HL7 Personal Health Record System Functional Model, Release 2
2.0.1-ballot - Normative Ballot

HL7 Personal Health Record System Functional Model, Release 2, published by EHR WG. This guide is not an authorized publication; it is the continuous build for version 2.0.1-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/phrsfm-ig/ and changes regularly. See the Directory of published versions

Anticipated Uses (Informative)

International Community and Realm Specifications

HL7 is an international community and supports the development of functional profiles, which may be country specific (HL7 realm) specifications within a standard.

Anticipated Development Approach: Functional Profiles

A functional profile is a selected set of functions that are applicable for a particular purpose, group of users, degree of interoperability, custodian, etc. Functional profiles help to manage the master list of functions. It is not anticipated that the full set of functions and criteria specified in the PHR-S Functional Model will apply to any single PHR-S implementation.

Similar to the EHR-S specified by ISO/HL7 10781 – EHR System Functional Model, a PHR-S does not conform directly to the Functional Model; rather, it conforms to one or more functional profile(s). For more information about creating, registering, and balloting functional profiles, see Chapter 3.6: Conformance Clause, Sections 3.6.2 and 3.6.6.

Functional Profiles are the more concrete expression of usable subsets of functions from the PHR-S FM. In this PHR-S FM the reader will see a long list of Function Names and Function Statements, which serve as reasonable representations of functions that may be needed by an individual PHR Account Holder. The list of functions is not intended to be used in its entirety for a given implementation and some of the functions may apply differently under different use scenarios. For example, many of the functions in the model apply directly to the PHR Account Holder, but some functions (e.g., PH.2.5.9 Manage Personal Genetic Information) might more appropriately be used by a specialist on behalf of the PHR Account Holder. The list of functions is not considered to be ready for system certification or implementation until a functional profile or constraint is generated. NOTE: See the examples of PHR-S functional profiles in Annex C PHR Sources.

The goal of creating a functional profile is to support a business case for PHR-S use by selecting an applicable subset of functions from the PHR-S FM. For example, a functional profile may be created by a vendor to develop a unique product for a specific population, or by any person/entity wishing to stipulate a desired subset of functions for a particular purpose or specific realm (see Annex C). Once an applicable subset of functions has been selected, the person/entity creating the profile assigns each function a priority of Essential Now, Essential Future or Optional. For more information about the steps to creating a functional profile, see the How-to Guide for Creating Functional Profiles released separately by the EHR WG.

A Conformance Clause defines the minimum requirements for profiles claiming conformance to the PHR-S FM. The Conformance Clause is a high-level description of what is required of profiles and implementations. It, in turn, refers to other parts of the standard for details. The Conformance Clause describes concepts critical to the understanding and implementation of the PHR-S FM, such as: what is a profile, what are conformance criteria, and what is mandatory versus optional. A Conformance Clause can also provide a communication between the implementers (vendors) and users (buyers) as to what is required, and gives meaning to the phrases, “conforming profile” and “conforming PHR system”. Additionally, it serves as the basis for testing and certification activities that may be performed by organizations external to HL7.