Project Health Design Blog

Project HealthDesign and HL7 functional requirements for PHRs compared

Posted on March 27, 2008 by Lygeia Ricciardi

On February 25, 2008 Project HealthDesign publicly released its functional requirements for PHRs. Since then we’ve gotten several comments and questions asking how they relate to other efforts, particularly those of the PHR work group of the healthcare standards development organization HL7, which released its functional model for PHRs in November of 2007. (You can download it in a zip file here.)

While there is some similarity in the two efforts—-both address the desirable features, functions, and infrastructural elements of PHRs, they differ in their objectives, methods, and scope.

The primary objectives of the Project HealthDesign effort are to accelerate the development of PHR applications by obviating the need for developers to create common “building blocks” from scratch each time, and also to facilitate interoperability among PHR applications through the sharing of data and/or common application interfaces.

The Project HealthDesign building blocks (or “platform components,” which will be developed later this year) are not PHR applications unto themselves, but software modules that may be used by or integrated into PHR applications to provide useful services (the way, for example, that a master-patient index is a software module used by HIT applications). For example, one such module provides services for storing and managing medication lists, and another for storing and managing calendar data.

These components won’t necessarily provide the full set of end-user functionality, but they identify the data that the components should handle and the operations that they should provide to *enable* PHR applications themselves to provide the functions that end users need. In this regard, the Project HealthDesign functional requirements are most closely associated with the "infrastructure functions" that the HL7 work group defined.

The stated objective of the HL7 effort, meanwhile, is to “define a standardized model of the functions that may be present in PHR Systems”. According to HL7’s Overview of the PHR-System functional model, the PHR functions can be used to:

• Promote a common understanding of PHR functions upon which developers, vendors, users and other interested parties can plan and evaluate PHR functions.

• Provide the necessary framework to drive the requirements and applications of next level standards, such as PHR content, coding, information models, constructs and interoperability for information portability between sub-systems of a PHR-S and across more than one PHR.

• Establish a standards-based method by which individual countries can apply these PHR functions to care settings, uses, and priorities.

• Inform those concerned with secondary use of PHR data and national infrastructure what functions can be expected in a PHR System.

In short, Project HealthDesign is supporting the development of concrete modular building blocks for engineering PHRs, while HL7 is focused largely on the relatively abstract task of defining the ideal end-user functionality of PHRs.

As far as method is concerned, the Project HealthDesign team followed a “bottom up” or inductive approach, dictated by the needs identified by the grantee teams in their development work, while the HL7 team followed a “top down” or deductive model in which a variety of experts collaborated over the course of several years to envision a broad array of functions that they think should be part of PHRs.

Finally, there is a difference in scope. The HL7 requirements are designed primarily to parallel those of clinical records systems; the Project HealthDesign ones also emphasize consumer-generated data that does not correspond to information in a clinical records system and may in fact prove useful only to the patient (eg how far he runs each day, or the regularity of her menstrual cycle).

The two initiatives validate each other by identifying many similar elements. They are complementary in that Project HealthDesign can vet some of HL7’s existing requirements through field testing and perhaps suggest some new ones; at the same time HL7 can help to identify potential extensions to the Project HealthDesign functional requirements.

The Project HealthDesign team hopes that its requirements will be used by many different information models, such as the CCR and proprietary clinical information systems, and that they will serve as a model for new requirements descriptions.

Using the iPhone for eHealth

Posted on March 20, 2008 by Lygeia Ricciardi

Last summer this blog highlighted the trend toward using cell phones as a means of accessing or linking to a PHR. Earlier this month Apple, maker of the popular iPhone, released a software development kit (SDK) that makes it easier for programmers outside of Apple to write applications for it.

Applications of many types are expected to result from this greater access to the iPhone's inner workings. Several were on show at Apple's announcement of the software development kit, including one for medical professionals produced by ePocrates. Other updates to the iPhone include e-mail and data-syncing software that will make it more attractive for business users.

While seeding the development of consumer health applications was not a specific focus of Apple's announcement, they will not be not far behind. See the previous post on cell phones for brief descriptions of two patient applications for the iPhone that Project HealthDesign teams are currently working on.

In June Apple will release its iPhone 2.0 update, at which time the public will be able to download iPhone applications from iTunes just like music.

For more on the potential implications of greater openness in health care generally (including the openness of code), see the post inspired by the paper “Harnessing Openness to Transform American Health Care” by Elliot Maxwell, which was published early this year.

Value of PHRs to be Studied

Posted on March 19, 2008 by Lygeia Ricciardi

According to Digital HealthCare & Productivity.com, Kaiser Permanente and Microsoft agreed to sponsor a study by the Center for Information Technology Leadership (CITL), a nonprofit research center in Boston, on the potential impact, costs, and value of PHRs. The expected date of completion is some time in fall, 2008.

Deidentified Data Doesn’t Exist… and What to Do About It (Part II)

Posted on March 7, 2008 by Lygeia Ricciardi

This is the second part of the entry called “Deidentified Data Doesn’t Exist… and What to Do about It”. In the first installment, I wrote about the extreme difficulty of stripping the identity from any reasonably meaningful set of health data.

If we assume there is a clear distinction between personally identifiable and deidentified data, we can apply certain policies to the former and other, less restrictive ones, to the latter. But unfortunately, if we conclude that genuine deidentification of data is very hard to achieve and/or yields outputs of relatively low value for most purposes, we need a more sophisticated (though not necessarily uniform) degree of privacy protection for virtually all health data—including data in PHRs generated by patients or consumers.

There is no silver bullet when it comes to privacy protection. No single element can do the job, but an array of coordinated polices and technologies together can be very effective. There is a lot we can gain from previous efforts to protect privacy in disciplines other than health. For more than 25 years, Fair Information Practices have been used in the US, Canada, and Europe to define appropriate ways of handling electronic personal information, whether it is health information, financial information, or any other kind.

According to the US Federal Trade Commission, the five core principles of privacy protection embodied in Fair Information Practices are (1) Notice/Awareness; (2) Choice/Consent; (3) Access/Participation; (4) Integrity/Security and (5) Enforcement/Redress. It’s important to apply the practices as a group, not just pick and choose among them. While many stakeholders—especially policymakers—have a role to play in implementing Fair Information Practices, part of the responsibility falls to designers of applications such as PHRs because design shapes use; you can’t just graft privacy protective policies onto a technology after its features have been set.

In 2006 the Markle Foundation released the “Common Framework”, which applies Fair Information Practices specifically to the case of health information exchange. Markle is currently working on a paper as part of the Common Framework that will address consumers’ access to their own health information via PHRs and related tools and services. That paper contains very specific guidelines on, for example, how to write and post a privacy notice, and how to protect the integrity of data. I’ll post a note on this blog when the paper is publicly released later this spring.

In addition, if you are not already familiar with it, I suggest the Project HealthDesign e-primer on privacy as a resource for exploring this topic in greater detail.

PHR-Related Events in March

Posted March 3, 2008 by Lygeia Ricciardi

While there are many conferences and events that cover some aspect of the overlap between health and information technology, I wanted to draw your attention to a few coming up this month that highlight PHRs specifically:

March 3-4, 2008 -- Health2.0 Spring Fling “Connecting Consumers & Providers”
A spinoff of the broader Health 2.0 Conference in the fall, this meeting is focusing on consumers & providers using Health 2.0 tools and technologies.
(San Diego, CA)

March 5, 2008 -- National Web Conference on Personal Health Records: An Overview
This is the 1st in a 3-part Series of web conferences on Personal Health Records sponsored by the Agency for Healthcare Research and Quality. (Online)

March 18, 2008, 1:00 p.m. to 4:00 p.m. -- HHS Public Consumer Empowerment Workgroup Meeting This is a meeting of one of the workgroups of the American Health Information Community (the Community), run out of the Department of Health. It is made open to the public via webcast—you can ask questions at the end. (Online)

March 28-30, 2008 -- Patient-Centered Computing and eHealth: Transforming Healthcare Quality
Project HealthDesign's National Program Director, Patricia Flatley Brennan, RN, PhD, will be a keynote speaker at a CME course presented under the auspices of Harvard Medical School's Division of Continuing Education. (Boston, MA)