This specification conforms to FHIR®© R4
New to FHIR?
Table of contents
The purpose of this section is to give an introduction to MedCom’s FHIR standards to stakeholders with no or limited knowledge about FHIR. On this page, you will find a brief introduction to the most frequently used terms and guidance to more information about FHIR and MedComs FHIR standards.
1 FHIR Glossary
Fast Healthcare Interoperability Resources (FHIR®©) is developed by the international organization Health Level 7 (HL7) and is an open-source standard developed to exchange healthcare-related information. FHIR defines several resources, often referred to as ‘building blocks’, each describing a delimited area within healthcare, e.g. a Patient or an Encounter. These resources are generic and can therefore be used across the world. However, when using the resources in a specific context, such as communication between Danish healthcare parties, the resources need to be profiled to accommodate the use. The profiling could be to require the last name of a Patient. In some cases, it is necessary to extend the generic resources to fit the context, e.g. to add a civil registration number (Danish: CPR-nummer) as a patient identifier.
When creating a MedCom FHIR standard, multiple profiles are assembled to include the information necessary to support the business requirements. Under the auspices of MedCom, these profiles will most often come from multiple Implementation Guides (IG). This decision is further addressed in section “Why are there Multiple Implementation Guides?” that can be founded in the Frequently asked questions page.
The first wave of MedCom’s modernisation only includes FHIR messages, which means that there must always be a sender and a receiver. A relevant exchange paradigm could be to upload data as services or as documents where multiple receivers have access to data or documents. If another exchange paradigm is to be used, it is possible to reuse the profiles from the Core IG. This is an example of FHIR’s reusability across standards and exchange paradigms. The optimal exchange paradigm for a standard will be considered when modernizing the next wave of MedCom standards.
In the Table 1 you will find the most common terms and associated descriptions and examples. These terms all describe a fundamental feature in FHIR, and they make the foundation for understanding FHIR, and why they are presented initially.
Note: the Table 1 uses FHIR-paths to describe exactly which element is referred to e.g. Patient.name refers to the nameelement in the Patient resource.
| Term | Description | Example |
|---|---|---|
| Implementation Guide (IG) | The technical specification of a MedCom FHIR standard. A set of rules and associated documentation describing, how FHIR profiles should be implemented to accommodate a given standard and its requirements. | Acknowledgement IG , HospitalNotification IG , CareCommunication IG , Terminology IG , Core IG target="_blank", Messagaging IG |
| Standard | FHIR standard define how health and care information can be exchanged between providers and their system regardles of how the information is stored in those systems. | MedCom FHIR standards are HospitalNotification, CareCommunication |
| Element | A resource consists of multiple elements each describing a specific part of the content. | Patient.name or Patient.address. |
| Cardinality | Each element is described with a minimum and maximum cardinality, determining how many times an element may or shall appear:
|
In the generic resource Patient.name has the cardinality 0..*, meaning a patient may have zero or more names. In the generic resource Encounter.status has the cardinality 1..1, meaning that a status always shall appear, and in may only appear once. |
| Resources | FHIR consists of generic resources, each describing a clinically delimited area. Resources are 'building blocks' defined by HL7. | A Patient resource, an Allergy resource, an Observation resource, an Encounter resource ect. |
| Profile | FHIR profile is a set of specified constrains and/or extensions on the base resource | MedComMessaging profiles , MedComCore profiles |
| Profiling | Profiling allows us to fit a resource to a given context, by defining constrains and/or by define extensions. It is widely recognised that when exchanging data it is impossible to make a one size fits all within the healthcare worldwide. To accommodate this condition, the resources are made generic with the possibility of being profiled to fit a specific context, such as exchanging a CareCommunication message between Danish healthcare parties. |
Profiling could be to require a lastname and an identifier of a patient or citizen when exchanging information about the person. |
| Extensions | To extend a resource to include additional information than defined by HL7. | Extending the MedCom MessageHeader with a reportOfAdmissionFlag. |
| CodeSystem | A collection of codes, which can be predetermined by HL7, from a international terminology or defined by the developer of the IG. | Predetermined by HL7 e.g. gender, from an international terminology e.g. SNOMED CT, or defined by the developer of the IG e.g. categories categories in a CareCommunication message. |
| ValueSet | A collection of codes from one or more CodeSystems. ValueSets can either include all codes from a CodeSystem or only some codes. | MedComMessagingMessageTypes is a ValueSet that includes all codes from the MedComMessagingEvents CodeSystem. The ValueSet includes the codes for MedComs FHIR standards |
| MustSupport | Indicates which information which shall be included in a MedCom standard if available in the sender systemer and which information the receiver system shall be able to handle. MustSupport is defined during profiling of the resource. | The elements Patient.identifier, Patient.name and Patient.address does all have the flag MustSupport in the MedComCorePatient profile. |
| Modifier | An element which modifies or changes the understanding of the resource. '!?' indicates in the IG that the element is a modifier element, which is often defined in the generic resource or in developed extensions | Patient.deceased is a modifier element since it modifies the way the content of the profile should be understood, if the patient is deceased. |
| Narrative | A textual summary of the information in a message which can be used to display information if the structured data cannot be displayed. All information in a message shall be included in the summary. | All content from a message, including the patients name or CPR-number and the written correspondence in a CareCommunication message. |
2 How to read a MedCom Implementation Guide
If you are interested in understanding the basic content and the composition of an IG, you can follow this step-by-step guide.
3 More information
3.1 Webinars
In 2022 MedCom has held two webinars concerning the modernization of MedCom standards. Both webinars are free and available in Danish:
- FHIR-introductionswebinar (17. may 2022)
- FHIR demo-webinar with MedCom, Mjølner and Trifork (10 . february 2022)
3.2 HL7 FHIR Documentation
All FHIR documentation can be found at www.hl7.org/fhir/. Here you will find detailed descriptions of basic principles, presentations to all resources and much more.
About
Support or contact
MedCom is responsible for this page. If you have any questions regarding this page, please contact fhir@medcom.dk or write to MedCom's stream on Zulip.Version of this documentation
The version of this documentation is: Version 1.0.9 You can find the release note of the version here."FHIR® is the registered trademark of HL7 and is used with the permission of HL7. Use of the FHIR trademark does not constitute endorsement of this implementation guide by HL7, nor affirmation that this content is conformant to the various applicable standards"