Basic Components

Common design considerations

In this project, five profiles have been developed. They were developed based on the data in the patient's plans for various diseases and the projects' requirements. For all five profiles, a series of common features and design choices exist and are explained below.

Naming and development of the profiles

The profiles are developed in Forge for H7 FHIR R4 (v. 4.0.1). After the completion of the project, the profiles are uploadet to Simplifier.net to contribute to the further development of FHIR and it was therefore chosen to adhere to the naming guidelines Simplifier has. Thus, profiles are named in English to increase the amount of people who can use the profiles. This is also the reason for using UpperCamelCase for naming profiles and lowerCamelCase for naming elements and slices. It also means that the name of each profile contains the following:

• Name of the project:
  The name of the project is used as a suffix, separated from the rest of the profile's name with a hyphen. The name of the project is OneComprehensivePatientPlanForChronicDisease.

• Adequate name for the profile:
  The profiles are named after what kind of data they contain. An example is the profile PatientPlan-OneComprehensivePatientPlanForChronicDisease which contains all the information about the observations and clinical impressions from the encounter, including information about the complications and diagnostics.

Since the full names of the profiles are quite long, they are henceforth only referred to without their postfix, e.g. the profile PatientPlan-OneComprehensivePatientPlanForChronicDisease is only referred to as Patient.

Constraints

Constraints are used in the form of cardinalities and data types in the elements of the profiles. The cardinalities are used to determine how many times an element in the profile can be repeated. Data type is used to determine the type of date, e.g. DateTime. By using constraints, the correlation between the profiles and the context was heightened as it made the profiles more specific.

Slicing

In some profiles, slicing was used on one or more elements. Slicing was used in instances where a constraint on an element did not apply to all the sub elements of the said element. A discriminator was determined in the sliced element and consisted of a type and a path which together determined though the sliced elements were to be separated. As a rule, the discriminator had ''exists'' as type and ''code'' and ''coding.code'' as path when the sliced element contained a reference to a SNOMED CT code. In the event where an element must be sliced but does not contain any references to SNOMED CT, the discriminator uses ''type'' as type and ''$this'' as path.

Modelling type

The project uses closed modelling as this technique is more specific for the context and yields smaller profiles. The use of open modelling would mean profiles with fewer constraints and thus larger flexibility. Open modelling would also mean that profiles would become more generic. With the use of closed modelling a more specific content for the context can be obtained and the profiles are smaller as they do not contain unnecessary elements.

Identifier

As an identifier for the patient, the Danish social security number is used to ensure correct identification of the patient. The Danish social security number has a database reference in the subelement system and their structure is defined in the subelement value. The structure of the Danish social security number is defined as ten digits with a hyphen before the last four digits.

CodeSystems

To ensure technical and semantic interoperability, the profiles contain SNOMED CT and Loinc codes. They are defined in HL7 FHIR as CodeSystems and their binding in the profiles are required to ensure that only codes from the specified standards are used.