Basic Components

Common design considerations

In this project, 11 profiles have been developed. The profiles have been developed based on the data entered in PPJ by the ambulance rescuers, which is why many elements have been selected from. The 12 profiles have common features, which are reviewed below. When profiling, there are design choices that will be common to the profiles prepared in the project.

Naming and development of the profiles

The profiles are developed in Forge for the HL7 FHIR R4 (V 4.0.1). Since the finished profiles must be uploaded to Simplifier and contribute to the further development and use of HL7 FHIR, it was decided to follow the recommendations that Simplifier has for naming. Therefore, the profiles are named in English to increase that more people can use the profiles and by using UpperCamelCase. Likewise, the elements and slices of the profiles are named in English with lowerCamelCase. In addition, it also means that the name of each profile contains:

• Prefix: in this project prefix is ​​the name of the project. The project is called PrehospitalDataInEHR. Prefix is ​​separated from the rest of the name by a hyphen.
• Resource: the base resource from which the profile is built is specified. In this project, e.g. the resources ClinicalImpression, Observation and Patient.
• Coverable name of the profile: the profiles are named after the content they cover in PPJ. This applies to e.g. for the profile PrehospitalDataInEHR-ClinicalImpressionVitalSignsTriage profile, which states that the profile contains data to describe vital parameters, symptom and contact cause and triage. In cases where the resource also covers the name of the profile, the resource is not used, e.g. there is no profile called PrehospitalDataInEHR-PatientPatient-profile, but only PrehospitalDataInEHR-Patient-profile.
• Suffix: the type of resource. In this project, only resources of the profile type are used. Suffix is ​​separated from the rest of the file name by a hyphen.

Going forward, the profiles are denoted without pre- and suffix, ie. the profile PreHospitalDataInEHR-ClinicalImpressionVitalSignsTriage-profile is referred to as ClinicalImpressionVitalSignsTriage.

Identifier

For all 12 profiles, it has been chosen that they must contain a mandatory identifier, as the identifier must be a reference to which series of information,based on the API call from the user system. This method can be used, as a requirement for the API call will only be to retrieve information in the database, which is stored on the date. It would be beneficial to use both the patient's CPR number and temporary replacement CPR number or patient ID as identifiable. The patient's CPR number could thus be used if the patient has been identified and the CPR number has been registered. If the patient is unidentified and thus has not registered their own CPR number, the ambulance rescuers contact the receiving hospital, which generates a temporary replacement CPR number (me-CPR number) for the patient. Me-CPR number is then registered in a general note in PPJ by the ambulance rescuer. In order to be able to extract the me-CPR number among other notes, some form of processing of the notes is required before the me-CPR number can be used. Therefore, me-CPR number is selected from, as this additional processing of data is outside the context of this project. In addition, patient ID was chosen from, as this would only apply in scenarios where there are two or more injured in the incident and is therefore not consistent for all acute treatment courses. Therefore, the patient's CPR number was used as an identifier for the project profiles. This identifier must ensure that data is connected to the correct patient. This ensures that when a user system makes an API call, all available data on the called patient is retrieved from the database for today's date. The elements under the element identifier that are selected for are system and value, as system must indicate with a uri where value is to be retrieved from. The element value must be unique and consist of 10 digits and a hyphen, which a Danish CPR number has.

Constraints and closed modelling

In this project, it has been chosen to do closed modeling. This is because it is known which data needs to be reused. It will be an advantage to do open modeling during further development, as open modeling makes the profiles more generic and has fewer constraints. In closed modeling, several elements are limited and the elements that are not used are rejected. The advantages of closed modeling are that there is no need to support all elements and the profiles become smaller and more specific. The disadvantages of closed modeling are that there will be more versions of the models, as a new element requires a new version, which also only makes the models backward compatible. In addition, in certain elements there are constaints on the data type, e.g. that an item must be a dateTime or a string. This ensures that the profiles are as specific as possible and the coherence to the context is ensured.

Slicing

It is recommended to avoid constraining maximum cardinality, which in this project is not done as it is not desired to constrain the number of instances of the profile. Therefore, slicing is used where the cardinalities are constrained. Using slicing does not require the development of custom interfaces from amPHI Systems PPJ that remove unnecessary data in order to send data. When slicing, be careful not to specify everything through slices and leave the rest open. Are several registrations made of e.g. vital parameters, a profile is instantiated again. Slicing requires the use of a discriminator in the item being sliced. The discriminator determines to which slice the information registered in the PPJ belongs. The discriminator is determined by a type and path. For project discriminators, exist is selected as type and itemCodeableConcept.text and text selected as path.

Safety

The developed profiles contain a canonical URL that is used as a tool to partly identify the profile and partly for references between the profiles. For example. certain profiles must have a reference at the subject subject to the Patient profile to which the URL of the developed Patient profile is inserted. All URLs have certain common features, as they contain the name of the project (PrehospitalDataInEHR) and a unique resource ID. The resource IDs consist of two letters and two numbers. The letters RE stand for resource and are repeated for all 11 profiles. The two digits denote the number of the profile. The profiles are numbered consecutively, based on their name. The ClinicalImpressionVitalSignsTriage profile thus has the resource ID RE01, while the SubstanceActiveIngredient profile has the resource ID RE01. The URLs also use https, as this project contains sensitive data such as CPR numbers. This ensures the best possible data transfer between the sender system, the service platform and the user systems.