Introduction to FHIR and profiling


Introduction


In this module we will give you a general introduction to FHIR and profiling. This module does not contain any exercises as it is meant as a general introduction into FHIR and profiling. Continue with the Start Profiling module and follow the exercises of this module to actually start profiling yourself.

The topics covered in this module are:

  • An introduction to FHIR resources
  • An explanation of the conformance layer, including structure definitions
  • What is profiling, why should you care about profiling and what can be profiled
  • Using derived or layered profiles for optimal reusability

Reading material


1. Introduction to FHIR

Before jumping into profiling a short introduction to FHIR is in order. This section contains a short introduction to FHIR and FHIR resources.

HL7 FHIR is an international standard for digital data exchange in healthcare. FHIR stands for Fast Healthcare Interoperability Resources. The base FHIR specification describes a set of base resources, frameworks and APIs that are used in many different contexts in healthcare.

The FHIR specification is a “platform specification”, which means that it creates a common platform on which a variety of different solutions are implemented. The FHIR specification is designed to be adapted to particular contexts of use:

  • Rules about which resource elements are or are not used, and what additional elements are added that are not part of the base specification.
  • Rules about which API features are used, and how.
  • Rules about which terminologies are used in particular elements.
  • Descriptions of how the Resource elements and API features map to local requirements and/or implementations.

1.1 FHIR Resources

FHIR Resources are FHIR’s unit of exchange. They have defined behavior and meaning as well as a known identity and location. Some examples of resources are Patient, Appointment, Medication and Practitioner. All resources are listed here: http://hl7.org/fhir/resourcelist.html

A resource consists of the following parts:

  • Metadata – the metadata of a Resource provides technical and workflow context to the resource, such as a version ID or the last update time.
  • Narrative – a description of the Resource that is readable in “human” language.
  • Extension – sometimes the provided Resource needs to be extended with additional information for use in a particular context. For example, the religion of a patient is registered in some countries, while other countries do not register this information. The Patient Resource does not include the element religion, but can be extended by the patient-religion extension.
  • Elements – these are the properties or attributes of the Resource. Elements of the Patient Resource are for example: name, gender and birthDate.
  • Data types – an element has a specific data type. For example the datatype HumanName is used for the element name and the datatype date is used for the element birthdate.

A collection of Resources can be “bundled” into a single instance with containing context. These resource bundles are useful for a variety of reasons, such as returning a set of resources that meet some criteria as part of a server operation. Bundle itself is also a Resource.

A resource’s identity consists of the endpoint, the resource type and the logical ID of the resource. This is in fact a URL that you can paste in a browser.

1.2 Conformance layer

Because of its general nature and wide applicability, the rules made in the FHIR specification are generally fairly loose. As a consequence, different applications may not be able to interoperate, because of how they use optional features. For this reason FHIR provides a conformance layer in which details can be given about how the resources and their exchange paradigms are used to solve particular use cases.

The following key resources implement the conformance layer:

ValueSet A ValueSet defines a set of coded values (see "Using Codes" for more details) that can be used in a particular element.
StructureDefinition A StructureDefinition is what you build when you build a profile. The StructureDefinition contains rules about how a resource (or type) and its data elements are used in a particular context. A structure definition references value sets for the coded elements in a resource.
CapabilityStatement A CapabilityStatement is a statement of the kinds of resources and operations provided and/or consumed by an application. The Capability Statement references profiles to describe specific use of resources by the application.
Implementation Guide An ImplementationGuide is a document that is published by a domain, institution or vendor that describes how FHIR is adapted to support a certain use case (or set of use cases). An implementation guide is a collection of capability statements, profiles, value sets, and (narrative) documentation describing a set of interoperable applications.

When you start profiling you start building structure definitions. A structure definition may contain:

  1. A differential statement, which describes the differences compared to the base structure.
  2. A snapshot, which contains the full description of the structure definition.
  3. Both, which is actually the most useful form as the differential form serves the authoring process, while the snapshot serves the implementation tooling. Although StructureDefinition resources used in operational systems should always have the snapshot view populated, the FHIR project provides tools for the common platforms that can populate a snapshot from a differential. Note, however, that these tools generate complete verbose snapshots; they do not support suppressing mappings or constraints.

2. Introduction to Profiling

This part contains an introduction in profiling. It explains what is meant by a profile and profiling, why it is important and what can be profiled.

2.1 What are profiles and profiling?

A profile is a set of constraints on a FHIR resource or another FHIR profile. The term is however also colloquially used to refer to an implementation guide or a conformance package. The term "profiling" refers to the act of applying constraints to Conformance Resources. Conformance Resources are created by work groups of industry specialists to accommodate a wide audience, that is to say that FHIR aims to standardize functionality that is supported by 80% of systems in use. The chances that you will need something that specifically fits your domain when deciding to use FHIR are high. To suit your needs you will need to apply edits (constraints) to the existing Conformance Resources to create a profile that is specific to your needs. In short, profiling is the act of creating a profile. Once you have created your first profile you are officially a profiler (and should be very proud!).

2.2 Why profiling?

Below you see an overview of why profiling is important. Although you could theoretically build a FHIR solution without using profiles, this would be very inconvenient as you would not be able to validate instances of resources for conformance. In a profile you can define a set of constraints on the resource, which enables you to validate instances of resources against these constraints and only accept instances that conform to the specified profile. It also enables you to automatically check if these constraints are valid or automatically compare them to other existing profiles. In addition, the profiles serve as documentation of the decisions that were made during the implementation and communicate to developers what kind of content is expected. They can also be published and shared online, so others can reuse them in similar use cases.

2.3 What can be profiled?

Below is an overview of what can be profiled. Usually you would start profiling a core resource, for example you would start building a profile for the Patient resource. You can profile anything that is used, not used or extended. For example, you could use the element name and specify in your profile that this element is obligatory by setting the minimum cardinality to 1. Or you could not use the element birthplace by setting the maximum cardinality to 0. It is also possible to add elements that are not available yet in the core resource. Maybe you would like to add hair color and build an extension for this. The concepts cardinality and extension are explained in the next part of the course. Other parts of the resource that you could profile are the codes in coded elements (you could either use standard codes or create your own), the interactions, operations and search parameters that will be supported and even the security details. Finally, you can specify your own mapping to a local view of the data.

In addition to profiling core resources, you can also profile data types or even another profile. The latter would result in a derived profile. Derived profiles and the profiling of data types will be explained in the next paragraph.

2.4 Derived or layered profiles

Constraints can also be applied to existing profiles. These "profiles on profiles" are called derived profiles. These profiles are made by further constraining profiles that have been made by yourself of by someone else, the so-called base profile. On the documentation site for Forge you can find detailed information about derived profiles and how to create one in Forge.

Derived profiles enable organizations to benefit from existing profiles and to further customize those profiles to their specific needs. Core resources are designed to fit approximately 80% of the use cases. A country can take a core resource and constrain it to fit the specific needs that reflect the situation in their country. This then becomes that country's version of that core resource, and acts as their national profile. An organization in that country realizes that they would like to use the national profile but need extra constraints to reflect the specific situation in their centers. They will make a derived profile of this national profile. This new organizational profile will have all the inherited changes from the national profile that were made to the original core resource.

It is also possible that there are additional layers (this is what we call layered profiles). For example, Norway has introduced regional profiles to incorporate regional differences. The regional profiles are derived from the national profile. A Norwegian organization uses the regional profile to derive their own use-case specific profile and reflect their own organization specific needs. If the regional profile is to specific for their needs they can provide feedback to the regional organization. If more organizations have the same comments, the regional organization can consider updating the profile on a higher level to meet their needs. In the same way, the regional organization can provide feedback to the national organization.

The image below illustrates the concept of derived and layered profiles. At a higher level, the profiles are more generic and have a lower volume, while a higher volume of resources will conform to these profiles. At a lower level, the profiles will be more specific and have a higher volume, while there will be less resources conforming to these profiles.


Real-life examples


HL7 Germany

The project Basisprofil DE in Simplifier contains the national profiles for Germany. Below is an example of the German national profile for Patient. The canonical URL or identity of this profile is: http://fhir.de/StructureDefinition/patient-de-basis-0.2 The first part (http://fhir.de) is the end-point were all German profiles are located. The resource type is a StructureDefinition (each profile is stored as a StructureDefinition resource). Finally, the logical ID of the resource is "patient-de-basis-0.2". Below you see the snapshot view of this resource, which means that all elements of the core Patient resource are shown whether these are changed compared to the core resource or not.

useΣ ?!0..1codeBinding
systemΣ1..1uri
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
systemΣ1..1uriFixed Value
valueΣ1..1string
periodΣ0..1Period
assignerΣ0..1Reference(Organization)
activeΣ ?!0..1boolean
nameΣ0..*HumanName, deutsches Basisprofil (Version 0.2)
systemΣ0..1codeBinding
valueΣ0..1string
useΣ ?!0..1codeBinding
rankΣ0..1positiveInt
periodΣ0..1Period
other-amtlich0..1Extension
birthDateΣ0..1date
deceasedBooleanboolean
deceasedDateTimedateTime
addressΣ0..*Adresse, deutsches Basisprofil (Version 0.2)
maritalStatus0..1CodeableConceptBinding
multipleBirthBooleanboolean
multipleBirthIntegerinteger
photo0..*Attachment
relationship0..*CodeableConceptBinding
name0..*HumanName, deutsches Basisprofil (Version 0.2)
telecom0..*ContactPoint
address0..*Adresse, deutsches Basisprofil (Version 0.2)
gender0..1codeBinding
organization0..1Reference(Organization)
period0..1Period
language1..1CodeableConceptBinding
preferred0..1boolean
generalPractitioner0..*Reference(Organisation, deutsches Basisprofil (Version 0.2) | Practitioner, deutsches Basisprofil (Version 0.2))
managingOrganizationΣ0..1Reference(Organisation, deutsches Basisprofil (Version 0.2))
otherΣ1..1Reference(Patient | RelatedPerson)
typeΣ1..1codeBinding

HL7 Norway

Below is an example of the Norwegian national profile for Patient as defined by HL7 Norway. This national profile was reused in the HelseVest Perioperative project. Below you see the differential view of this resource, which means that not all elements of the core Patient resource are visible. Only the elements that are changed compared to the core Patient resource are shown.

system1..Fixed Value
value1..
system1..Fixed Value
value1..
system1..Fixed Value
value1..

Stichting Koppeltaal

Stichting Koppeltaal is a Dutch organization that enables FHIR-based exchange of data between e-health applications in the care sector. The example below shows the KoppeltaalPatient profile, which is derived from the Dutch national profile for Patient, called nl-core-patient profile. This is a snapshot view of the resource.

url1..1uriFixed Value
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
systemΣ0..1uri
versionΣ0..1string
codeΣ0..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
systemΣ0..1uri
valueΣ0..1string
startΣ0..1dateTime
endΣ0..1dateTime
referenceΣ0..1string
identifierΣ0..1Identifier
displayΣ0..1string
displayΣ0..1string
nationality0..*ExtensionBinding
person-age0..1ExtensionBinding
useΣ ?!0..1codeBinding
systemΣ0..1uri
versionΣ0..1string
codeΣ0..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
systemΣ1..1uriFixed Value
valueΣ1..1string
startΣ0..1dateTime
endΣ0..1dateTime
referenceΣ0..1string
identifierΣ0..1Identifier
displayΣ0..1string
activeΣ ?!0..1boolean
nameΣ0..*nl-core-humanname
systemΣ1..1codeBinding
valueΣ1..1string
useΣ ?!0..1codeBinding
rankΣ0..1positiveInt
periodΣ0..1Period
genderΣ0..1codeBinding
birthDateΣ0..1date
deceasedBooleanboolean
deceasedDateTimedateTime
addressΣ0..*nl-core-address
maritalStatus0..1CodeableConceptBinding
multipleBirthBooleanboolean
multipleBirthIntegerinteger
photo0..*Attachment
relationship0..*CodeableConceptBinding
role0..*CodeableConceptBinding
name0..*nl-core-humanname
systemΣ1..1codeBinding
valueΣ1..1string
useΣ ?!0..1codeBinding
rankΣ0..1positiveInt
periodΣ0..1Period
address0..*nl-core-address
gender0..1codeBinding
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
systemΣ0..1uri
versionΣ0..1string
codeΣ0..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
systemΣ0..1uri
valueΣ0..1string
startΣ0..1dateTime
endΣ0..1dateTime
referenceΣ0..1string
identifierΣ0..1Identifier
displayΣ0..1string
displayΣ0..1string
period0..1Period
language1..1CodeableConceptBinding
preferred0..1boolean
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
systemΣ0..1uri
versionΣ0..1string
codeΣ0..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
systemΣ0..1uri
valueΣ0..1string
startΣ0..1dateTime
endΣ0..1dateTime
referenceΣ0..1string
identifierΣ0..1Identifier
displayΣ0..1string
displayΣ0..1string
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
systemΣ0..1uri
versionΣ0..1string
codeΣ0..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
systemΣ0..1uri
valueΣ0..1string
startΣ0..1dateTime
endΣ0..1dateTime
referenceΣ0..1string
identifierΣ0..1Identifier
displayΣ0..1string
displayΣ0..1string
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
systemΣ0..1uri
versionΣ0..1string
codeΣ0..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
systemΣ0..1uri
valueΣ0..1string
startΣ0..1dateTime
endΣ0..1dateTime
referenceΣ0..1string
identifierΣ0..1Identifier
displayΣ0..1string
displayΣ0..1string
typeΣ1..1codeBinding

Feedback


We are always looking for ways to improve our products. The Profiling Academy was built using our own IG-editor in Simplifier. If you have any feedback on this module or on our Profiling Academy in general, please leave a comment in the Issue Tracker of the project.


Get in touch


Start profiling

Most modules end with an exercise. Use Forge to start profiling yourself. Just contact us at simplifier@fire.ly if you need any help.

Learn more

Follow one of our predefined or tailor-made courses. We will make sure you know FHIR inside-out.

Need help or advice?

Let us assist you with your FHIR use case. Visit our company website to know more about our services or get into contact with Rien Wertheim right away.