ISO/HL7 16527:2016

INTERNATIONAL ISO/HL7
STANDARD 16527
First edition
2016-04-01
Health informatics — HL7 Personal
Health Record System Functional
Model, Release 1 (PHRS FM)
Informatique de santé — Modèle fonctionnel d’un système de dossier
de santé personnel, version 1 (PHRS FM)
Reference number
©
ISO/HL7 2016
© ISO/HL7 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or
by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written
permission. Permission can be requested from either ISO or HL7 at the respective address below.
ISO copyright office Health Level Seven International
Ch. de Blandonnet 8 • CP 401 Standards Publishing Department
CH-1214 Vernier, Geneva, Switzerland 3300 Washtenaw Avenue, Suite 227
Ann Arbor, MI 48104
USA
Tel. +41 22 749 01 11 Tel. + 1 734 677 77 77
Fax +41 22 749 09 47 Fax + 1 734 677 66 22
copyright@iso.org hq@HL7.org
www.iso.org www.HL7.org
Reproduction or use may be subject to royalty payments or licensing agreements.
The Material provided with this publication is protected by copyright law. The unauthorized reproduction or distribution of the
copyright work is illegal and may be punishable by criminal law.
The license to the Material provided with this publication is limited to a personal use and includes the right to download for
study purposes only. The modification or the implementation, in whole or in part, of the software is not permitted. Under no
circumstances may it be sublicensed, copied, transferred, or placed on a network of any sort without the authorization of the
copyright owner.
Membership to HL7 is required to obtain non-exclusive, worldwide, rights to download, copy and share the Material with
employees and consultants of your company or organization for internal and study purposes, or to utilize the software for the
purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing,
and to otherwise distribute Compliant Products. Information about such membership can be obtained by contacting HL7 at the
address above.
Violators may be prosecuted.
Published in Switzerland.
HL7, CDA, CCD, and Health Level Seven are registered trademarks of Health Level Seven International Reg. U.S. Pat & TM Office.
ii © ISO/HL7 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 The Functional Model . 2
4.1 Overview and Definition . 2
4.2 PHR-S Functional Outline. 4
4.2.1 The Functions and Their Use . 4
4.2.2 Personal Health Section Functions . 5
4.2.3 Supportive Section Functions . 5
4.2.4 Information Infrastructure Section Functions . 5
4.3 Common Major Concepts Across the Model . 6
4.3.1 The “Action-Verb” Hierarchy . 6
4.3.2 Relevant Standards . 8
4.3.3 Consents, Authorizations, and Preferences . 8
4.3.4 Scope of Downstream Uses of PHR data . 8
4.4 Type of Profiles . 8
5 Conformance Clause . 9
5.1 Introduction (Reference) . 9
5.2 Scope and Field of Application (Normative) . 9
5.3 Concepts (Normative) . 9
5.3.1 Functional Profiles . 9
5.3.2 Conformance Model (Normative) .10
5.3.3 Profile Traceability (Normative) .11
5.4 Normative Language (Normative) .11
5.5 Conformance Criteria (Normative) .12
5.5.1 Introduction .12
5.5.2 Criteria in the Functional Profile .12
5.5.3 ‘Dependent SHALL’ Criteria .12
5.5.4 Referencing Other Criteria or Functions .12
5.6 PHR-S FM Structure and Extensibility (Normative) .13
5.6.1 Hierarchical Structure .13
5.6.2 Naming Convention .13
5.6.3 Priorities .14
5.6.4 Extensibility .14
5.7 Functional Profile Conformance (Normative) .14
5.7.1 Introduction .14
5.7.2 Rules for Functional Domain Profiles .14
5.7.3 Rules for Creating New Functions in Functional Profiles .16
5.7.4 Rules for Derived Functional Profiles .17
5.7.5 Conformance Statement .17
5.7.6 Rules for Functional Companion Profiles .18
5.8 Use Cases and Samples (Reference) .19
5.8.1 Functional Profile Use Cases .19
5.8.2 Sample Functional Domain Profile Conformance Clauses .20
5.9 Interpreting and Applying Conditional ‘SHALL’ (Reference) .21
5.9.1 Construction of Conformance Criteria Using the Conditional ‘SHALL’ Overview .21
5.9.2 General Concepts .21
5.9.3 Rationale for ‘Dependent SHALL’ .22
5.9.4 How to Apply the ‘Dependent SHALL’ .22
Annex A (normative) Function List .25
© ISO/HL7 2016 – All rights reserved iii

Annex B (informative) Glossary .27
Annex C (informative) PHR Sources .54
Annex D (informative) Anticipated Uses .57
Annex E (informative) Mobile Device Impact on, and Issues related to, PHRs .58
Annex F (informative) Background .64
Annex G (informative) Acknowledgements .65
Bibliography .66
iv © ISO/HL7 2016 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 215, Health informatics.
© ISO/HL7 2016 – All rights reserved v

Introduction
Notes to Readers
The HL7 Personal Health Record System Functional Model (PHR-S FM) was approved as a Draft Standard
for Trial Use (DSTU) in July 2008. In September 2010 the PHR-S FM was presented to ISO TC215 as a
New Work Item Proposal (NWIP) ballot and received comments from the international community. The
comments from that ballot were used to update and improve the draft standard. In September 2013,
the standand was updated, re-balloted, and the comments reconciled – resulting in the current version.
Information about HL7 is given in Annex F.
Changes from Previous Release
Not Applicable for Release 1.
Background
Personal Health Record (PHR) Versus a Personal Health Record System (PHR-S)
The PHR WG makes a clear distinction between a PHR and a PHR System (PHR-S). The PHR is the
underlying record (e.g. data, information, pictures, sounds, graphs, or videos) that the software
functionality of a PHR-S maintains. There has been much discussion surrounding the definition of a
personal health record. The PHR-S FM does not attempt to define the PHR, but rather to identify system
features and functions necessary to create and effectively manage PHRs. The PHR-S FM offers examples
of data elements, but is not intended to provide details necessary to specify a data model.
The overarching theme of a PHR-S involves a patient-centric tool that is controlled, for the most part, by
the individual PHR Account Holder. A PHR-S should be immediately available electronically and able to
link to other systems. The PHR-S provides functionality to help an individual maintain a longitudinal
view of his or her health history, and may be comprised of information from a number of sources –
e.g. from providers and health plans, as well as from the individual. Data collected by the system is
administrative and/or clinical, and the tool may provide access to health-related forms (e.g. Advance
Directives) and advice (e.g. diet, exercise, or disease management). A PHR-S might also help the
individual collect behavioral health, public health, patient-entered and patient-accessed data (including
medical monitoring devices), medication information, care management plans and the like, and might be
connected to providers, laboratories, pharmacies, nursing homes, hospitals and other institutions and
clinical resources. This PHRS-FM is universal and therefore generic by design. There may be additional
constraints in certain realms or regions. For example, in the US Realm, the management of laboratory
results is subject to the Clinical Laboratory Improvement Amendments (CLIA) federal regulation.
At its core, the PHR-S should provide the ability for the individual to capture and maintain demographic,
insurance coverage, and provider information. It should also provide the ability to capture health history
in the form of a health summary, problems, conditions, symptoms, allergies, medications, laboratory
and other test results, immunizations and encounters. Additionally, personal care planning features
such as Advance Directives and care plans should be available. The system must be secure and have
appropriate identity and access management capabilities, and must use standard nomenclature, coding
and data exchange standards for consistency and interoperability. A host of optional features have
been addressed over the course of this initiative, including secure messaging, graphical presentation
of test results, patient education, guideline-based reminders, appointment scheduling and reminders,
drug-drug interactions, formulary management, health care cost comparisons, document storage and
clinical trial eligibility.
The effective use of a PHR-S is a key point for improving healthcare in terms of effective self-
management, patient-provider communication and quality objectives.
vi © ISO/HL7 2016 – All rights reserved

INTERNATIONAL STANDARD ISO/HL7 16527:2016(E)
Health informatics — HL7 Personal Health Record System
Functional Model, Release 1 (PHRS FM)
1 Scope
The HL7 PHR-S FM defines a standardized model of the functions that may be present in PHR Systems.
It is beyond the scope of the PHR system to control the use (or intended use) of PHR data. On the
contrary, it is within the scope of the PHR system to manage the authorization of an individual (or
other application). Those parties are then responsible for using the data for appropriate (or intended)
purposes. The system manufacturers specify “intended and permitted use of PHR data” in their Terms
of Service and Terms of Use agreements.
This Functional Model is not:
• a messaging specification;
• an implementation specification;
• a conformance specification;
• a specification for the underlying PHR (i.e. the record itself);
• an exercise in creating a definition for a PHR;
• a conformance or conformance testing metric;
• a requirement specification for a single PHR system (see Annex D, Anticipated Uses).
The information exchange enabled by the PHR-S supports the retrieval and population of clinical
documents and summaries, minimum data sets, and other input/outputs.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/TR 14292:2012, Health informatics — Personal health records — Definition, scope and context
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
base functional profile
existing functional profile from which new (child) functional profiles are created/derived
3.2
conformance
fulfillment of a product, process, or service of specified requirements
3.3
conformance criteria
requirements indicating the behavior, action, or capability that constitutes implementation of the
function
© ISO/HL7 2016 – All rights reserved 1

3.4
conformance clause
section of a specification that defines the requirements, criteria, or conditions to be satisfied in order to
claim conformance
3.5
conformance statement
description of the function in a PHR system that has been implemented. It reflects the degree to which
a PHR system has met the functional profile’s requirements and may include optional functions and
information
3.6
derived functional profile
functional profile that is created from a base functional profile, also known as a child functional profile
3.7
extension
ability for a PHR-S to incorporate additional functionality beyond what is defined in a functional profile
3.8
functional profile
subset of the PHR-S FM in which functions have been designated (sometimes in varying degrees) for
certain PHR systems or sources or level of functionality
3.9
informative functional profile
registered functional profile that has successfully completed formal public scrutiny via the HL7
consensus process
3.10
inherited criterion
conformance criteria listed in a header function that will be inherited by all its children functions, and
conformance criteria listed in a parent function that are inherited by all its children functions
3.11
registered functional profile
functional profile that has successfully completed HL7 EHR WG registration process and review
3.12
situational criterion
criterion that is required if the circumstances given are applicable
4 The Functional Model
4.1 Overview and Definition
The PHR-S FM is divided into three sections: Personal Health, Supportive, and Information
Infrastructure. Functional profiles can be developed which identify various functions from one or more
of these three sections in order to describe a given system, and allows for further characterization
of that profile by the assignment of priorities to each function in the profile (see Figure 1). While the
PHR-S FM should contain all reasonably anticipated PHR-S functions, it is not intended to comprise
the entire list of all functions that may be found in any specific PHR-S. Again, functional profiles will
be developed to constrain the functions for an intended use [see 5.1, Introduction (Reference)]. This
document defines the PHR-S Functional Model and describes the general use of profiles and priorities
(see Annex C, PHR Sources, for examples of stakeholders that might create profiles).
2 © ISO/HL7 2016 – All rights reserved

Figure 1 — PHR-S FunctionList Sections
As previously mentioned, the PHR-S FM is divided into three main sections: Personal Health, Supportive,
and Information Infrastructure. Within the three main sections are a number of subsections (parent-
child relationships). Each subsection is comprised of a number of individual functions. Functions
describe the behavior of a system in consumer-oriented language and are intended to be recognizable
to all key stakeholders of a PHR-S. Each function contains a Function Name, Function Statement,
and Conformance Criteria (which are “normative” in an ANSI-accredited standard) as well as other
associated information such as Description (which is reference information and is not a normative part
of the ANSI-accredited standard).
The numbering of the functions maintains parent-child relationships between the sections and
subsections (e.g. “PH.1.1 Account Holder Profile” is the parent of child “PH.1.1.1 Identify and Maintain
a Patient Record”). In many cases the parent is fully expressed by the children (see Figure 2). In the
aggregate, the PHR-S Functional Model is intended as the superset of functions from which a subset
can be derived by a Stakeholder Community to illustrate what they need in a PHR-S for their setting.
Only a subset of this inclusive set of functions (one or more PHR-S Functional Profiles) will apply to any
particular PHR-S implementation.
© ISO/HL7 2016 – All rights reserved 3

Figure 2 — PHR-S Functional Outline
4.2 PHR-S Functional Outline
4.2.1 The Functions and Their Use
The PHR-S Functional Model 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.
4 © ISO/HL7 2016 – All rights reserved

• 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-S.
• Establish a standards-based method by which each realm (country) can apply these PHR-S functions
to care settings, uses, and priorities.
• Inform those concerned with new, additional, or other use of PHR data and national infrastructure
what functions can be expected in a PHR-S.
4.2.2 Personal Health Section Functions
Description of Personal Health section functions: The Personal Health (PH) section functions are the
subset of PHR-S functions that manage information and features related to self-care and provider based
care over time. PH section functions can yield a summary record of an individual’s care, including ad
hoc views of the overall PHR.
Example of a Personal Health section function: A function to ensure that the individual PHR Account
Holder’s demographic information is captured and maintained so that the individual is unambiguously
identified.
Actors for Personal Health section functions: As the subject of PHR information, the PHR Account Holder
is the principal user of PH section functions.
4.2.3 Supportive Section Functions
Description of Supportive section functions: The Supportive section functions are the subset of PHR-S
functions that assist the PHR Account Holder with administrative and financial requirements. Also
included are PHR-S functions that provide input to systems that perform clinical research, promote
public health and seek to improve the quality and outcome of health care delivered.
Example of a Supportive section function: A function that will electronically query local immunization
registries to ensure that a person is currently registered and determine the person’s immunization status.
Actors for Supportive section functions: The PHR Account Holder is the principal user of Supportive
section functions, but under certain circumstances, health care providers might be expected to perform
various Supportive section functions.
4.2.4 Information Infrastructure Section Functions
Description of Information Infrastructure section functions: The Information Infrastructure section
consists of PHR-S functions that support Personal Health and Supportive section functions. These
functions ensure that the PHR-S provides information privacy and security, interoperates with other
information systems (including PHR and EHR systems), and helps make PHR-S features accessible and
easy to use.
Example of an Information Infrastructure section function: A function to ensure that PHR data, such as
an immunization record, can only be viewed and updated after an individual or system authenticates
the user’s identity within the PHR-S.
Actors for Information Infrastructure section functions: Information Infrastructure section functions
are generally performed transparently by the PHR-S on behalf of (and without intervention of) PHR-S
Account Holders and other users.
© ISO/HL7 2016 – All rights reserved 5

4.3 Common Major Concepts Across the Model
4.3.1 The “Action-Verb” Hierarchy
4.3.1.1 Consistency in the Conformance Criteria
Within the authoring group, there was an intentional effort to create language consistency in the
conformance criteria. The “Action-Verb” Hierarchy diagrams below are used to create semantic
harmony within the conformance criteria so that, for example, if the Personal Health Chapter has a
conformance criterion using the Action-Verb “Update,” that term has the same meaning as in the
Supportive Chapter’s conformance criteria.
The levels in the hierarchy are granular and have a parent-child relationship. For example, the diagram
below reveals that the “Capture” of information covers local data entry (“Enter”) and importation
of data from an external source (“Import”). Similarly, under the “Maintain” section of the diagram,
the term “Store” could invoke Action-Verbs listed below it. If the parent term is not used, then the
respective verbs in the child will be cited individually in the criterion. If the term “Manage” is used,
all of the applicable Action-Verbs included in the table are encompassed in that criterion. Authors are
responsible for determining whether one or more of the sub-verbs are appropriate for a given function
and must write conformance criteria that constrain the use of the Action-Verb hierarchy according to
the intent of the profile being created.
4.3.1.2 The “Secure (System)” Category
The Secure System Category provides Action-Verbs for controlling access (authenticating and
authorizing users), tracking activities (logging and auditing), and sustaining operations. This category
has one parent, Secure (System), and three (3) intermediate children: Control Access, Track, and Sustain
(Operations).
Figure 3 — Secure (System)
4.3.1.3 The “Manage (Data)” Category
The data management Category provides Action-Verbs for the complete range of data handling actions
by a system. The category has one parent, Manage (Data), and six (6) children with subsets: Capture,
Maintain, Render, Exchange, Determine, and Manage-Data-Visibility.
6 © ISO/HL7 2016 – All rights reserved

Figure 4 — Manage (Data)
The hierarchical principle above was applied during the development of the PHR-S FM. The Action-
Verbs and other terms used in the model are found in the model’s Glossary (see Annex B). It is important
to be consistent in the terminology used in the PHR-S FM conformance criteria to ensure consistent
interpretation.
4.3.1.4 PHR Account Holder Privacy
It is the bias of this Model that consumer privacy rights be protected to the fullest extent possible.
However, as an international model that attempts to describe functionality for many PHR system sub-
types (e.g. integrated PHR/EHR systems, stand-alone PHR systems, or vendor-provided Web-based
systems), statements concerning consumer control over information are frequently tempered by the
phrase (with some variations) “in accordance with user role, organizational policy, or jurisdictional
law.” This phrase does not extend license to institutions to violate individual rights, but acknowledges
that legitimate exceptions may exist to the general rule of PHR Account Holder control over their PHR
information. In all cases, the model requires that the privacy policy of a PHR system be fully transparent
to PHR Account Holders, and that a PHR-S has the ability to capture a PHR Account Holder’s consent on
how his or her personal information may be used and disclosed (see functions in IN.3.8, Patient Privacy
and Confidentiality for additional detail.)
4.3.1.5 Functionality versus Implementation
It is important to note that many functions provide the capacity for functionality (e.g. provide
for standards-based interoperability), but do not give implementation details. A function, when
implemented, must be implemented within the context of the entire PHR-S FM. For example,
implementation of many functions throughout the model are expected to conform to the security and
audit functions found within IN.3 (Security) and IN.4 (Auditable Records), and functions performed “by
the PHR Account Holder” may be actually performed by others as delegated by the Account Holder (see
IN.3.2, Entity Authorization). Examples of PHR implementation contexts within the Mobile Device space
can be found in Annex E, Mobile Device Impact on, and Issues related to, PHRs.
© ISO/HL7 2016 – All rights reserved 7

4.3.2 Relevant Standards
Relevant Standards:
• ISO/TR 14292 “Personal health records - definition, scope, context and global variations of use”
4.3.3 Consents, Authorizations, and Preferences
Consumers may desire to declare a consent, authorization, or preference differently in the PHR-S
context than in the EHR-S context. The method of handling consents, authorizations, or preferences is
not addressed by the PHR-S FM. Rather, such issues ought to be addressed during implementation. For
example, such functionality could be implemented in a “services-aware” fashion if desired (for example,
as a smart-cloud-type-query). Differences between multiple versions of consents, authorizations, or
preferences may be best adjudicated by humans. The state of the art may not yet be adequate to handle
such adjudication computationally.
4.3.4 Scope of Downstream Uses of PHR data
The PHR-S FM currently only envisions privacy, security, and confidentiality measures that extend to
the initial PHR data-exchange recipient and not to (possible) subsequent recipients of the PHR data that
might be passed on by the initial data-exchange recipient.
This PHRS-FM is universal and therefore generic by design. There may be additional constraints
in certain realms or regions. For example, in the US Realm, the management of laboratory results is
subject to the Clinical Laboratory Improvement Amendments (CLIA) federal regulation.
4.4 Type of Profiles
Characterization of a PHR profile based on its attributes:
• Scope and nature of content
Some PHR systems do not contain any patient clinical data, but just have consumer health
information, personal health journals, or information about benefits and/or providers.
Of those PHR systems that have clinical information, some are populated by EHRs, some are disease
specific, some include just specific subsets (e.g. lab reports), and some are comprehensive.
• Source of information
Data in PHR systems may come from the consumer, patient, caregiver, healthcare provider, payer,
or all of these.
• Custodian of the record
The physical record may be operated by a number of parties, including the consumer or patient, an
independent third party, a healthcare provider, an insurance company, or an employer.
• Data storage
Data may be stored in a variety of locations, including an Internet-accessible database, a provider’s
EHR-S, the consumer/patient’s home computer, a portable device such as a smart card or thumb
drive, or a privately maintained database.
• Degree of Interoperability
PHR system may be stand-alone or be interoperable with other EHRs/PHRs or somewhere in
between.
• Party controlling access to the data
8 © ISO/HL7 2016 – All rights reserved

While consumers or patients always have access to their own data, they do not always determine
who else may access it. For example, PHRs that are “views into a provider’s EHR” follow the
access rules set up by the provider. In some cases, consumers do have exclusive control.
5 Conformance Clause
5.1 Introduction (Reference)
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:
a) This conformance clause defines what it means to conform to the PHR-S FM.
b) Conformance to the PHR-S FM is defined for functional profiles. A PHR system (PHR-S) does not
directly conform to the PHR-S FM, rather it conforms to one or more functional profiles.
c) Conformance criteria are associated with every function in the PHR-S FM.
d) This conformance clause does not specify testing or validation procedures to determine whether a
PHR-S conforms to a functional profile or whether a functional profile conforms to the PHR-S FM.
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.
5.2 Scope and Field of Application (Normative)
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:
• The purpose, structure, and use of conformance criteria that are to be included in the PHR-S FM and
conforming functional profiles,
• The rules for defining conforming functional profiles of the PHR-S FM,
• The relationship between functional profiles and PHR systems,
• Sample conformance clauses and use case scenarios,
• Guidance on the conformance requirements that a functional profile might levy on PHR systems,
• Guidance on the purpose and use of a PHR system Conformance Statement.
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.
5.3 Concepts (Normative)
5.3.1 Functional Profiles
Creating a functional profile is a method for defining subsets of the PHR-S FM. A functional profile
is a specification which uses the PHR-S FM 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
© ISO/HL7 2016 – All rights reserved 9

on scope or nature of information such as chronic conditions). See 5.8.1.3, Figure 8, for examples of
functional profile types.
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, Employer or Payer).
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.
There are two types of functional profiles: Domain Profile and Companion Profile. The Functional
Domain 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 Functional Domain 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 Functional Companion Profiles is a type of
profile that must be paired with one or more Domain Profiles. The purpose of a Companion Profile is to
add unique features to a PHR System, such as for research 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.
There is one type of mandatory inheritance in the PHR-S FM. All criterion listed in a parent function
will be applicable to all the children of that parent function.
A formal process exists for registering and balloting functional profiles. Functional profiles that are
submitted to the HL7 EHR WG with an attestation of conformance to Section 5, Conformance Clause, of
the HL7 PHR-S FM Standard and successfully complete review by the WG are designated as “Registered
functional profiles”. Registered functional profiles that undergo formal public scrutiny via the HL7
consensus process as an Informative EHR WG ballot at the WG level will be designated as HL7 Informative
functional profiles. HL7 Informative functional profiles are eligible to undergo full membership ballot
via the HL7 consensus process.
5.3.2 Conformance Model (Normative)
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 (1) directly to the PHR-S FM or (2)
to another conforming functional profile. A PHR system does not conform directly to the PHR-S FM;
rather, it conforms to a 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
profiles. A PHR system cannot claim conformance to a companion profile only. Figure 5 illustrates this
relationship.
10 © ISO/HL7 2016 – All rights reserved

Figure 5 — Conformance Relationships
5.3.3 Profile Traceability (Normative)
Functional profiles allow for added specificity and extensibility to the FM with changes allowed to the
base FM functions and criteria. However, 5.7, Functional Profile Conformance, 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 for derived profile are needed to reflect
care setting, regulatory, technology changes – or a future new release of the FM.
5.4 Normative Language (Normative)
The following keywords (i.e. normative verbs) SHALL be used to convey conformance requirements.
• SHALL – to indicate a mandatory requirement to be followed (implemented) in order to conform.
Synonymous with ‘is required to’.
...