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.

Project HealthDesign Releases Functional Requirements for PHR “Building Blocks”

Posted February 25, 2008 by Lygeia Ricciardi

Over the past 14 months, Project HealthDesign (PHD) has been working to support the development of an innovative array of PHR applications that address the specific needs of diverse health care consumers. Despite the differences in PHRs designed for, say, adults managing chronic pain, caretakers of children with cystic fibrosis, or sedentary adults wanting to increase their activity, there are numerous basic functions that PHRs have in common, like documenting observations of their illness experiences or helping patients to remember to take medications or scheduling appointments with a health care provider.

Today, Project HealthDesign announced the release of functional requirements for a set of software “building blocks” or “platform components” that are common to many PHR applications. The requirements are intended to inform and support the PHR development community generally, not to favor any particular existing model, product, or approach.

Walter Sujansky of Sujansky & Associates, LLC, who led the team that developed the requirements, informed me that, “These requirements were derived from the needs of the nine PHD applications, but, given the diversity of these projects we think that the requirements could have broad applicability across the field.”

The Project HealthDesign team is encouraging interested parties to use the comment form provided on the program’s Web site to send feedback on the functional requirements directly to the Project HealthDesign team, and also to comment on them publicly via this blog.

Project HealthDesign Director Patti Brennan said, “We are hoping that the functional requirements will catalyze PHR development broadly by providing an organizing structure—a little bit of structure can unleash a lot of creativity.”

What do the functional requirements cover?

Since Project HealthDesign was launched in 2006 it was anticipated that a few key functions would emerge as essential to all most PHR applications. Indeed they have. The functional requirements are an identification and description of those key functions or “core services.” This is not a comprehensive list, but an initial set, based on the experience of the project teams, that is expected to evolve with time:

• Medication list management—Record, manage, share, and provide advice to consumers based on a list of the specific medications they are taking.
• Calendaring—Track, share, and remind consumers of scheduled events relevant to the management of their health and their lives.
• Observations captured in the course of daily living—Manage health-related information captured outside of the health care system. For example, acknowledging the important fact that your blood pressure measurement may be very different at home than at the doctor’s office; the idea is to track information where people are…at home, work, or school, in transit, at the park, etc.
• Identity management—Manage user authorization and authentication and allow consumers to monitor and control access to their own health data.

Why are functional requirements needed?

Articulating functional requirements is a first step toward developing “common platform components” – the actual software modules that provide common services and a functional platform for PHR applications.

In addition, common platform components support interoperability. They may comprise, in effect, a shared infrastructure that facilitates the seamless exchange of information among consumers, caregivers, and physicians who may interact with multiple PHRs and related applications.

Steve Downs of the Robert Wood Johnson Foundation talked with me about how the functional requirements help realize the Project HealthDesign vision – to stimulate the field to develop more user-centered PHR applications and provide tools to facilitate their work.

“Since the beginning of Project HealthDesign, we've argued that innovation in personal health applications would most likely result if developers could build applications on top of open platforms that provided access to medical records, other relevant data, and core services.  The reasoning is quite simple -- with access to a platform, PHR application developers don’t have to reinvent the wheel. Instead they can focus on the ‘front end’ applications unique to specific groups of users, not the ‘back end’ coding that has already been done by others.  Our project teams have been designing and prototyping applications—to meet a wide range of possible users and health management needs—that assume access to such a common platform.  One of our goals has been to use the design process to identify the core services that a platform would need to offer.  Releasing these functional requirements serves two purposes:  1) it can inform the providers of PHR platforms of potential services they can offer to enable more 3rd party application development; and 2) it provides an opportunity for PHR application developers to join the discussion and by adding their perspective on what core services are needed to support their applications.”

Additionally, Project HealthDesign Director Patti Brennan points out that the development of functional requirements has helped several of the grantee teams by providing a framework that helps to shape the applications they are building.

How were they developed?

Project HealthDesign enlisted a team led by Walter Sujansky of Sujansky & Associates LLC to help develop the functional requirements and common platform components through an in-depth process of interviews with the nine grantee teams and analysis of their work to date.

As Patti Brennan underscored, “The teams ‘backed into’ an articulation of the functional requirements from their work, rather than imagining hypothetically what they might look like at the outset. We believe that this approach is the most practical because it’s grounded in real life experience.”

What’s next?

Project HealthDesign hopes the release of the functional requirements will complement and inform existing and future PHR development and related efforts, and that it will stimulate a broader discussion about the standardization and modularization of platform services.

Later this year, Project HealthDesign will release prototype versions of the actual code—the common platform components that correspond to the functional requirements released today. Those common platform components are being developed to support the prototyping work of the nine Project HealthDesign teams and will be made available to the public for vetting and integration into other efforts.

Congratulations, Paul Tang!

Posted February 1, 2008 by Lygeia Ricciardi

Dr. Paul Tang, the Chair of Project HealthDesign, is profiled as an "IT Visionary" by Health Care's Most Wired Magazine online. Paul is Vice President and CMIO at Palo Alto (Calif.) Medical Foundation.

Making a "Moodmeter": A Glimpse into Next Generation PHR Design

Posted by Lygeia Ricciardi on January 15, 2008

One of the Project HealthDesign teams, the Living Profiles Team, based at the Art Center College of Design in Pasadena, is developing a PHR application to help adolescents with chronic illnesses transition from pediatric to the adult care system.

What’s really interesting about this team from my perspective is that it is intensely focused on understanding teens and their specific needs, in part by learning from applications that are popular among this age group, such as phone texting, IM, Facebook, and YouTube. Teens use these applications in building social connections--and their social interactions with each other often incorporate how they are feeling.

Naturally, how you are feeling can be very relevant from a health perspective, as well as a purely social one. The Living Profiles Team is trying to come up with ways that teens can convey their feelings to caregivers through a PHR. A member of the team, Gilad Lotan, has been blogging about some of the interesting questions that arise, such as “What is a mood, anyway?” And “How can you use images to convey it?” Have a look at Gilad’s blog for more.

Project HealthDesign in the Wall Street Journal

Posted by Lygeia Ricciardi on December 11, 2007

For those of you with Wall Street Journal online access, have a look at the mention of Project HealthDesign in today's edition. Dr Bill Yasnoff includes the project as a "recommended reading" resource for people interested in health information and IT.

Welcome to the Project HealthDesign blog!

This is a place to share and learn about changes in the policy and media landscape that impact the development of personal health records (PHRs), and the field of health and information technology generally.

 

While part of our intended audience is the innovators – including Project HealthDesign grantees – who are dreaming up and designing new services and tools, the topics we’ll cover here are relevant to a much larger group, including policymakers, healthcare providers, insurers, technology vendors – and especially patients or consumers, a category to which we all belong to some degree.

 

Last month at the American Medical Informatics Association (AMIA) Spring Congress in Orlando, I attended a panel chaired by Project HealthDesign Director Patti Brennan. Representatives from four Project HealthDesign teams shared their progress so far, about six months into the project.

 

I learned about how PDAs can help patients manage chronic pain, and how an open-source program will tap into the power of community to motivate sedentary adults to become more active. I was surprised by grantee JR Kedziora’s observation that different users – all with diabetes – have very distinct preferences in the ways in which they receive health information electronically. And I was intrigued by a group that is using visual vocabulary (the Art Center College of Design in Pasadena is serving as the lead partner on its team) to reach teens on their own terms, using formats that appeal to them. Each project was unique. Despite their variety, they shared several common themes, two of which I’d like to highlight at the launch of this blog.

 

The first is a contagious spirit of blue-sky creativity. You see, I live in Washington,DC, home of the filibuster, partisan gridlock, and bureaucratic red tape. Nearly every discussion of health and IT (and there have been plenty in the last 20 years!) is mired by a review of The Barriers blocking its progress. Where is the technical infrastructure? Who will pay for it? Will doctors use it? Can patients trust it? Project HealthDesign waves those concerns aside – and asks us to imagine, for a moment, what is possible.

 

This seemingly impractical approach is in fact very practical. We need a compelling and concrete vision of what health IT could be. Without an understanding of its value, it is extremely difficult to muster the forces to overcome The Barriers, which are indeed formidable. But if we, including and especially the general public, can grasp how healthcare could be, we have a much better chance of making it so. And the future isn’t as far off, time or technology-wise, as we might think.

A second common theme that came through the panel presentations was the importance of user-centered design, which calls for direct input from users in the development of a product or service. In that spirit, in this blog I will report and opine on topics that I find fascinating and relevant to PHRs, but it’s also up to you to communicate your interests and needs so I can better meet them. Let the conversation begin!

- Lygeia Ricciardi