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.
