2. Technical design
2.1. Introduction
This technical design provides the technical specification of the Dental Care (Dutch: Mondzorg) standard.
This technical design is the technical counterpart of the functional design. The FHIR version used for this IG is R4 (4.0.1).
Note that in addition to this design, the (technical) guidelines as specified in the MedMij R4 Core IG and the MedMij FHIR IG for R4 apply, the latter of which is published by Nictiz.
2.2. Actors involved
| Actor | System | ||
|---|---|---|---|
| Name | Description | Name | Description |
| Patient | The user of a personal healthcare environment | PHR | Personal health record |
| Healthcare provider | The user of a XIS | XIS | Healthcare information system |
Table 1: Actors
2.3. Boundaries and relationships
This technical design includes use cases for the exchange of dental care data between healthcare providers (e.g. dentists) and patients (e.g. in a PHR setting).
This technical design assumes that a PHR is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right source system nor does it provide information about security. These infrastructure and interface specifications are described in the MedMij Afsprakenstelsel. In particular, each transaction is performed in the context of a specific authenticated patient, which has been established using the authentication mechanisms outlined in the MedMij Afsprakenstelsel (also see the MedMij FHIR IG by Nictiz), i.e. via an OAuth2 token. Each XIS gateway is required to perform filtering based on the patient associated with the context for the request, so only the records associated with the authenticated patient are returned. For this reason, search parameters for patient identification SHALL NOT be included.
2.4. Relating FHIR (profiles) to its functional counterpart
The functional model used in Dental Care consists of zibs from publication 2020, as well as Clinical Information Models (CIMs) defined by MedMij, the latter of which are represented by Logical Models.
- For each concept in these Logical Models, an id is assigned by MedMij. These ids are also added as mappings in the FHIR profiles on the corresponding elements, i.e. by specifying
.mapping.mapon each element accordingly. Therefore, these ids form the linking pin between the Logical Models and FHIR profiles. If no such mapping is possible for a certain element in a FHIR profile, guidance is provided to indicate how that element should be handled. - The zibs are technically implemented via nl-core profiles, which are bundled in the nictiz.fhir.nl.r4.nl-core package. In these profiles, mappings to the corresponding zib (concepts) have been added.
2.5. Use cases
Within Dental Care the following use cases are distinguished:
- General dental care
- Dental Fitness (only relevant in the Ministry of Defence context)
Within this technical design these use cases are combined into a single use case, as a granular exchange approach is adopted.
2.5.1. Use case: Retrieve Dental Care data
The Dental Care data is defined and exchanged in a granular manner, which means that for each CIM that is part of Dental Care, a separate (granular) data service is defined. Granular exchange allows the PHR to retrieve individual data services that are part of Dental Care through targeted search interactions, in accordance with the general guidance and profiles defined in the MedMij R4 Core IG.
The table below gives an overview of all granular data services that are applicable for Dental Care. Note that cross-domain data services are defined in the MedMij R4 Core IG, while domain-specific data services are defined in this IG.
| Id | Data service name without version (English) | Data service name without version (Dutch) | Data service version |
|---|---|---|---|
| 900000107 | Retrieve MedMij Core - ASA score | Verzamelen MedMij Core - ASA-score | 1.0.0-beta.2 |
| 900000111 | Retrieve MedMij Core - Encounter (zib2020/R4) | Verzamelen MedMij Core - Contact (zib2020/R4) | 1.0.0-beta.2 |
| 900000101 | Retrieve MedMij Core - Patient (zib2020/R4) | Verzamelen MedMij Core - Patient (zib2020/R4) | 1.0.0-beta.2 |
| 900000110 | Retrieve MedMij Core - Payer (zib2020/R4) | Verzamelen MedMij Core - Betaler (zib2020/R4) | 1.0.0-beta.2 |
| 900000103 | Retrieve MedMij Core - Treatment objective (zib2020/R4) | Verzamelen MedMij Core - Behandeldoel (zib2020/R4) | 1.0.0-beta.2 |
| 900000105 | Retrieve Dental Care - Caries risk | Verzamelen Mondzorg - Cariësrisico | 1.0.0-beta.2 |
| 900000109 | Retrieve Dental Care - Dental fitness | Verzamelen Mondzorg - Dental fitness | 1.0.0-beta.2 |
| 900000104 | Retrieve Dental Care - Oral hygiene | Verzamelen Mondzorg - Mondhygiëne | 1.0.0-beta.2 |
| 900000106 | Retrieve Dental Care - Parafunctional activity | Verzamelen Mondzorg - Parafunctionele activiteit | 1.0.0-beta.2 |
| 900000108 | Retrieve Dental Care - Periodic Periodontal Screening score | Verzamelen Mondzorg - Periodieke Parodontale Screening-score | 1.0.0-beta.2 |
| 900000102 | Retrieve Dental Care - Procedure | Verzamelen Mondzorg - Verrichting | 1.0.0-beta.2 |
Table 2: Granular data services applicable for Dental Care+
The technical specifications with respect to the request message executed by the PHR and the response message of the XIS are detailed in the MedMij R4 Core IG.
Moreover, the MedMij R4 Core IG contains specifications and requirements regarding the care type, which is exchanged via the .meta.tag element. In particular, two SHOULD statements are part of these requirements. Note, however, that within Dental Care these two requirements are stricter, as the care type SHALL always be conveyed in Dental Care data, which means that at least one .meta.tag indicating the care type SHALL be added to each FHIR resource, provided the care type is known in the source system.