Infrastructure Support for PHRs: What’s Missing?

Posted August 18, 2008 by Lygeia Ricciardi

Project HealthDesign is publicly releasing the results of its analysis of the extent to which existing and emerging platforms and standards meet the infrastructure requirements for PHRs as defined by its nine teams. The analysis, Meeting the Requirements of Project HealthDesign: Comparative Analysis with Respect to Existing and Emerging Clinical Data Standards and Commercial PHR Data Repositories, includes a review of both clinical data standards (for sharing information), and data repositories or platforms (for storing information). Efficient, scalable PHRs demand that both actions be supported by an external infrastructure so applications like the ones Project HealthDesign is working on can function.

For those who may not be frequent readers of this blog, Project HealthDesign is funding nine interdisciplinary teams to develop innovative PHR applications that address the specific needs of diverse health care consumers. These PHR applications were designed presupposing a robust technical infrastructure on which they could run–and as applications, are distinct from the infrastructure they plug into. It’s important to clarify that the “infrastructure” is not a single and dedicated set of physical wires and databases but rather a collection of various standards, protocols, and networks including the Internet. In the Project HealthDesign vision, consumers of the future will choose one or numerous PHR applications to share and interpret their personal health data via that infrastructure.

Personal health data used by consumers via a PHR may include the clinical information typically found in a doctor’s medical record (e.g., a list of health problems and medications, vital statistics, family health history), and information consumers gather themselves, such as observations of daily living (e.g., information about their sleep, exercise, mood, diet and adherence to medication regimens).

Project HealthDesign commissioned Sujansky & Associates, LLC to take a look at the existing and evolving infrastructure for PHRs to see how well it supports the needs of its nine grantee projects based on its ability to support four basic requirements or key functions that were identified earlier this year. These include medication list management, calendaring, observation recording, and access control. They are common to all of the Project HealthDesign projects and many outside PHRs as well.

What does the analysis reveal?
To qualify as supporting the needs of the Project HealthDesign requirements (and thus be deemed sufficient in this analysis), a given standard must both promote interoperability and be extensible, meaning that others can build on it. While in general the infrastructure largely supports the functions Project HealthDesign requires, the analysis addresses only what’s missing—it’s a sketch of the hole, as opposed to the much larger doughnut.

Though what’s missing depends on the individual standards or software being discussed, there are some patterns in the types of needs identified. For example, most existing standards were developed to fit the traditional model of health care, which revolves around a patient’s periodic visits to doctors, usually in connection with a particular illness or injury. By contrast, the health care “consumer” of the future may monitor his or her health on an ongoing basis, and may place as much attention on preventing illness as on treating it. The existing standards that group data according to episodes of care may not be appropriate for data collected by consumers because it doesn’t naturally fit into discrete episodes.

Is the analysis meant to be exhaustive?
Nope. It includes a discussion only of the most widely used and prominent standards (HL7, CCR, CCD, AHIP/BCBSA etc.) and platforms (Google Health, HealthVault, and Indivo/Dossia). There are certainly others out there that have not (yet) been covered. Even if it were possible to do a comprehensive scan, standards and platforms evolve quickly in some cases, so the analysis can be accurate only up to a point in time.

So why did Project HealthDesign release the analysis, and what should we do with it?
The scan was initially intended for internal use only, but the project is releasing it publicly to encourage discussion and help the PHR field to continue to grow. The hope is that those interested in sharing and storing data—as well as in developing PHR applications—will join the discussion and think about how the existing infrastructure can evolve to accommodate a broad range of PHR needs.

If you would like to comment on the analysis, please share your ideas on this blog (see comment form below). If you prefer to submit a private comment directly to Project HealthDesign, you can use this link. Your comments will help to inform Project HealthDesign and the PHR community in general, fostering its continued evolution.

Comments

[Busby SEO Challenge]

good job

[Sean Nolan]

All in all a solid and comprehensive review of the state of the art ... I appreciate the depth of research that went into the project.

That said, it does contain a few pretty critical misunderstandings around the HealthVault authorization model. I have tried to clarify things on my blog at http://blogs.msdn.com/familyhealthguy/archive/2008/08/26/comparative-analysis-with-respect-to-the-comparative-analysis.aspx . Hopefully it helps!

Look forward to continuing the discussion.

---S