FHIR Profiles

FHIR Profiles, ExtensionsValueSets, Conformance

&(Many slides adapted from presentation

by Ewout Kramer)

David HayProduct Strategist

FMG co-chairwww.fhirblog.com

Page 2 • 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 core spec!


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

http://hl7.org/fhir/Profile/iso-21090

http://hl7.org/fhir/Profile/iso-21090


Who publishes?

http://www.hl7.org/fhir/Profile/iso-21090

http://www.hl7.nl/fhir/Profile/patient-nl

http://www.health4all.org/fhir/Profile/


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

IdentifierName, VersionPublisherDescription, CodeStatusDate (of publication)

Resource and Datatype Constraints

Extension Definition

Conformance(server)

Resource (via Tag)

ValueSetValueSet

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

16

(c) 2012 HL7 International

04/12/2023


Extension definition

17

Note: multiplecontexts!


An Extension in a resource

18


The need for Governance

• Profiles & extensions allow a user to customize their use of FHIR

• With great power...


AppendixAssociated 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)

Healthcare

FHIR Profiles