MedMij FHIR Implementation Guide GP Patient Data 2.0.37 (2024)

1 Introduction

The input document "Richtlijn online inzage in het H-EPD door patiënt" (Dutch) described online access of GP data by patients. The use case evolves around a GP specific Patient Data that consists of 10 sections plus the patient and the healthcare provider (GP). These sections correspond to the "HIS referentiemodel Publieksversie 2016" (Dutch). HIS referentiemodel is the GP information system reference model (GP-IS-RM).

Some but not all sections in the GP Patient Data correspond to Health and Care Information Models (HCIMs (English) or zibs (Dutch)). A joint initiative project between Nictiz and the Dutch GP association NHG is underway to analyse the relationship between the GP-IS-RM and the HCIMs and propose updates where needed. This analysis will not yield results before 2019. This specification thus predates the analysis, and will updated accordingly moving forward.

This page will elaborate further on the HL7 FHIR details needed to exchange the GP Patient Data information using FHIR.

Note: This implementation guide builds on the general guidelines described in the use case overarching principles.

2 Actors involved

3 Boundaries and Relationships

The GP Patient Data use case has similarities and differences with other use cases such as the BgZ, Medication Process, Vital Signs 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 GP Patient Data also has a few unique profiles compared to the aforementioned use cases. A second thing to note is that while the selection criteria of certain sections like lab do not match, this does not affect the response profiles. For example it is irrelevant for the response profile lab if you request the 'latest lab result' or 'every result since date X'.

4 List of invocations

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 Client - PHR

The PHR system requests the GP Patient Data using individual search interactions. The search interaction searches the current resources based on some filter criteria. The interactions are performed by an HTTP GET or command as shown:

GET [base]/[type]{?[parameters]}

The table below shows in the first four columns the GP Patient Data sections, the GP-IS-RM sections / HCIMs that constitute those sections and the specific content of the GP Patient Data. The last column shows the FHIR search queries to obtain the GP Patient Data information. These queries are based on profiles listed in this section. As noted in the introduction, the associated HCIMs are ahead of a separate joint initiative project that aims to analyse and harmonize this further.

see Patient

GET [base]/Patient?_include=Patient:general-practitioner

GET [base]/EpisodeOfCare

GET [base]/MedicationRequest?periodofuse=ge[today]&category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication

GET [base]/AllergyIntolerance?category=medication

GET [base]/Observation?code=https://referentiemodel.nhg.org/tabellen/nhg-tabel-45-diagnostische-bepalingen|&_include=Observation:related-target&_include=Observation:specimen&date=ge2017-01-01

GET [base]/Composition?type=http://loinc.org|67781-5

GET [base]/Encounter

4.2 Server - XIS

The returned data to the PHR should conform to the profiles listed in #List_of_profiles.

4.3 Custom search parameters

Clients can search for MedicationRequest and MedicationDispense resources based on the period of use, using the custom search parameter Medications-periodofuse. This search should be treated as a search on Period as described by the FHIR specification. During processing of the search, servers should take into account the Period value from the Medication-PeriodOfUse extension and the Duration value from the MedicationUse-Duration extension in these resources. This Duration should be used to dynamically calculate Period.end if this is not specified.

To illustrate the expected behavior: if a client requests MedicationRequest resources after March 7th, 2023, like so:

 GET http://example.org/MedicationRequest?periodofuse=ge2023-03-07

The server should include a MedicationRequest resource where Period.start is populated with 2023-03-01 and the Duration is populated with 14 days, because the date searched on falls between Period.start en the dynamically calculated Period.end.

In order to allow the client to be confident about what search parameters were used as criteria by the server, the server SHALL return the parameters that were actually used to process the search. Applications processing search results SHALL check these returned values where necessary. For example, if the server did not support some of the filters specified in the search, a client might manually apply those filters to the retrieved result set, display a warning message to the user or take some other action.

In the case of a RESTful search, these parameters are encoded in the self link in the bundle that is returned:

<link> <relation value="self"/> <url value="http://example.org/MedicationRequest?periodofuse=ge2023-03-14/></link>

Link to the relevant FHIR specification: http://hl7.org/fhir/STU3/http.html#search

5 Interactions, operations, search parameters

5.1 Interactions

The following logical interactions are needed for the GP Patient Data use case:

• Search
• Batch/Transaction

5.2 Operations

There are no operations required to support this use case

5.3 Search parameters

The following search parameter types and search result parameters need to be supported for this use case.

Search parameter types:

Search result parameters:

• _include
• _revinclude
• periodofuse *

* This SearchParameter searches on the FHIR DataType Period in the PeriodOfUse extension, which is added to profiles on MedicationRequest and MedicationDispense resources. Clients use date parameter searches as described by the FHIR specification. Servers are expected to take the MedicationUse-Duration extension into account when processing a client's search. This means that either a Period.start + Period.end or Period.start + Duration is used to determine the search results. To illustrate the expected behavior: if a Period.start and a Duration is known, but not the Period, the Duration should be added to the Period.start date to calculate the Period.end. The calculated Period.end date is then used to determine the search results.

6 List of profiles

The profiles represent their entire respective HCIM, to make them applicable in a broader context than the exchange of GP Patient Data or a MedMij context. An example for reuse of existing profiles are those of the patient administration resources and vital signs.

6.1 Referencing encounters and episodes

During early testing of the published information standard, an omission was found. Any journal entry or other activity, and in some cases medication agreement and diagnostic results is associated with an encounter (Encounter resource in FHIR), but an additional association with one or more episodes (EpisodeOfCare in FHIR) is also normal GP practice. However, it is not possible to do this natively in the currently used FHIR version STU3: many resources define the element .context (Encounter | EpisodeOfCare), but restricts its cardinality to 0..1, meaning that a resource can be connected to either an Encounter or EpisodeOfCare resource, but not both.

The recommendation is to use .context for associating the Encounter, not the EpisodeOfCare. This approach aligns with the changes in FHIR version R4, where the .context element is replaced by .encounter to support just a reference to an Encounter resource. EpisodeOfCare resource can be referenced through a new extension published in the spring of 2021 (package 2.1.1): http://nictiz.nl/fhir/StructureDefinition/extension-context-nl-core-episodeofcare.

Compatibility note: systems that went in production before this new extension was published will not be able to interpret it, unless they update for it. These systems will ignore the extension and read - as specified - the .context which is normally claimed by a reference to Encounter. Updated and newer systems may now anticipate episode associations on journal entries, diagnostic results, medication agreements and potential other encounter activities, as applicable. For more details, please see issue MM-1521.

Release notes can be found on the functional design page.

For questions and change requests regarding the information on this page, please create a ticket in Servicedesk Portal.