ISO 16527:2023

INTERNATIONAL ISO
STANDARD 16527
First edition
2023-10
Health informatics — HL7 Personal
Health Record System Functional
Model, Release 2 (PHR-S FM)
Informatique de santé — Modèle fonctionnel d'un système de
dossier de santé personnel, version 2 (PHR-S FM)
Reference number
© ISO 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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 at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword . vi
Introduction . viii
0.1 Notes to Readers . viii
0.2 Changes from Previous Release . viii
0.3 Background . viii
0.3.1 Personal Health Record (PHR) Versus a Personal Health Record System (PHR-S) . viii
0.3.2 Designation of Sections. ix
1 Scope . 1
1.1 PHR-S Functional Model 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 . 6
4.2.1 The Functions and Their Use . 6
4.2.2 Personal Health Section Functions . 6
4.2.3 Personal Health Support Section Functions . 6
4.2.4 Record Infrastructure Section and Trust Infrastructure Section Functions . 6
4.3 Common Major Concepts Across the Model . 7
4.3.1 Consistency in the Conformance Criteria. 7
4.3.2 PHR Account Holder Privacy . 7
4.3.3 Functionality versus Implementation . 7
4.3.4 Relevant Standards . 7
4.3.5 Consents, Authorizations, and Preferences . 7
4.3.6 Scope of Downstream Uses of PHR data. 8
4.4 Type of Profiles . 8
5 Conformance Clause . 8
5.1 Introduction (Reference) . 8
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) . 12
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 . 14
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 Domain Functional 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 . 18
5.7.6 Rules for Companion Functional Profiles. 18
5.8 Use Cases and Samples (Reference) . 19
5.8.1 Functional Profile Use Cases . 19
5.8.2 Sample Domain Functional 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
6 Glossary .24
6.1 Preface (Reference) .24
6.2 Introduction (Normative) .24
6.3 Overview (Reference) .24
6.4 The Action-Verb Structure (Normative) .24
6.4.1 Secure (System) Hierarchy .24
6.4.2 Data Management Hierarchy .25
6.4.3 How Action-Verbs are defined .26
6.4.4 Deprecated Action-Verbs .32
6.5 Guidelines for Use (Reference) .35
6.5.1 General Guidance .35
6.5.2 Constructing Rigorous Conformance Criteria .36
7 PHR System Conformance Claim via Self-Attestation .37
8 Glossary Supplement: Record Lifecycle Events and Descriptions (Normative) .37
8.1 Record Lifecycle Events (See RI.1.1.1) .37
Annex A (Normative) Function List .40
Annex B (Informative) Glossary of Terms for the EHR-S FM .41
Annex C (Informative) Background .71
C.1 What is HL7? .71
C.2 The HL7 Electronic Health Records Work Group .71
C.3 PHR WG Background and Charge .71
Annex D Bibliography .73
Annex E (Normative) Function List .74
Annex F (Informative) PHR Sources .75
F.1 Provider-linked .75
F.2 Payer-linked .75
F.3 Health Record Bank .76
F.4 Hybrid Payer & Provider Linked .76
F.5 Web-based, Consumer-centric Model .76
Annex G (Informative) Anticipated Uses .77
G.1 International Community and Realm Specifications .77
G.2 Anticipated Development Approach: Functional Profiles .77
Annex H (Informative) Mobile Device Impact on – and Issues related to – PHRs .78
H.1 Introduction .78
H.2 PHR Relationship to Mobile Devices .78
H.3 Trustworthiness of Mobile Device Information Sources .78
H.4 Possibility of Consumer Alteration of Professionally-sourced Data .78
H.5 Possibility of Other Alterations of Professionally-sourced Data .78
H.6 Possibility of Insufficient/Unexpected Governance or Management of Professionally-
sourced Data .79
H.7 Interoperability Standardization within Health Information Exchange Environments .79
H.8 Various Types of Mobile Devices .79
H.9 Functionality (or capability) –Nuances of Various Information Exchange Systems .79
H.10 Labeling of Mobile Devices (and corresponding software) as “Regulated” by the FDA .79
H.11 Amount or Type of Data .80
H.12 Future Vision .80
H.13 Location of Data-At-Rest .80
H.14 Management of lost, stolen, or misplaced mobile devices .81
H.15 Consents, Authorizations, and other Governance issues .81
H.16 Location Awareness Services .81
H.17 Use of multiple mobile devices .81
H.18 Usage heuristics .81

iv © ISO 2023 – All rights reserved

H.19 Difference Between “Patient-entered” and “Patient- sourced’ Data . 82
H.20 Difference Between “Author-of-the-data” and “Source-of-the data” . 82
H.21 Relationships between PHR, EHR, and Mobile Devices . 82
H.22 Responses to Rules-engine Requests . 83
H.23 Security and Privacy Obligations Vary Between Providers and Consumers . 83

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 document should be noted (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all
such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by HL7 (as ANSI/HL7 PHRSFM, R2-2021) and drafted in accordance with
its editorial rules. It was assigned to Technical Committee ISO/TC 215, Health informatics and adopted
under the “fast-track procedure”.
This first edition of ISO 16527 cancels and replaces the ISO/HL7 16527:2015, which has been
technically revised.
The main changes are as follows:
— updates to many functional requirements, including those relevant to:
 patient advance directives, consents and authorizations;
 PHR account management, activation, deactivation and account transfers;
 allergies, intolerances and adverse reactions;
 problem list management and integration from multiple sources;
 care plans, treatment guidelines and protocols;
 clinical decision support;
 nutrition and dietary information;

vi © ISO 2023 – All rights reserved

 health calendar;
 annotation of externally sourced information;
 record corrections and amendments;
 reduction of data duplication – same data from multiple sources;
 customized data views and reports;
 Record Infrastructure including:
 record entry management,
 lifespan and lifecycle events – fully compatible with ISO/HL7 10781 – Electronic Health
Record System Functional Model, Release 2.1;
 Trust Infrastructure including:
 authorization,
 authentication,
 access control and audit – fully compatible with ISO/HL7 10781 – Electronic Health Record
System Functional Model, Release 2.1.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

Introduction
0.1 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. The standard was updated, re-balloted,
and the comments reconciled in September 2013 resulting in Release 1, and again in 2019 resulting in
Release 2.
0.2 Changes from Previous Release
This personal health –focused standard (PHR-S FM) was developed in harmony with the clinically-focused
HL7 EHR System Functional Model (EHR-S FM). When the EHR-S FM’s layout was enhanced from Release
1 format to Release 2 format, the HL7 Personal Health Record Work Group determined to update and
harmonize the PHR-S FM from Release 1 format to Release 2 format as well. The PHR-S FM will follow the
format of the EHR-S FM with respect to the replacement of the Information Infrastructure Section with two
individual sections: the Record Infrastructure section and the Trust Infrastructure section.
0.3 Background
0.3.1 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 PHR-S-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.
viii © ISO 2023 – All rights reserved

0.3.2 Designation of Sections
The PHR-S FM (i.e., all chapters) contains normative, informative, and reference sections. In the
Conformance Clause chapter, the normative content defines how a functional profile achieves conformance to
the PHR-S FM.
INTERNATIONAL STANDARD ISO 16527:2023(E)

Health Informatics — HL7 Personal Health Record
System Functional Model, Release 2 (PHR-S FM)
1 Scope
1.1 PHR-S Functional Model 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 ought to 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 Anticipate Uses below
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 are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. 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, context and global
variations of use
3 Terms and Definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/

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
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 (e.g.,,
the text within a PHR is often displayed on a screen -- but that same text could be read aloud by an (external)
speech synthesis computer program (even though speech synthesis is not part of the PHR system, per se).
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 four sections: Personal Health, Supportive, Record Infrastructure, and Trust
Infrastructure. Functional profiles can be developed which identify various functions from one or more of these
four 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

2 © ISO 2023 – All rights reserved

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 Section 5.1). This document defines the PHR-S Functional Model and describes the
general use of profiles and priorities (see Reference Material for examples of stakeholders that might create
profiles).
Profiles
Personal Health
Supportive
Record Infrastructure and Trust
Infrastructure
Figure 1: PHR-S Function List Sections

As previously mentioned, the PHR-S FM is divided into four main sections: Personal Health, Supportive,
Record Infrastructure, and Trust Infrastructure. Within the 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.

4 © ISO 2023 – All rights reserved

PH.1.0 Account Holder Profile
PH.2.0 Manage Historical Clinical Data And Current State Data
PH.3.0 Wellness, Preventive Medicine, and Self Care
PH.4.0 Manage Health Education
PH.5.0 Account Holder Decision Support
PH.6.0 Manage Encounters with Providers
S.1.0 Provider Management
S.2.0 Financial Management
S.3.0 Administrative Management
S.4.0 Other Resource Management

RI. Record Infrastructure
TI. Trust Infrastructure
Figure 2: PHR-S Functional Outline

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.

Record and Trust
Supportive Personal Health
Infrastructure
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.
• 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 Personal Health Support 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 Record Infrastructure Section and Trust Infrastructure Section Functions
Description of Record Infrastructure section functions and the Trust Infrastructure section functions: These two
sections are copied from the EHR-S FM R2 since the record and trust requirements of health information
exchange between the personal and clinical settings overlap heavily. They offer functionality that supports the
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 a Record 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.
6 © ISO 2023 – All rights reserved

Actors for Record Infrastructure section and the Trust Infrastructure section functions: These functions are
generally performed transparently by the PHR-S on behalf of (and without intervention of) PHR-S Account
Holders and other users.
4.3 Common Major Concepts Across the Model
4.3.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 (see 6.4 The Action-Verb Structure) was established to help create
semantic harmony within the conformance criteria so that, for example, if the Personal Health section has a
conformance criterion using the Action-Verb “Update,” that term has the same meaning as in the Supportive
section’s conformance criteria.
The levels in the Hierarchy are granular and have been arranged in a parent-child relationship. For example,
the Hierarchy 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 Hierarchy, 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 Hierarchy 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.2 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 TI.1.8, Patient Privacy and Confidentiality for additional detail.)
4.3.3 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 TI.1 (Security)
and TI.2 (Auditable Records), and functions performed “by the PHR Account Holder” may be actually
performed by others as delegated by the Account Holder (see TI.1.2, Entity Authorization).
4.3.4 Relevant Standards
Relevant Standards include:
• ISO/TR 14292 "Personal health records - definition, scope, context and global variations of use”
4.3.5 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.6 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 PHR-S 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., laboratory 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 person or organization that manages or maintains the physical record. This may be 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
While consumers or patients always have the right to access 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
...