Netherlands - Generic Functions for data exchange Implementation Guide
0.2.0 - ci-build
Netherlands - Generic Functions for data exchange Implementation Guide
0.2.0 - ci-build
Netherlands - Generic Functions for data exchange Implementation Guide - Local Development build (v0.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
This FHIR Implementation Guide specifies the Generic Function 'Medical Record Localization' (GF Localization), a national initiative led by the Dutch Ministry of Health, Welfare and Sport (VWS). GF-Localization provides a standardized framework that enables healthcare professionals to discover which organizations hold relevant patient data of a specific type, ensuring GDPR compliance through proportionality and subsidiarity principles while facilitating secure and efficient health information exchange.
Patient data is divided over multiple data holders. In today’s healthcare landscape organizations rely on several different types of indices to find data concerning a specific patient and context. However, none of these indices are complete and all of these indices have different requirements for usage, hindering interoperability and timely access to health information. GF-Localization addresses this challenge by providing a unified framework that ensures an index of all data holders concerning a specific patient and type is easily and securely accessible.
This guide outlines the technical requirements and architectural principles underlying GF-Localization, with a focus on trust, authenticity, and data integrity. Key design principles include:
By adhering to these principles, this Implementation Guide supports consistent and secure data holder discovery, fostering improved interoperability within the healthcare ecosystem.
GF-Localization follows the choices made by the MinvWS Localization working group, see GF-Lokalisatie, ADR's. This guide specifies the choices made. Most impactful/striking choice are:
Here is a brief overview of the processes that are involved:
Both processes require the use of pseudonyms that are generated and resolved using a national Pseudonymization Service. The Localization service-response provides a list of data holders; the endpoints of these data holders (e.g. FHIR or DICOM-urls) need to be resolved using a Care service (Query) Directory. This process is illustrated in this example.
For more detail on the topology of GF-Localization, see GF-Lokalisatie, ADR-2. Each component, data model, and transaction will be discussed in more detail.
A (Medical Record) Localization Service is responsible for managing the registration, maintenance, and publication of localization records. It should be able to create and update localization records. A Localization Service MUST implement these FHIR capabilities and basically involves creating and searching for FHIR DocumentReferences (see )
A Local Metadata Register (LMR) is responsible for managing the registration, maintenance, and publication of the metadata of one data holder (the custodian or the healthcare organization). To implement an LMR, existing FHIR-APIs of data sources can be used. This decision was made to simplify the implementation and reduce complexity while still meeting the core requirements of metadata-based searching. Resource Metadata is registered in every FHIR resource type and can be found by standard search-parameters. In the Netherlands, both FHIR R4 and FHIR STU3 are used.
The Pseudonymization Service is responsible for creating and retrieving Polymorphic Pseudonyms of Patient identifiers. It involves multiple interactions for both a FHIR request and a FHIR response:
Within GF-Localization the NL-gf-localization-DocumentReference profile is used to register, search, and validate localization records (NL-GF-IG, ADR#10). This data model basically states "Care provider X has data of type Y for Patient Z". It contains the following elements:
A Location record example is in the IG artifacts.
One of things you can do to mitigate privacy risks: Please don't put dates or references to actual documents into the localization records since it can expose the identity patient
The initial implementation uses plain BSN (Burgerservicenummer) for simplicity. In a later stage, this will be replaced with pseudo-BSNs to enhance patient privacy. The pseudonymization service will ensure that patient identities are protected while still allowing organizations to use a joint index.(GF-Lokalisatie, ADR-1)
Authentication and authorization follows the GF Authorization specification. The required authentication and authorization attributes for Localization Service are:
For POST operations (registering localization records):
For GET operations (querying localization records):
These attributes ensure proper access control and auditing while maintaining the security requirements outlined in the GF Authorization specification.
Scenario: Dr. Carter, a radiologist at a care provider organization, performs an imaging study for a patient. To enable data discovery by other healthcare professionals, Dr. Carter's organization must register the existence of this imaging data in the national localization index (NVI). This process involves pseudonymizing the patient's identifier, creating a localization record, and submitting it to the NVI with the appropriate authorization attributes.
The following diagram illustrates the registration workflow, including interactions between the radiologist, the PACS system and the NVI. For brevity, interactions to the Pseudonymization Service are left out here.
Scenario: Dr. Smith, a cardiologist at Hospital A, is treating a patient who was recently referred from another hospital. She needs to know what imaging data (X-rays, CT scans, MRIs) might be available from other healthcare providers to avoid unnecessary duplicate examinations and to get a complete picture of the patient's medical history.
For brevity, interactions to the Pseudonymization Service are left out here.
Potential future enhancements to the Localization Service include: