Netherlands - Generic Functions for data exchange Implementation Guide
0.1.0 - ci-build
Netherlands - Generic Functions for data exchange Implementation Guide
0.1.0 - ci-build
Netherlands - Generic Functions for data exchange Implementation Guide, published by Ministerie van Volksgezondheid, Welzijn en Sport. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/minvws/generiekefuncties-docs/ and changes regularly. See the Directory of published versions
| Page standards status: Draft |
Patient data is often divided over multiple data holders. Generic Function Localization provides a standardized framework that enables healthcare professionals to discover which organizations hold relevant patient data of a specific type.
GF-Localization is based on the IHE MHD profile and 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:
These 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
The Pseudonymization Service is responsible for creating and retrieving Polymorphic Pseudonyms of Patient identifiers using Oblivious Pseudorandom Function (OPRF) protocols.
A Localization Client is responsible for registering and managing localization records at the Localization Service on behalf of healthcare organizations. The client is typically embedded within or integrated with Electronic Health Record (EHR) systems, Picture Archiving and Communication Systems (PACS), or other clinical systems that manage patient data.
The Localization Client MUST support the following capabilities:
The client SHALL be able to create and register List resources (localization records) at the Localization Service. The client MUST support Bundle transactions to register localization records:
transactionPseudonymization Integration: Before submitting localization records, client MUST obtain a pseudonymized patient identifier from the Pseudonymization Service. This pseudonym is a transient encrypted token (JWE) intended for single-use in registration or query operations.
Data Holder Identification: The client MUST include the appropriate organization identifier (URA) in the nl-gf-localization-custodian extension of each localization record to identify the data holder/custodian.
Example Bundle Transaction: For more information on the content, see the paragraph on Localization record
{
"resourceType": "Bundle",
"id": "nvi-org1",
"entry": [
{
"request": {
"method": "POST",
"url": "List"
},
"resource": {
"resourceType": "List",
"extension": [
{
"valueReference": {
"identifier": {
"system": "http://fhir.nl/fhir/NamingSystem/ura",
"value": "11111111"
}
},
"url": "http://minvws.github.io/generiekefuncties-docs/StructureDefinition/nl-gf-localization-custodian"
}
],
"subject": {
"identifier": {
"system": "http://fhir.nl/fhir/NamingSystem/pseudo-bsn",
"value": "UHN1ZWRvYnNuOiA5OTk5NDAwMw=="
}
},
"source": {
"identifier": {
"system": "https://cp1-test.example.org/device-identifiers",
"value": "EHR-SYS-2024-001"
},
"type": "Device"
},
"status": "current",
"mode": "working",
"emptyReason": {
"coding": [
{
"code": "withheld",
"system": "http://terminology.hl7.org/CodeSystem/list-empty-reason"
}
]
},
"code": {
"coding": [
{
"code": "MEDAFSPRAAK",
"system": "http://minvws.github.io/generiekefuncties-docs/CodeSystem/nl-gf-zorgcontext-cs",
"display": "Medicatieafspraak"
}
]
}
}
}
],
"type": "transaction"
}
The client SHALL support searching for List resources (localization records). This enables healthcare professionals to discover which organizations hold relevant patient data. The Localization Client SHALL support the following search parameters:
Client SHALL either use the patient.identifier or source.identifier in a search.
Example Search Query:
GET [base]/List?patient.identifier=http://fhir.nl/fhir/NamingSystem/pseudo-bsn|UHN1ZWRvYnNuOiA5OTk5NDAwMw==&code=LABBEPALING
The search operation returns a Bundle of type searchset containing matching List resources, allowing the client to identify which data holders have specific types of patient data.
This response will not contain the (pseudomized) patient.identifier for privacy/security reasons.
The Localization Client MUST implement the following requirements when interacting with the Pseudonymization Service:
1. Prepare PRS Interaction
Construct context string: {recipient_organization}|{recipient_scope}|{version} (e.g., "URA-NVI |
localization | v1") |
blind_factor: Retained for NVI processingblinded_input: Sent to Pseudonymization Service (PRS)2. PRS Interaction
blinded_input to PRS3. Localization Record Submission
subject.identifier.valueReference implementations: OPRF.py
Within GF-Localization the NL-gf-localization-List 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:
Device reference with an identifier.emptyReason is set to withheld because this List signals the existence of data at a custodian, without enumerating the actual records. The List resource is used as a localization pointer, not as a container for document referencesA Location record example is in the IG artifacts.
Link to 'NVI/PRS Aansluitdocument'?
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.
Scenario: A healthcare organization needs to retrieve all localization records it has registered in the National Localization Service (NVI). This is useful for administrative purposes, data quality checks, reconciliation, or audit trails. This query retrieves all localization records registered by a specific device/system (the Localization Client)
GET [base]/List?source.identifier=https://cp1-test.example.org/device-identifiers|EHR-SYS-2024-001
Response: The NVI returns a Bundle of type searchset containing all matching List resources registered by the specified organization or device.
Potential future enhancements to the Localization Service include: