Claude Nanjo will be providing an introduction to the FHIR model and its metamodel including the resources which make up the FHIR model, the core datatypes, and ways the model can be extended to capture the expressivity required by the clinical domain.
2. What is FHIR
FHIR is
● A resource-oriented RESTful API
● A metamodel
● An extensible model
3. The bigger picture - an example
Electronic Health
Record System
(EHR)
Health Application
An application is invoked based on a trigger event in
the clinical workflow
The application invokes the EHR’s FHIR API to get
patient data
The application returns a recommendation that is
persisted in the EHR
FHIR
messages are
exchanged
during these
calls
4. The bigger picture - HTN management
Electronic Health
Record System
(EHR)
Blood Pressure
Management
Application
On opening the patient’s chart, trigger call to blood
pressure management app (patient, encounter, current
user)
Get patient’s blood pressure goal, blood pressure,
current medications, problem list
Recommend modifications to the patient’s current HTN
medication regimen
5. Assumption
The EHR system and the application agree on the message payload and the
API. That is, they agree on:
● The syntax and structure of the messages exchanged
● The semantics of the message
6. What if I want to use my application on another EHR?
1. Both parties agree to a common specification - point-to-point
2. Both parties decide to adhere to a common standard
a. Allows ‘application portability’ - the application can be used with any EHR that
understands the standard
7. Is FHIR that common standard?
Yes (but with a caveat)
8. FHIR defines an API
CRUD + Search
Resource-Oriented RESTful API
Fairly complete
Can be extended
9. FHIR also specifies a health information model but ...
The model only represents the resources and attributes that are found in the
most prevalent health IT systems (known as the 80/20 rule)
The model is therefore extensible/configurable to support use cases that
extend beyond this core set of models
But the model can be extended in different ways by different
stakeholders
12. Syntax Examples
read
GET [base]/[type]/[id] {?_format=[mime-type]}
vread
GET [base]/[type]/[id]/_history/[vid] {?_format=[mime-type]}
Update
PUT [base]/[type]/[id] {?_format=[mime-type]}
PUT [base]/[type]/?[search parameters]
16. Next steps
We will learn more about:
1. Health information models
2. The FHIR model
3. The FHIR metamodel
4. How to extend FHIR
17. What is a Health Information Model?
It consists of the classes, the properties of those classes, the relationships that
exist between these classes and the constraints and rules needed to support
the exchange of health information.
A core aim of the FHIR standard is to support the specification of a
computable, shareable, and semantically precise representation of health
information.
18. Where can I find the latest stable model (FHIR R4)
http://hl7.org/fhir/
21. How is the FHIR health information model represented?
1. Visually
a. Generally as a UML-like diagram or as a tree-like structure
2. In a computable form using the FHIR meta-modeling language
a. Via the StructureDefinition, ElementDefinition, and ValueSet classes
b. Authors typically use an Excel spreadsheet to define or update a model
24. A little more about modeling - some concepts
Resources in FHIR are classes
Classes represent concepts relevant to health care such as a procedure or a
medication
Classes have attributes/properties/fields - e.g., a procedure may have a code, a
performer, and a performedDateTime
Attributes have types and cardinality - e.g., performedDateTime is of type
DateTime, and its cardinality is 0..1 meaning that it is optional.
30. ‘Concept’ Types
The following types have special meanings:
1. code - an enumerated type
2. Coding - a reference to a concept in a terminology or ontology
3. CodeableConcept - a set of references to synonymous concepts in one or
more terminology or ontology
Unlike ‘string’, concept types point to elements in a formal vocabulary
(controlled terminology, thesaurus, or ontology)
32. About cardinalities
0..1 - Optional and no more than one
1..1 - Required and no more than one
0..* - Optional and collection type
1..* - Required and collection type
-----------------
0..0 - Constrained out
m..n - Not less than m and not more than n
39. Extensions on Extensions
Person
url: citizenship
(Extension)
url: country
value: CodeableConcept
(Extension)
url: obtainedOn
value: Date
(Extension)
41. How can one specialize FHIR resources?
By using a mechanism called ‘FHIR Profiles’
42. FHIR Profiles
FHIR profiles allow a modeler to:
● Add new attributes to a FHIR resource
● Remove attributes from a FHIR resource
● Constrain the definition of specific parts of the FHIR model
43. Important constraint types
● Type constraints: e.g., constrain an integer type to a positiveInt
● Choice constraints: e.g., reduce the options available for a choice type
● Reference constraints: e.g., reduce the options available for a reference
type
● Cardinality constraints:
○ Constraint out: 0..0
○ Make mandatory: 0..1 -> 1..1 (the reverse is illegal)
○ Specify other lower and upper bound: 0..* -> 3-5 (not common)
● Terminology constraints (a type of range constraint)
○ All procedure codes must be descendants of the SNOMED CT Procedure code.
○ The category codes must be one of the following five codes {A,B,C,D,E}
○ Often referred to as ‘value set constraints’
● Slicing constraints - more on that later
44. Profiles at a high level
Procedure
code: CodeableConcept [0..1]
status: code [1..1]
category: CodeableConcept [0..1]
statusReason: CodeableConcept
[0..1]
LaboratoryProcedure
(profile)
code: CodeableConcept [1..1]
Bound to MyLaboratoryProcedureValueSet
statusReason: CodeableConcept
[0..0]
specimen: CodeableConcept
[1..*] - an extension
45. Slicing
Slicing allows modelers to turn a collection into a set of attributes with
different cardinalities
Extensions are the most common example of slicing
46. An example using Extension
FHIR defines a DomainResource attribute called extension: Extension 0..*
● All resources inherit this attribute
● It is a collection (0..*)
● It is essentially a name (really a URL)-value pair
● The name (url) is the attribute name
● The value is the attribute value
● What distinguishes each attribute derived from a slice from one another
is the URL (name)
● The URL is called the discriminator and is used to determine the slices in
this collection
48. The FHIR Metamodel
● StructureDefinition - used to define resources and their
specializations/constraints
● ElementDefinition - used to define and/or constrain attributes in a
resource
● ValueSet - used to define the sets of allowed values for concept types
○ May be used to define the rules to generate the set: e.g., all medications that are
beta-blockers
○ May specify each member of the set by explicitly enumerating them.
○ Can be built using a combination of the two approaches: e.g., ValueSetC = ValueSetA U
ValueSetB
49. Ensuring interoperability with FHIR
FHIR can be extended and constrained using FHIR profiles
This can be done in many ways
To support interoperability, a community must agree on a specific set of FHIR
profiles and FHIR API calls that it wishes to support
A FHIR Implementation Guide (IG) expresses such a specification.
IGs provide guidance to a community on the definitions of message payloads
(FHIR profiles and extensions), FHIR API calls (operations and search params),
terminologies, and other requirements that are necessary for a given use.
50. US Core
Base IG for interoperability in the US
Defines minimum conformance requirements for accessing patient data
http://hl7.org/fhir/us/core/STU3/