MedMij FHIR Implementation Guide basic GGZ data 2.0.1
The page describes the FHIR requirements for exchanging GGZ information between the patients and healthcare providers in the context of MedMij.
Note: This implementation guide builds on the general guidelines described in the use case overarching principles.
2 Actors involved
|Actors||Systems||FHIR Capability Statements|
|Patient||The user of a personal healthcare environment.||PHR||Personal health record||CapabilityStatement: Client||FHIR Client requirements|
|Healthcare professional||The user of a XIS||XIS||Healthcare information system||CapabilityStatement: Server||FHIR Server requirements|
3 Boundaries and Relationships
The GGZ use case has similarities and differences with other use cases such as the BgZ, Medication Process, Vital Signs, GP Patient Data and Lab Results. These use cases use much of the same HCIM based FHIR profiles for exchanging information. Wherever possible every attempt is made to re-use the profiles as used in the BgZ. The GGZ use case also has unique profiles compared to the aforementioned use cases. In addition, it has a CareTeam profile without an underlying HCIM. A second thing to note is that while the selection criteria of certain sections like procedure do not match with the BgZ or other use cases, this does not affect the profiles in use. For example, it is irrelevant for the response profile for procedures if you request ' surgical procedures' or 'every procedure'.
4 Use case: retrieve GGZ information
This FHIR implementation guide assumes that the PHR system 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 XIS nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, for whose context (token) has been established using the authentication mechanisms described in the 'Afsprakenstelsel'. 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 should not be included for patient identification.
4.1 PHR: request message
The PHR system requests the patients GGZ information using individual search interactions. The BgGGZ consists of multiple FHIR resources with certain constraints. To obtain the patient's BgGGZ, the client can use multiple individual search operations based on specified search queries. The interactions are performed by an HTTP GET as shown:
The table below shows in the first three columns the HCIM name in Dutch, in English and what HCIM content is requested. The last column shows the FHIR search queries to obtain this information. These queries and expected responses are based on profiles listed in this section.
|HCIM NL||HCIM EN||Content||Search URL|
|Patient||Patient||Identification, birthdate, gender, deceasedindicator, contact details, marital status, legal status, and general practitioner (practitioner or organization)|
|BurgerlijkeStaat||MaritalStatus||Known marital status||see Patient|
|BehandelAanwijzing||TreatmentDirective||All known treatment directives|
|Wilsverklaring||AdvanceDirective||All known advance directives|
|JuridischeStatus||LegalStatus||Known legal status||see Patient and FreedomRestrictingMeasures procedure|
|VrijheidbeperkendeMaatregelen||FreedomRestrictingMeasures||All known freedom restricting measures||see Procedure|
|Contactpersoon||Contact||First relation/contact||see Patient.contact|
|FunctioneleOfMentaleStatus||FunctionalOrMentalStatus||All known functional / mental status|
|Probleem||Problem||All known problems|
|Druggebruik||DrugUse||All known drug use|
|Alcoholgebruik||AlcoholUse||All known alcohol use|
|Tabakgebruik||TobaccoUse||All known tobacco use|
|Woonsituatie||LivingSituation||Last known living situation|
|Gezinssituatie||FamilySituation||All known family situations|
|GezinssituatieKind||FamilySituationChild||All known family situations of child patient|
|Taalvaardigheid||LanguageProficiency||Known language proficiency||see Patient|
|ParticipatieInMaatschappij||ParticipationInSociety||All known participation in society status|
|HulpVanAnderen||HelpFromOthers||All known help from others|
|LaboratoriumUitslag||LaboratoryTestResult||Last known laboratory results per type (incl. medication levels like lithium)|
|AlgemeneMeting||GeneralMeasurement||All known questionaire (for example HONOS, OQ-45, CQ index, 4DKL) outcome scores.|
|Verrichting||Procedure||All known GGZ procedures (includes all known freedom restricting measures)|
|TekstUitslag||TextResult||All known text results of GGZ procedures|
|-||-||CareTeam: primary healthprofessional and other relevant healthprofessionals including the healthcare provider.|
|Zorgverlener||HealthProfessional||General Practitioner of the patient||see Patient, CareTeam|
|Zorgaanbieder||HealthProvider||General Practitioner's organization of the patient||see Patient, CareTeam|
- See Search URLs and search parameters for the interpretation of these search URLs
4.2 Server - XIS
The returned data to the PHR should conform to the profiles listed in #List_of_profiles.
The following operation is needed for this use case.
lastn query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.
The FHIR STU3 specification is vague regarding the sorting mechanism of
lastn. In FHIR R4 however, this has been clarified and can be read as follows: when using
effective[x] element is used for sorting of Observations, sorted from most recent to the oldest.
4.4 List of profiles
The profiles represent their entire respective HCIM and are applicable in a broader context than the exchange of GGZ information.
MedMij uses the FHIR Packaging mechanism. This conveniently bundles all examples, profiles 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: any other version with the same major.minor version is compatible. See Semantic Versioning for more information.
* LegalStatus is a single concept of the HCIM FreedomRestrictingMeasures and does not represent a complete HCIM yet. This concept will become an independent HCIM in a future release of the HCIM.
Example instances of FHIR resources can be found on Simplifier. Please note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of any information standard.
5 Terminology, NamingSystems, Mappings
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here here and can be downloaded as a .zip in XML or JSON format.
Relevant NamingSystems can be found here.
A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found here.
An explanation about mappings can be found at Mapping of coded concepts.
6 Release notes
Release notes can be found on the functional design page.