cio:V2.0.0 FHIR CiO: verschil tussen versies
(Restructured profiles section) |
(Added Patient identification) |
||
| Regel 8: | Regel 8: | ||
<div class="toclimit-3">__TOC__</div> | <div class="toclimit-3">__TOC__</div> | ||
| − | =Introduction= | + | = Introduction = |
This is the implementation guide (IG) for the information standard CiO (Dutch: Contra-indicaties en overgevoeligheden, English: Contraindications and intolerances), version {{VersieInfo|CiO|release=V2.0.0}}. The functional specification can be found [[cio:Vdraft_Ontwerp_CiO|here]] and is implemented using [https://www.hl7.org/fhir/R4/ HL7 FHIR R4]. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR. | This is the implementation guide (IG) for the information standard CiO (Dutch: Contra-indicaties en overgevoeligheden, English: Contraindications and intolerances), version {{VersieInfo|CiO|release=V2.0.0}}. The functional specification can be found [[cio:Vdraft_Ontwerp_CiO|here]] and is implemented using [https://www.hl7.org/fhir/R4/ HL7 FHIR R4]. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR. | ||
| Regel 120: | Regel 120: | ||
* The zib HealthcareProvider is mapped to both a Location and Organization profile. In general the Location profile acts as the focal resource, because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. However, within the main building blocks in CiO the HealthcareProvider is always present as an author, hence a reference to the Organization profile is sufficient in those cases. The Location profile, although not directly referenced from the main building blocks, is mentioned in the table above for completeness purposes (as it is referred to in supporting resources). | * The zib HealthcareProvider is mapped to both a Location and Organization profile. In general the Location profile acts as the focal resource, because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. However, within the main building blocks in CiO the HealthcareProvider is always present as an author, hence a reference to the Organization profile is sufficient in those cases. The Location profile, although not directly referenced from the main building blocks, is mentioned in the table above for completeness purposes (as it is referred to in supporting resources). | ||
| − | =Release notes= | + | == Mappings between profiles and data set == |
| + | |||
| + | Each transaction starts with links to the functional definition in an ART-DECOR publication and references one or several FHIR profiles. The FHIR profiles contain mappings to all data elements that are present in the functional data set (prefixed with ‘cio-dataelement-20-’). | ||
| + | |||
| + | Each transaction contains a Patient building block with cardinality 1..1 M. This patient is the subject of all other building blocks in the transaction, although no explicit relation exists in the data set. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in {{fhir|.subject}} (or {{fhir|.patient}} in the case of the {{fhir|AllergyIntolerance}} resource) of each FHIR instance of each main building block. | ||
| + | |||
| + | Relations between different building blocks exist in transactions by means of concepts with a name starting with ‘Relation…’ (Dutch: ‘Relatie…’) and an underlying concept 'Identification' of data type Identification, for example RelationHypersensitivityDisposition (cio-dataelement-20-734) in building block HypersensitivityDisposition. These relations are mapped to the FHIR data type ‘Reference’. Implementers SHOULD use literal references (using {{fhir|.reference}}) instead of logical references (using {{fhir|.identifier}}) where possible, see the [[FHIR:V1.0_FHIR_IG_R4#Use_of_the_reference_datatype|general FHIR IG on the Reference data type]]. | ||
| + | |||
| + | == Patient identification == | ||
| + | |||
| + | This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification. | ||
| + | |||
| + | Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a [https://www.hl7.org/fhir/r4/search.html#chaining chained search parameter] for all resource types except Patient, so only the records associated with the authenticated patient are returned. | ||
| + | |||
| + | When patient identification requires the use of search parameters, the following search parameters SHALL be supported: | ||
| + | * Patient: {{fhir|identifier}} | ||
| + | * AllergyIntolerance: {{fhir|patient.identifier}} | ||
| + | * Condition: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}} | ||
| + | * Observation: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}} | ||
| + | * Flag: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}} | ||
| + | |||
| + | An example of a request that retrieves all AllergyIntolerance resources of a patient with a fake BSN of 11122233: | ||
| + | |||
| + | <pre>GET [base]/AllergyIntolerance?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</pre> | ||
| + | |||
| + | All request examples in this document do not include patient identification mechanisms. Requesters are assumed to include these if necessary. | ||
| + | |||
| + | = Release notes = | ||
Release notes can be found on the [[cio:Vdraft_Ontwerp_CiO#Release_notes| functional design page]]. | Release notes can be found on the [[cio:Vdraft_Ontwerp_CiO#Release_notes| functional design page]]. | ||
Versie van 18 apr 2023 om 14:19
|
|
This FHIR IG is currently under development and can not be considered stable and ready for use. For questions and change requests regarding this IG, please create a ticket in [ BITS]. |
1 Introduction
This is the implementation guide (IG) for the information standard CiO (Dutch: Contra-indicaties en overgevoeligheden, English: Contraindications and intolerances), version . The functional specification can be found here and is implemented using HL7 FHIR R4. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR.
Apart from this document, the guidelines as specified in the general FHIR Implementation Guide apply. In particular, the reader should take note of the Overarching principles and the use of FHIR packages. Where the general IG uses the term ‘use case’, this IG follows the functional specification in using the term ‘transaction’ for the various processes that are described. The functional specification uses the term ‘use case’ for more practical examples.
This IG first describes the boundaries and relationships in place, after which the implementation is described per transaction.
2 Boundaries and relationships
2.1 Building blocks and profiles
The exchange of data within the CiO standard version is partly based on the 2020 publication of the Dutch Health and Care Information Models (Dutch: ‘zorginformatiebouwstenen’ or ‘zibs’), and subsequent changes made that are present in the 2022 prepublication. In particular, the prepublication of 2021 saw the introduction of the Hypersensitivity and Reaction zibs which are based on and still have quite some overlap with the zib AllergyIntolerance that already existed. The functional data set of CiO has further built upon the former two zibs (renaming the first as HypersensitivityDisposition), next to the zib MedicationContraIndication. These objects (which are actually exchanged) are referred to as ‘building blocks’ in the data set, and can thus be seen as ‘extended zibs’ suitable for implementation.
Due to new insights, the building blocks HypersensitivityDisposition and Reaction in the functional data set have deviated quite a lot from the zib AllergyIntolerance present in the 2020 publication, making them incompatible in varying degrees from a technical point of view. Therefore it was not possible to implement the FHIR profiles for these building blocks by building on and extending the nl-core profiles based on zib publication 2020. Hence the profiles for these building blocks have been created ‘independently’ from the nl-core profiles, meaning that they are not derived from nl-core-AllergyIntolerance. For the building block MedicationContraIndication on the other hand, the changes made within CiO are quite minimal with respect to its zib 2020 counterpart, making it possible to derive from nl-core-MedicationContraIndication.
Lastly it is important to note that there is still extensive discussion about the exact scope, name and structure of the HypersensitivityDisposition and Reaction building blocks, meaning that the current profiles definitely cannot be considered to be stable and ready for use. To aid in the discussion, two sets of FHIR profiles have been made for these building blocks:
- The cio-HypersensitivityDispositionReaction profile is created on the
AllergyIntoleranceresource and closely follows the nl-core-AllergyIntolerance profile corresponding to the zib AllergyIntolerance present in the 2020 publication. However due to incompatibilities (mainly on the level of terminology) it is not actually derived from that profile. The cio-HypersensitivityDispositionReaction profile contains both the HypersensitivityDisposition and Reaction building blocks, which makes sense as the Reaction building block is never exchanged on its own, but always in the context of a certain HypersensitivityDisposition. The main advantage in this profiling approach lies in the fact that it semantically makes the most sense, and the FHIR resourceAllergyIntolerancealready contains quite a lot of counterparts to the concepts in the functional data set (in particular on the level of the Reaction). - The cio-HypersensitivityDisposition and cio-Reaction are created on the
ConditionandObservationresources, respectively. Using this approach there are less custom extensions necessary to properly map the concepts from the functional data set, and it makes it easier to identify and handle Reactions. The main disadvantages are semantically of nature, for instance the mapping of the SubstanceToMonitor concept (which is a key concept in the HypersensitivityDisposition building block) is not as straightforward, and quite some concepts within the Reaction building block are mapped onObservation.components, while they have a direct counterpart in the other profiling approach.
|
|
Nictiz uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version. |
2.1.1 Main building blocks
As described above, only the MedicationContraIndication building block has a dependency on its zib2020 counterpart. Nevertheless all building blocks have resulted in so-called ‘cio’ profiles.
| Building block (EN) | Building block (NL) | FHIR resource | FHIR profile |
|---|---|---|---|
| HypersensitivityDisposition | Overgevoeligheid | AllergyIntolerance | http://nictiz.nl/fhir/StructureDefinition/cio-HypersensitivityDispositionReaction |
| Reaction | Reactie | ||
| HypersensitivityDisposition | Overgevoeligheid | Condition | http://nictiz.nl/fhir/StructureDefinition/cio-HypersensitivityDisposition |
| Reaction | Reactie | Observation | http://nictiz.nl/fhir/StructureDefinition/cio-Reaction |
| MedicationContraIndication | MedicatieContraIndicatie | Flag | http://nictiz.nl/fhir/StructureDefinition/cio-MedicationContraIndication |
2.1.2 Supporting building blocks
Additionally, the standard uses several supporting building blocks referenced from the main building blocks. All supporting building blocks are part of either the ‘nl-core’ or ‘medicationprocess9’ package.
Note the following:
- Each occurrence of the zib HealthProfessional is normally represented by two FHIR resources: an instance of nl-core-HealthProfessional-PractitionerRole and an instance of nl-core-HealthProfessional-Practitioner. Sending systems should only fill the reference to the PractitionerRole instance where relevant. Receiving systems can resolve the reference to the Practitioner resource from that PractitionerRole instance.
- The zib HealthcareProvider is mapped to both a Location and Organization profile. In general the Location profile acts as the focal resource, because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. However, within the main building blocks in CiO the HealthcareProvider is always present as an author, hence a reference to the Organization profile is sufficient in those cases. The Location profile, although not directly referenced from the main building blocks, is mentioned in the table above for completeness purposes (as it is referred to in supporting resources).
2.2 Mappings between profiles and data set
Each transaction starts with links to the functional definition in an ART-DECOR publication and references one or several FHIR profiles. The FHIR profiles contain mappings to all data elements that are present in the functional data set (prefixed with ‘cio-dataelement-20-’).
Each transaction contains a Patient building block with cardinality 1..1 M. This patient is the subject of all other building blocks in the transaction, although no explicit relation exists in the data set. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject (or .patient in the case of the AllergyIntolerance resource) of each FHIR instance of each main building block.
Relations between different building blocks exist in transactions by means of concepts with a name starting with ‘Relation…’ (Dutch: ‘Relatie…’) and an underlying concept 'Identification' of data type Identification, for example RelationHypersensitivityDisposition (cio-dataelement-20-734) in building block HypersensitivityDisposition. These relations are mapped to the FHIR data type ‘Reference’. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible, see the general FHIR IG on the Reference data type.
2.3 Patient identification
This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.
When patient identification requires the use of search parameters, the following search parameters SHALL be supported:
- Patient:
identifier - AllergyIntolerance:
patient.identifier - Condition:
patient.identifierandsubject:Patient.identifier - Observation:
patient.identifierandsubject:Patient.identifier - Flag:
patient.identifierandsubject:Patient.identifier
An example of a request that retrieves all AllergyIntolerance resources of a patient with a fake BSN of 11122233:
GET [base]/AllergyIntolerance?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333
All request examples in this document do not include patient identification mechanisms. Requesters are assumed to include these if necessary.
3 Release notes
Release notes can be found on the functional design page.
