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.