Basic Components
Common design considerations
In this project, one extension and 12 profiles have been developed. They were developed based on the data in the patient's treatment plan for AML and the projects' requirements. For all 12 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 uåloadet 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 postfix, separated from the rest of the profile's name with a hyphen. The name of the project is ReuseBetweenEHRsForChildrenWithAML.Adequate name for the profile:
The profiles are named after what kind of data they contain. An example is the profile CarePlan-ReuseBetweenEHRsForChildrenWithAML which contains all the information about the treatment and medication the patient has received, including information about the complications and diagnostics.Resource:
The profiles all originate from base resources which are stated before the adequate name. An example of a profile with both a base resource and an adequate name is the profile Organizationhospital-ReuseBetweenEHRsForChildrenWithAML. For the profiles where the adequate name was identical to the base resource name, the resource name was not used to avoid double names. This means that the profile ObservationObservation-ReuseBetweenEHRsForChildrenWithAML does not exists; instead the profiles is names Observation-ReuseBetweenEHRsForChildrenWithAML.
Since the full names of the profiles are quite long, they are henceforth only referred to without their postfix, e.g. the profile CarePlan-ReuseBetweenEHRsForChildrenWithAML is only referred to as CarePlan.
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 or a LOINC code. In the event where an element must be sliced but does not contain any references to SNOMED CT or LOINC, the discriminator uses ''type'' as type and ''$this'' as path. In the profile DiagnosticReport, the slices are each made with two sub slices, although this is not common practice. It is however done to ensure that a registration from this profile contains both a SNOMED CT code and a LOINC code.
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.
Resource ID
All profiles contain an URL unique to the profile. With this, it was made possible to create references between the profiles using a target profile. the profile ClinicalImpression has for example a reference to the profile Patient in its element subject where the URL for the profile Patient is encompassed. References to other profiles are bundled as all profiles are in the same collection.
All the URLs contain the name of the project and a resource ID which is unique. The resource ID for the profiles consists of the letters RE and a sequential number from 01 to 12, since there are 12 profiles. For the extension, the resource ID is E01, as it is the only extension. Thus, the URL for the profile ClinicalImpression is http://ReuseBetweenEHRsForChildrenWithAML.dk/fhir/StructureDefinition/RE03.
Identifier
As an identifier for the patient, the Danish social security number is used to ensure correct identification of the patient. Furthermore, a patient ID is used as a primary key to create binding between the patient and the other profiles. The patient ID ensures that all data registered in a certain patient's care plan was extracted and standardized so the information could be passed on to another EHR. This means that for the profile Patient, both a Danish social security number and a patient ID must be defined in the element identifier. Both the Danish social security number and the patient ID 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. The patient ID is structured as a unique value, making each patient ID different from the others.
In the other 11 profiles, patient ID is used in the profiles' element identifier to ensure a connection between the profiles and their associated patient. In the subelement system, the database reference is specified while the subelement value structures the patient ID as a unique value.
CodeSystems and ValueSets
To ensure technical and semantic interoperability, the profiles contain SNOMED CT, LOINC and ICD-10 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. Some profiles also use ValueSets, e.g. in the element speciality from the profile HealthCareServiceAttendingWards. ValueSets specify a shorter list and their binding is also required.
Extensions
Since more registrations can be done within the same profile, each registration must have its own timestamp. Therefore, an extension specifying date and time is created and used in these profiles. The extension can be added to the sliced element of the profile.