# 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.

{{render:FHIR_Resources.png}}

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.

{{render:Resource_identity.png}}

## 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](https://www.hl7.org/fhir/valueset.html)|A ValueSet A ValueSet defines a set of coded values (see ["Using Codes"](https://www.hl7.org/fhir/terminologies.html) for more details) that can be used in a particular element.|
|[StructureDefinition]( https://www.hl7.org/fhir/structuredefinition.html)| 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](https://www.hl7.org/fhir/capabilitystatement.html)| 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](https://www.hl7.org/fhir/implementationguide.html)| 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.

{{render:profiling goals.png}}

### 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.

{{render:What can be profiled.png}}

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]( http://docs.simplifier.net/forge/forgeDerivedProfiles.html) 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.

{{render:derived_profiles2.png}}

It is also possible that their 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.

{{render:derived_profiles.png}}

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.

{{render:derived_profiles3.png}}