FHIR Profiles

FHIR Profiles, Extensions
ValueSets, Conformance &
(Manyslidesadaptedfrompresentationby
EwoutKramer)
DavidHay
ProductStrategist
FMGco-chair
www.fhirblog.com

• Copyright © 2012 Orion Health™ group of companies • All rights reserved
The need for Profiles
• Many different contexts in healthcare, but a single set of
Resources
– A desire to keep the resources manageable
• Need to be able to:
– Describe restrictions based on use and context
– Support elements not in the core resource
• Allow for these usage statements to:
– Authored in a structured manner
– Published in a repository
– Discoverable at Design and Run-time
– Used as the basis for validation, code, report and UI generation.
2

Profiling a resource. For example...
3
Demand that the identifier uses your
national patient identifier
Limit names to just 1 (instead of 0..*)
Limit maritalStatus to another set of
codes that extends the one from
HL7 international
Add an extension to support
“RaceCode”
Note: hardly any
mandatory
elements in the

Capabilities of Profiles
• Descriptive
– Information about the Profile (what, why, who)
• Extending a resource
– Adding new properties
– Same capabilities as existing ones
• Constraining a resource
– Specifying datatypes for an element
– Modifying datatypes (eg translations)
– Defining terminology bindings
– Specifying multiplicity (eg make an element required)
– Further refining repeating values (‘Slicing’)
• Example of Composition.section (Document)
– Cannot specify default values for resource instances
• Everything explicit in an instance

Structured & published
• A Profile is just a “normal” Resource
• Any FHIR server could serve Profiles (just like Patients, Observations,
etc…)
• So, any FHIR server is a profile repository!
• A profile is simply referred to by its URI:
– Like any other resource
• e.g. http://hl7.org/fhir/Profile/iso-21090
– Extensions in an ‘instance’ of a resource refer to the profile that defined
them using the URI
– Need to think about re-usability when designing profiles
5

Who publishes?
http://www.hl7.org/fhir/Profile/iso
-21090
http://www.hl7.nl/fhir/Profile/patie
nt-nl
http://www.health4all.org/fhir/Pro
file/

Using profiles
• If we are a server then a client can read our conformance
resource, which will list the profiles we support, and provide a link
to them.
– Conformance also has other functions like specifying supported resources,
operations on those resources & interoperability paradigms
• If we are a client, we can tell a server that we conform to a profile
using a tag (the server will probably still check).
– We could also ask a server just to validate
– Could set up ‘distributed’ validation with (eg) National Validation servers
used by local/regional servers
• If we receive a resource with an extension we don’t recognize, it
will point to the profile in which it is described so we can decide
what to do with it.
– Note that a single resource can reference different profiles
7

Tags
• Contain metadata about resources
• Used for different purposes:
– Compliance to Profile
– Security – e.g. sensitivity of resource
– Indicate Document/Message
– User defined
• Transported in different ways:
– REST – as an HTTP header
– In a bundle (document, message, transaction) - in the feed.category
element

What’s in a profile, and its relationships?
9
Descriptive
Identifier
Name, Version
Publisher
Description, Code
Status
Date (of publication)
Resource and
Datatype
Constraints
Extension
Definition
Conformance
(server)
Resource
(via Tag)
ValueSet
ValueSet
Extension in
Resource
Tag

Scale / design
• Make a profile with just extensions
• Make a profile with just 1 resource + extensions on that
resource
• Make a profile with all (say national) resources + extensions.
10

Profile Descriptive information
• To describe the purpose of the Profile
• To help with location
• Details
– Identifier: Universally unique identifier, assigned by author value=“urn:hl7.org:extensions:iso-21090“
or “2.16.840.1.113883.10.20.2.1”
– Version: Version of the profile, manually maintained by author. Suggested format: a timestamp (e.g.
2013-01-01T12:34:45)
– Name: Free natural text name (e.g. “Extensions to support Orion Medications”)
– Publisher: organization or individual responsible for publishing. Should be populated (e.g. “FHIR
Project Team“)
– Telecom: one or more contact points of the publisher (telephone, email, website etc)
– Description: longer description of the contents of the profile
– Code: one or more coded descriptions to help with finding the profile
– Status (fixed choice of draft, active, retired) + experimental Y/N
– Requirements: scope & usage (the “need” or “why” of the profile)
– Date (of publication), e.g. “2013-07-07"
11

Constraining Structures
• Defining terminology bindings
• Specify element datatypes
• Further refining repeating values (‘Slicing’)
• Specifying multiplicity
From the spec
Possibilities

Profile example
Medication.code with a defined valueset

Profile Example
• MedicationPrescription.asNeeded required, and must be
boolean

Slicing
• Constraining an element with 0..* , 1..*
• FHIR Document as an example
• Composition resource is the CDA Header equivalent
– Composition.section is 0..*
– A CCDA equivalent profile might specify the sections allowed
• Different document types would have a profile

Extensions
• Resources design for the 80% - Allow easy extension for the
remaining 20% of elements
• Note - You’re not extending a resource per se, but you
specify its characteristics and where an extension may
occur:
– A specific element within a resource
– A specific element within a datatype
– All elements referencing a datatype
– All elements mapping to a specific mapping target
– An extension

Extension definition
17
Note: multiple
contexts!

An Extension in a resource
18

The need for Governance
• Profiles & extensions allow a user to customize their use of
FHIR
• With great power...

Appendix
Associated Resources

ValueSets
• A “true” FHIR ValueSet resource (may be version specific)
• A general reference to some web content that defines a set
of codes. (e.g. mime types).
• A textual description of the possible codes
21

Conformance resource
• Allows a server to indicate:
– Metadata about the server
– The resources they support
– The paradigms they support
• REST, messaging, services
– The queries against those resources
– Specific (custom) queries
– The profiles it supports
• Is a normal resource
– Supports discoverability (think UDDI for SOAP)

FHIR Profiles

More Related Content

What's hot

Similar to FHIR Profiles

More from David Hay

Recently uploaded

FHIR Profiles

Editor's Notes