HL7 Personal Health Record System Functional Model, Release 2
2.0.1-ballot - Normative Ballot
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
The following is the HL7 EHR Work Group (EHR WG) -approved Conformance Clause for the PHR System Functional Model (PHR-S FM). As important background on conformance, please note the following:
The technical and management staff of the U.S. National Institute of Standards and Technology (NIST), Information Technology Laboratory provided input and support for the development of this conformance clause.
This conformance clause defines the minimum requirements for functional profiles claiming conformance to the PHR-S FM. It also identifies how PHR systems achieve conformance to the Functional Model (FM), which is via the system’s conformance to a particular functional domain profile, multiple functional profiles, or combination of domain and companion profiles. This clause specifies:
While the conformance requirements for functional profiles can be found in this clause, they necessarily reference the PHR-S FM and other sources.
This conformance clause does not specify testing or validation procedures to assess a functional profile’s conformance to the PHR-S FM. It also does not specify testing or validation procedures to determine whether a PHR system conforms to a functional profile or matches its Conformance Statement.
Creating a functional profile is a method for defining subsets of the PHR-S FM. A functional profile is a specification which uses the Functional Model to indicate which functions are required, desired, or implemented for certain PHR systems (e.g., systems characterized by their attributes such as source, custodian, technical approach, or level of functionality) or for other purposes (e.g., systems based on scope or nature of information such as chronic conditions). See the figure in Section 3.6.8 for representative examples.
Functional profiles can be created by healthcare community stakeholders with interest in using and/or providing a functional profile for a PHR system (e.g., Integrated Delivery Network, or an Employer or Payer system). Functional profiles can represent the functionality required and desired for the level of functionality and interoperability, or reflect the functionality incorporated in a vendor’s PHR system. Once a functional profile is defined it can be implemented by PHR systems or it MAY trigger the creation of derived functional profiles. A derived functional profile is a functional profile that is created from an existing functional profile, inheriting functions from the base (existing) functional profile.
(NOTE: During the process of creating a Functional Profile, it MAY be important to understand and accommodate clinical processes, work flows and/or interaction(s) of healthcare actors. The international standard ‘ISO 13940 System of Concepts to Support Continuity of Care’ provides an outline of key principles and processes in the provision of healthcare. We would highly recommend reviewing this standard as part of your functional profile development work.)
There are two types of functional profiles: the Domain Functional Profile and the Companion Functional Profile. The Domain Functional Profile is the common type of profile used to describe a PHR system for a specific community of stakeholders and/or sponsors (such as, diabetes-specific, asthma-specific, EHR-linked or payer-linked). Also, a Domain Functional Profile of a PHR system can be for use in a selected realm to meet the rules, regulations and standards applicable for that realm. The Companion Functional Profile is a type of profile that must be paired with one or more Domain Functional Profiles. The purpose of a Companion Functional Profile is to add unique features to a PHR System, such as for research, records management and evidentiary support, usability, or preventative care. For example, many PHR systems for consumers do not need to support clinical research. For a clinic that is supporting advanced research, the need MAY exist for a PHR system that is capable of all of the expected functions for routine patient self-monitoring activities, but also has unique features to support additional data collection needs for research reporting and clinical trials.
The Conformance Clause portion of this standard also supports the creation of other (potentially) unique types of Companion Functional Profiles, whose goal can be to meet the common (or overarching) needs of regulation-based or realm-specific requirements.
A formal process exists for registering and balloting functional profiles. Functional profiles that are submitted to the HL7 EHR Work Group with an attestation of conformance to Section 3.6, Conformance Clause, of the HL7 PHR-S FM Standard and successfully complete review by the Work Group are designated as “Registered functional profiles”. Registered functional profiles that undergo formal public scrutiny via the HL7 consensus process as an Informative EHR Work Group ballot at the Work Group level will be designated as HL7 Informative functional profiles. HL7 Informative functional profiles are eligible to undergo full HL7 membership ballot via the HL7 consensus process.
A PHR-S does not conform directly to the PHR-S FM; rather, a PHR-S conforms to a functional profile (i.e., a subset – more specifically, a tailored subset) of the PHR-S FM. Conformance to the PHR-S FM is defined for functional profiles. A functional profile conforms either directly to the PHR-S FM or to another conforming functional profile. Thus, functional profiles claim conformance to the PHR-S FM and PHR systems claim conformance to one or more conforming functional profiles. A PHR system can also claim conformance to a domain functional profile, in combination with one of more companion functional profiles. A PHR system cannot claim conformance solely to a companion functional profile. Figure 3 illustrates this relationship.
Functional profiles allow for added specificity and extensibility to the FM with changes allowed to the base FM functions and criteria. Section 3.6.6 of this chapter defines rules for these changes. It is also required that any changes and additions be tracked. Two added columns in profiles accomplish this. One column will document the unique source FM row number for each item in the new profile (or source profile for a derived profile). The second column will provide codes for the type of changes from the source FM (or source profile). Together, these two traceability columns will keep track of the origins of the functions or criteria – and whether it is modified or unchanged from that within the FM or the source profile. This MAY be important when questions arise as to where did it come from, why did you choose or modify it, etc. It can also be helpful to have traceability back to the FM functions and criteria if and when revisions to a profile or a derived profile are needed to reflect care setting, regulatory, technology changes – or when a newer version of the FM is offered.
The following keywords (i.e., normative verbs) SHALL be used to convey conformance requirements.
Every function in the PHR-S FM is associated with a set of conformance criteria. These conformance criteria form the basis for determining whether the function has been implemented.
Functional profiles also have conformance criteria associated with every function in the functional profile. The functional profile’s criteria are either (1) adapted from the PHR-S FM criteria with care-setting and application specific information or (2) if no care-setting or application specific criteria are present, inherited directly from PHR-S FM. Functional profiles MAY change PHR-S FM criteria to match the needs and priorities of the functional profile’s constituency, e.g., by making it more specific, or changing it from ‘may’ or ‘should’ to ‘shall’. The functional profile SHALL NOT be made less restrictive than the PHR-S FM by changing ‘shall’ criteria to ‘may’ or ‘should’ criteria. (A companion functional profile MAY be less restrictive that the FM by ignoring ‘shall’ criterion). Functional profiles MAY also add additional criteria.
Conformance criteria that contain the keyword ‘shall’ and a dependency on situational conditions are called ‘dependent shall’ criteria. The ‘dependent shall’ SHALL contain the phrase “according to user role, organizational policy, and/or jurisdictional law” or other appropriate grammatical tie-in words (e.g., ‘based on’ rather than ‘in accordance’). A ‘dependent shall’ criteria is used to highlight only these (i.e., user role, organizational policy, and/or jurisdictional law) conditions. A ‘dependent shall’ criterion is a mandatory criterion for functional profiles and situational for PHR systems. Specifically,
There is often a link between functions and their criteria with other functions and criteria. For example, a given function MAY depend on another function or on a specific criterion associated with another function. A criterion in the functional profile that references another function in the functional profile SHALL reference that function by indicating its Function ID and Function Name, as “X.n.n (Name)” (e.g., “PH.1. 5 (Manage Consents and Authorizations)”. If the referenced function is required to be implemented, then all the ‘shall’ criteria of this referenced function apply. If the referenced function is a parent function that has child functions (i.e., sub-functions), the reference must be explicit regarding whether the child functions are included in the reference, all or selected ones. See the examples below:
A criterion in the functional profile that references a specific criterion in another function SHALL reference that function by rewriting the referenced criterion as one of its own and indicating the function and criterion number from where it came (e.g., F#, CC3).
Functions MAY be contained (i.e., nested) within other functions. A nested function is a ‘child’ to its ‘parent’ (i.e., the function that contains it). A child SHALL always have a parent. A function that is not a parent to another function is considered a ‘leaf’. Figure 4 illustrates this hierarchical structure. The PHR-S FM is represented as a hierarchical list of functions, consisting of functional parents, functional header children and functional leaf functions. Headers include an ID, Name and “H” in the column labeled “Type”. Headers MAY contain conformance criteria only if the criteria apply to all its descendent functions (children, grandchildren, etc.). All parent functions SHALL be designated as a header (“H”) function. Leaf functions contain at a minimum the following: ID, Name, Statement, Description, and Conformance Criteria and have an “F” in the “Type” column.
Conformance criteria listed in a header function SHALL be inherited by all its children functions. Similarly, conformance criteria listed in a parent function SHALL be inherited by all its children functions. Conformance Criteria have a “C” in the “Type” column.
(Note: The numbering schema above reflects functions in the Personal Health section. For instance, PH.1.1 is the function ‘Identify and Maintain a PHR Account Holder Record.)
Functional profiles either:
Functional profiles SHALL NOT change the name or statement of a function except to allow for alignment to realm specific nomenclature, including language distinctions and implication of non-english translations. In these cases, the International Organization for Standardization (ISO) country code (ISO 3166 Country Codes) SHALL be appended to the function ID in the functional profile. It is recommended that the HL7 Affiliate for the respective realm coordinate with the profile development process to maintain a mapping of the Functional Model function name and/or statement and the realm-adjusted name and/or statement.
Functional profiles indicate the importance and/or immediacy of a functional profile by associating a priority with a function. Three priorities have been defined: Essential Now, Essential Future, and Optional.
Any or all of these priorities SHALL be used in a functional profile. If the Essential Future priority is used, then functional profiles are required to define the timeframe associated with implementing functions. A timeframe MAY be a date, time allotment (e.g., year 2014, or four months after functional profile publication), or event (e.g., subsequent publication of this functional profile). A functional profile MAY define multiple timeframes for the Essential Future priority. If multiple timeframes are defined, then the timeframe SHALL be used to qualify each occurrence of the Essential Future priority (e.g., EF-2015, EF-2016).
To accommodate changes in technology as well as functional profiles’ needs, the PHR-S FM is designed for extensibility with respect to functions and their related criteria. Incorporation of additional functions in the functional profile beyond what is defined in the PHR-S FM is accommodated through a set of rules for adding new functions as defined in Section 3.6.7.3.
Incorporation of additional criterion, changing the sequence of criterion and providing greater profile-specific detail, beyond what is defined in the FM, is accommodated through a set of rules for adding new criterion or changing existing criterion as defined in Section 3.6.5.2.
A functional profile claiming conformance to the PHR-S FM SHALL meet all requirements specified in section 5.7.2 Rules for Domain Functional Profiles or 5.7.6 Rules for Companion Functional Profiles.
Domain functional profiles that adhere to the Rules for Functional profiles MAY claim conformance to the version of the PHR-S FM from which it was derived. Functional profiles claiming PHR-S FM conformance SHALL:
Functional domain profiles claiming conformance to the PHR-S FM MAY:
Functional domain profiles claiming conformance to the PHR-S FM SHALL NOT:
If a function is not adequately specified for a functional profile or does not exist, the functional profile SHALL only create new children; the new children can be parents or leaves. Figure 5 illustrates the addition of a new child function.
The following rules specify the method for creating new functions:
If new children functions are created by a functional profile that is balloted or registered, these new functions will be captured by the HL7 EHR Work Group and tracked for review. The EHR Work Group WILL use these new functions and related criterion as input and candidates for changes to the FM (e.g., inclusion, relaxation of conformance criteria). The EHR Work Group MAY maintain a file of functions and criterion reviewed and rejected for inclusion in a future version of the FM.
Derived functional profiles claiming conformance to one or more base functional profiles SHALL:
Functional profiles MAY want to require that a conformance statement be produced for systems claiming conformance to the profile. A Conformance Statement provides information about a PHR system, by presenting in a uniform manner the functions that have been implemented by the PHR system. A blank (i.e., yet to be completed) Conformance Statement typically takes the form of a questionnaire or checklist, to be completed for each PHR system.
A Conformance Statement provides a concise summary of a functional profile. It follows a standard layout, thus providing PHR system vendors and users a quick overview of the functional profile’s functions. Moreover, it can also be used to highlight optional functions and capabilities supported by the PHR systems as well as document any extensions (i.e., additional functionality beyond what is in the functional profile) or specializations that have been made. A PHR system’s Conformance Statement provides information that can be used in assessing the PHR system’s conformance to a specific functional profile. Additionally, organizations wishing to acquire a PHR system MAY produce a Conformance Statement to indicate the functions that are required and/or desired in a PHR system.
Functional profiles MAY want to include a blank Conformance Statement in order to promote consistency among completed Conformance Statements. Conformance Statements can be useful in determining the chances of interoperability between two PHR systems, by comparing the functions supported by each PHR system. Additionally, for conformance testing purposes, it can be used to facilitate the selection of tests that would be applicable to a particular PHR system being tested. For example, if a PHR system did not implement functions designated as ‘Essential Future’, this would be evident in the Conformance Statement and the tests for these functions (which are unimplemented) would not be performed.
Companion functional profiles that adhere to the Rules for Functional profiles SHALL claim conformance to the version of the PHR-S FM from which it was derived. Companion functional profiles will follow the section 5.7.2 Rules for Domain Functional Profiles and the Section 3.6.7.4 Rules for Derived Functional Profiles, except for the exceptions and addition described below:
Companion functional profiles claiming FM conformance SHALL:
Companion functional profiles claiming conformance to the FM MAY:
It is determined that a new source-based functional profile is needed to reflect the specific requirements and expectation of a system from this particular stakeholder source (e.g., a hospital, medical group, payer, or health record bank) – see Figure 8. To help ensure widespread use and uniformity, the functional profile authors elect to undergo the registration review followed by the HL7 consensus process (i.e., submitting the registered functional profile for an “Informative” committee level ballot). If successful, the result will be designated an HL7 Informative Functional Profile.
After looking at current list of HL7 PHR informative functional profiles, the decision to create a new functional profile is made. Each function in the PHR-S FM is examined and those that are relevant to the PHR source chosen – e.g., a Provider-Linked PHR from an Integrated Delivery Network. From these functions, a small set of ‘core’ functions is selected as being essential and mandatory. For each function, conformance criteria are developed either adapting the PHR-S FM conformance criteria or in a few cases, using the PHR-S FM criteria as is. To complete the functional profile, a description of the functional profile is written that includes its intended use and audience, as well as a conformance clause. The functional profile is made public by publishing it on various web sites. Additionally, the functional profile is submitted to HL7’s EHR WG for registration review, comment and ballot.
A Community of Interest (e.g., a regional health information exchange network, or a care management community who targets a specific chronic condition) or a particular stakeholder may want a functional profile. The Community of Interest or stakeholder MAY want a profile based on the level of functionality that they want for their patient population, to reflect the expectation of the PHR system’s sophistication and/or capabilities – see Figure 8.
The Community of Interest or stakeholder does not want to create a new functional profile from scratch. After looking at the list of HL7 Registered PHR Functional Profiles, they find an existing functional profile that is very close to what they want. Using this functional profile as the base, they accept all the functions designated as ‘Essential Now’, reject functions designated as ‘Future’ and add several more functions. For each function, they review the conformance criteria and adapt the criteria to reflect their situational information.
A vendor of a PHR system wants to claim conformance to the PHR-S FM.
The vendor identifies and lists all the functions that are in his product. The vendor adds a description and a conformance clause (see samples in Section 3.6.8.2). This is the vendor’s functional profile. If the vendor has actually implemented all the functions listed, then this is equivalent to ‘Essential Now’ and these functions are mandatory. Vendor features that are not in the PHR-S FM MAY be added as added functions or added criteria – within the rules of sections 5.7.2 and 5.7.3 above. If functions that are currently implemented and those that will be implemented in the future are listed, then the functional profile is comprised of ‘Essential Now’ and ‘Essential Future’ and/or optional functionality. Finally, the vendor adds conformance criteria for each function inheriting directly (without change) the criteria in the PHR-S FM. This is appealing in that, the vendor has the opportunity to list the current functionality and, if desired, indicate future plans. In essence, this is similar to a vendor Conformance Statement (a concept with which most vendors are already familiar). A vendor MAY create multiple functional profiles.
To aid functional profile developers in developing a conformance clause for their domain functional profile, as required by Section 3.6.7.2 rule #3, the following fictional examples are offered. Note: in these examples, the keywords ‘SHALL’, ‘SHOULD’, and ‘MAY’ are capitalized and bold. This is a convention to draw attention to the keywords.
This domain functional profile defines the conformance requirements for PHR systems and derived functional profiles. To conform to this functional profile, all ‘Essential Now’ functions SHALL be implemented. ‘Essential Now’ functions are considered mandatory functions. A PHR system is conforming if it implements all the functions designated as ‘Essential Now’ and the mandatory conformance criteria associated to that function. A derived functional profile is conforming if it follows the Rules for functional profiles.
Mandatory conformance criteria are indicated by the keyword ‘shall’. Optional conformance criteria are indicated by the keywords ‘should’ or ‘may’.
PHR systems SHALL provide a Conformance Statement structured according to the rules and policies defined in this functional profile.
Conformance is defined for My-PHRsystem. All functions in this functional profile are mandatory, are deemed as ‘essential now’, and SHALL be implemented in order to conform to this functional profile.
Conformance is defined for BuyMyDiabetesPHR. To conform to this functional profile, all functions labeled as ‘essential now’ SHALL be available and have been implemented. Functions labeled ‘essential future’ are optional, in that they are present for informational purposes only and MAY be implemented in future functional profiles.
Conformance criteria in the FM and those created can be structured in the simple format an Actor followed by normative verb followed by action or property. For example: The system SHALL capture demographic information as part of the patient record.
However, there are two conditional forms for which if the condition is true, then the following text must apply. One is If/Then. If condition, then Actor followed by normative verb followed by action. If the condition is not met (i.e., false) then ignore the rest of the sentence. For example, IF data is exchanged with internal or external systems, THEN the system SHALL conform to function TI.5.4 (Interchange Standards).
The other is a ‘Dependent Shall’ format. Actor followed by normative verb followed by action/interaction followed by ‘according to scope of practice, organizational policy or jurisdictional law’. For example, “The system SHALL enable EHR-S security administrators to grant authorizations to principals according to scope of practice, organizational policy, or jurisdictional law.” The following example of a PHR-S FM ‘dependent shall’ criterion will be used to illustrate concepts throughout this section.
PHR-S FM criterion: The PHR-S SHALL provide the ability for PHR-S security administrators to grant authorizations to principals according to user role, organizational policy, and/or jurisdictional law.
The purpose of the ‘dependent shall’ is to allow functional profiles to constrain a PHR-S FM ‘shall’ criteria based on situational conditions such as policy and legal implications. Specifically, the ‘dependent shall’ criteria in the PHR-S FM are ‘shall’ criteria plus a dependency, where the dependency is defined by:
The structure of the ‘dependent shall’ criteria in the PHR-S FM is the same as the ‘shall’ criteria except with the addition of the phrase “according to user role, organizational policy and/or jurisdictional law” or other appropriate grammatical tie-in words (e.g., “based on” rather than “according to”). Note that all three dependencies are present in the PHR-S FM ‘dependent shall’ criteria. It is the functional profile that narrows it to any one dependency or any combination of the three. Moreover, in the functional profile, the specific user role, organizational policy, and/or jurisdictional law which necessitates evoking the ‘dependent shall’ is explicitly identified.
For example: (derived from the PHR-S FM criterion above)
PHR-S FM criterion: The PHR-S **SHALL** provide the ability for PHR-S security administrators to grant authorizations in accordance with the U.S. Health Insurance Portability and Accountability Act of 1996.
The difference between a ‘shall’ criterion and a ‘dependent shall’ criterion is shown in the table below.
| ‘SHALL’ Criterion | ‘Dependent SHALL’ Criterion | |
|---|---|---|
| Must be present in the Functional Profile | Yes, either verbatim or modified (e.g., constrained or refined) | Yes, verbatim. If dependency exists, add additional criteria reflecting the dependency. |
| Implemented by EHR systems | Yes. | Situational - only implement if the dependency exists. Specifically, the PHR system does not implement the ‘dependent shall’ criterion (as copied from the PHR-S FM), but does implement additional ‘shall’ criteria created to reflect the dependency. |
Table 1: Differences between 'shall' and 'dependent shall'
The reason for using a ‘dependent shall’ in the PHR-S FM is to highlight certain criteria and bring them to the attention of the reader – both developers of functional profiles as well as other users. ‘Dependent shall’ criteria are considered to be special cases, where there are one or more dependencies that affect these criteria, across multiple care settings. Using the ‘dependent shall’ ensures that developers of all functional profiles address the criterion and consciously decide whether the criterion in question is applicable, based on the stated dependency.
Regardless of whether a dependency exists or not, the ‘dependent shall’ is copied verbatim into the functional profile. The reasons for this are:
The way to interpret and apply a ‘dependent shall’ criterion in a functional profile is as follows:
For the new criteria, add an explanation and/or citing for the dependency. For example, “Jurisdictional legal requirements for this functional profile are defined by U.S. Federal Regulations HIPAA Security Rule 45 CFR Parts 160, 162 and 164”. The explanation or citing MAY be in an appendix. It is likely that multiple criteria will reference the same explanation or citing.
Examples:
Functional Profile criteria
Dependency Explanation: *For a U.S. realm functional profile, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) as well as other jurisdictional legal requirements or other more stringent requirements would be applied to ‘dependent shall’ criteria in the functional profile.
| PHR-S FM | Dependency Applicable? | Applicability | Functional Profile |
|---|---|---|---|
| Dependent SHALL | Yes | Mandatory | Copy SHALL from the PHR-S FM |
| Mandatory | Add additional criteria to reflect the dependencies. Use ‘shall’. | ||
| Mandatory | Add explanation or citing | ||
| Optional | Add additional criteria derived from ‘dependent shall’. Use ‘shall’, ‘should’ or ‘may’. |
| PHR-S FM | Dependency Applicable? | Applicability | Functional Profile |
|---|---|---|---|
| Dependent SHALL | No | Mandatory | Copy SHALL from the PHR-S FM |
| Mandatory | Add explanation | ||
| Optional | Add additional criteria derived from ‘dependent shall’. Use ‘shall’, ‘should’ or ‘may’. |
Examples:
IG © 2023 EHR WG. Package hl7.ehrs.uv.phrsfmr2#2.0.1-ballot based on FHIR 5.0.0. Generated 2025-08-29
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change