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.

Comments

[Steve Beller, PhD]

The PHR specifications are, in general, a good start, but they fail to offer elegant solutions for some of the most daunting issues.

One of the biggest shortcomings is the lack of an easy, low-cost way for a PHR to accommodate ALL relevant medical, terminology standards, and other healthcare content, as well as all data structures that currently exist and may emerge in the future. And, at the same time, enable the data to be shared securely between any current or future PHR applications. I suggest that this requires a paradigm shift in how data are structured for transport and reporting.

I propose a data organization model for data transmission and reporting that:

(a) Interoperates with any data stores (databases, spreadsheet, XML, document files, etc.) through a fluid “homogenization” process that translates and transforms data sets automatically depending on the source and the recipient.

(b) Enables data compositing and decompositing, so data from multiple disparate sources can be combined into a single dynamic report (compositing), and data from a single report can be broken up and distributed to multiple locations (decompositing).

(c) Uses formatting templates to generate different personalized reports from the same data set.

(d) Requires minimal resource use (e.g., data storage, server processing, and bandwidth consumption), as well as minimal parsing and transmission time.

(e) Promotes the fluid, efficient connectivity of loosely coupled networks of standalone and centralized PHRs (and other information systems).

(f) Supports any mathematical and logical algorithm easily and efficiently, for such things as medication monitoring, calendaring, trending, information therapy, and other forms of decision support and alerting.

The data organization model enabling these capabilities relies on the novel use of spreadsheets and cell-based indexing.
At this link http://curinghealthcare.blogspot.com/2007/04/personal-health-application.html I discuss the what such a PHR (which I call a PHA-Personal Health Application) would do.

And at http://cpsplit.typepad.com I present the data organization model in greater detail .

Steve Beller, PhD
http://curinghealthcare.blogspot.com
http://wellness.wikispaces.com

[Juhan Sonin]

Why aren't the "functional requirements" a wiki?

[Gail Casper]

Thanks for your comments. We considered a wiki, but due to time and resource considerations, opted against it. But the spirit of what a wiki is intended to achieve is something that we're definitely aiming for, and that's why we are soliciting comments from readers directly on the form where the functional requirements are accessed. Refining the requirements to make them most helpful to end users depends on the input and reactions that we get. We hope you'll consider adding your perspectives via this comment tool. (http://www.projecthealthdesign.org/form_page

[John, Industry Analyst, Chilmark Research]

Seems like you are re-inventing the wheel here. Why not adopt HL7 PHR-S FM?

[Lygeia Ricciardi]

John --

Indeed there is some overlap between HL7's efforts and the Project HealthDesign functional requirements, though the objectives for and methods of developing them are different. You're not the first person to ask about it--I'll do a longer post that compares them in more detail shortly. Thanks.

- Lygeia

[Steve Beller, PhD]

When it comes to PHRs (and technology in general) I have a problem with the “don’t reinvent the wheel” mindset. I assert that the functional (and data) requirements for the PHR will continue to evolve, changing considerably over time to accommodate advances in both health-related knowledge and computer technology (see this link http://curinghealthcare.blogspot.com/2007/05/art-of-health-knowledge-creation-use.html ). While HL7 PHR-S FM and the use of XML are examples of such evolving standards, there is no Holy Grail: no one requirement/standard is adequate for everyone and continued innovation is critical, which is why I applaud Project HealthDesign.

The PHRs of today, therefore, ought to be designed to be able to handle all requirements/standards, and ongoing changes to them, without requiring great effort and expense. That means we need extremely flexible applications with a simple, efficient and durable underlying technology structures that can map easily to any current & future data standards and use cost-effective methods for highly secure data analysis, storage, transport and display.

In terms of PHR content, what's needed is an easy, low-cost way for data from health care providers and consumers, no matter where they are stored, to be transformed into useful information that increases one's knowledge and understanding about the most cost-effective ways to deal with troubling health-related issues: from coping with a stressful life situation, to changing unhealthy lifestyles, to adhering to one's plan of care, to making valid diagnosis, to deciding wisely about which treatment option or insurance plan to choose. These capabilities go way beyond data storage and access, and enter into the realm of decision-support, self-help assistance and research facilitation; yet current day PHRs are very immature regarding these types of capabilities.

That is why I’m recommending even more creativity, including support for the development of disruptive (radical, discontinuous) technologies that are able to achieve the lofty goals I described above. Some are threatened by such paradigm-busting approaches for fear they will make their conventional technologies obsolete. Having everyone adopt a single functional requirement and data standard would remove that fear by stifling radical innovation and turning all PHRs in commodities that differ only superficially. We are currently in the “Stone Age” of health information technology and the PHR “wheels” we’ve been inventing barely roll. So, we ought to be “reinventing the wheel” many times!