This page is part of the FHIR Specification (v3.0.2: (v4.0.1: R4 - Mixed Normative and STU 3). ) in it's permanent home (it will always be available at this URL). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R4 R3 R2

7.10 7.11 Appendix: HL7 EHR System Functional Model and FHIR

Electronic Health Records Work Group

Maturity Level : N/A

Ballot Standards Status : Informative

IDO/HL7 ISO/HL7 10781 EHR System Functional Model Release 2 provides a reference list of functions that may be present in an Electronic Health Record System. While FHIR is an implementation focused on exchange of information in healthcare, this often happens in the context of an EHR system and EHR record. This table briefly describes one way that FHIR can be used to meet the requirements described in the EHR-S FM and is provided to help readers of the FHIR specification understand how FHIR can be used. There are many other equally valid ways to implement the EHR-S FM and to make use of FHIR.

EHR Function		FHIR Implementation Notes
TI.1	Security	FHIR defines parts of the security infrastructure, and delegates others to standard web based web-based security frameworks
TI.1.1	Entity Authentication	FHIR assumes that the users are authenticated. OAuth is the preferred mechanism
TI.1.2	Entity Authorization	FHIR does not currently provide any resources to describe or manage access-control permissions. By default, underlying web frameworks such as SAML would be used. See the security section for a discussion of binding between FHIR and SAML
TI.1.3	Entity Access Control	See above about SAML / OAuth
TI.1.4	Patient Access Management	See Security Labels
TI.1.5	Non-Repudiation	The provenance resource tracks the timestamps, actors, and digital signatures associated with resources
TI.1.6	Secure Data Exchange	TLS (https:) should be used for all production exchange of data. All conformant FHIR RESTful implementations SHALL be able to use TLS
TI.1.7	Secure Data Routing	FHIR allows for brokers and various forms of messaging that support assured destinations and delivery (also see IN.2.2 below)
RI.1.1.4	Information Attestation	See the provenance resource
TI.1.8	Patient Privacy and Confidentiality	FHIR does not include functionality related to this requirement, though implementations would be expected to provide this
RI.1.1	Health Record Information and Management	This is a core application of the FHIR capabilities
RI.1.22	Data Retention, Availability and Destruction	A FHIR RESTful server gives precise and fine-grained control of retention, availability and destruction of resources, all clearly described by the capability statement
RI.1.1.x.1	Auditable Records	FHIR provides the AuditEvent resource for auditable records.
RI.2	Synchronization	FHIR supports synchronization using standard web publication/subscription methods via Bundles . Bundle-based pub/sub may be push or pull based, and can include all resources of a particular type, or selected subsets of the resources. In addition, groups of resources can be exchanged in bundles, keeping a set of related resources in synchronization
RI.1.1.13	Extraction of Health Record Information	FHIR does not provide report formats, but does provide extensive search and retrieval functions to assist with building such reports
RI.1.1.1	Store and Manage Health Record Information	A FHIR RESTful server can store and manage health information persistently - see below for further information.
RI.1.2.1	Manage Structured and Unstructured Health Record Information	The dual contents of FHIR resources - structured data and XHTML narrative - provide seamless support for dealing with a mix of structured and unstructured information
TI.3	Registry and Directory Services	The FHIR Administration resources provide registry-based access to patients, providers, etc.
TI.4	Standard Terminologies and Terminology Services	FHIR encourages the use of standard terminologies wherever possible, and provides full support for their use through a variety of terminology related data types . FHIR defines a terminology service infrastructure . Also, see profiling , which discusses how terminology is used in a FHIR context
TI.5	Standards-based Interoperability	FHIR is a definition of a standard on which to base interoperability
TI.5.1	Interchange Standards	This is the core focus of FHIR. See below for discussion of interaction modes
TI.5.2	Interchange Standards Versioning and Maintenance	FHIR version maintenance is described here
TI.5.3	Standards-based Application Integration	FHIR enables simple integration through use of an easy to understand, use use, and debug web-based infrastructure. The same framework used within an EHR for data persistence can also offer a simple way to implement data exchange
TI.5.4	Interchange Agreements	The FHIR Conformance Statement and Resource Profile resources provide a registry based registry-based infrastructure for individual trading partner agreements, as well as for community based ones
TI.6	Business Rules Management	FHIR does not currently address this requirement at this point in time
TI.7	Workflow Management	FHIR does not currently address this requirement at this point in time, requirement, though the resources and services exist to support this functionality

The EHR system functional model describes several modes for interaction between systems. Each of these can be implemented in several different ways using FHIR

Interaction Modes	FHIR Options
Unsolicited Notifications e.g. a patient has arrived for a clinic appointment	Create/update new resource via HTTP Push resources using Bundle Send FHIR Message (if appropriate event is defined)
Query/Response e.g. Is Adam Everyman known to the system? Yes, MRN is 12345678.	Search with parameters A query message (though not defined yet)
Service Request and Response e.g. Laboratory Order for Fasting Blood Sugar and a response containing the results of the test.	Could be supported either through Messaging or SOA solutions. Request/Response support is not yet defined
Information Interchange between organizations (e.g. in a RHIO, or in a National Health System)	Pub/sub using bundles (push or pull) RESTful interface FHIR messaging
Structured / Unstructured clinical document, e.g. dictated surgical note	See the Documents

The combination of a properly secured and managed FHIR server, along with enforced use of the AuditEvent and Provenance resources ensures that the core record management functions defined in the EHR-S FM are met (as follows). See the FHIR Record Lifecycle Event Implementation Guide for additional details.

• Lifespan/Lifecycle tracking, including capturing source, origination and authorship information, along with tracking of views and exchanges
• Attestation for accuracy and completeness, along with digital signature
• A full version history with content retention
• Retention and persistence

Additional functionality, not currently defined at this point in time in FHIR, is required to ensure non-repudiation, access control, and consent tracking.