MedMij FHIR Implementation Guide GP Patient Data

MedMij:Vprepub/Issuebox FHIR IG

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

Persons		Systems		FHIR Capability Statements
Name	Description	Name	Description	Name	Description
Patient	The user of a personal healthcare environment.	PHR	Personal health record	CapabilityStatement: Client	GP Patient Data client requirements
Healthcare professional	The user of a XIS	XIS	Healthcare information system	CapabilityStatement: Server	GP Patient Data server requirements

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 StructureDefinitions 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.

Bijlage 1 Richtlijn Online inzage in het H-EPD door patiënt
#	GP Patient Data Section	HCIM EN	Content	Search URL
1	General Practitioner/Practice	HealthProfessional v3.1 (2017) HealthcareProvider v3.1 (2017)	The GP or GP practice that originates the patient data.	TODO. Check assumption here that a patient requests the data from his regular GP. If he were to request it from any other GP/practice he might have visited, then the Patient.generalPractitioner does not apply. see Patient
2	Patient	Patient v3.1 (2017)	De patient data of the patient the data is for. Note that retrieving patient data separately may not be supported by GP systems in some circumstances. Patient data will however be part of the other responses in that case.	GET [base]/Patient?_include=Patient:general-practitioner
3	Episodes		A health concern like a complaint of illness, that may change in nature as diagnoses are made and/or the illness develops.	GET [base]/EpisodeOfCare GET [base]/Flag
4	Episodes with alert flag		Episodes may have an associated alert signaling extra attention to the episode is requested. The alert flag may stay active even if after closing the episode, if the user deems it important to stay aware.
5	Open and closed episodes		Episodes may be open (currently active) or closed (no longer active).
6	Treatment		Procedure on the patient targeting the patients health situation. E.g. operative and (severe) procedures like radiation or chemotherapy.	TODO: No HCIM. GP systems do not yet export this info.
7	Prophylaxis en precaution		Prophylaxis and precaution contain precautionary measures required for or to prevent certain medical conditions. See NHG Tabel 56	TODO: No HCIM. GP systems do not yet export this info. Unclear if it'll be anything beyond the Table 56 code (id, time, author, text?)
8	Current medication	MedicationAgreement v1.0 (2017)	MedicationAgreement The prescriber proposed use of medication that the patient agrees with. The agreement may signal starting, repeating, updating or stopping the medication. The list of MedicationAgreements is also known as the list of medication the patient is currently using. Note that current means that the period of use is still active. This is conveyed in the MedicationRequest.extension periodOfUse. This may or may not me populated. If it is not, the Medicationagreement is assumed to be current. The search parameter Medications-periodofuse allows filtering for current medicationagreements	GET [base]/MedicationRequest?periodofuse=ge[today]&category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication
9	Medication intolerance	AllergyIntolerance v3.1 (2017)	A medication intolerance concerns the intolerance of a patient for a specific drug, substance or substance group, that needs to be taken into account when prescribing, dispensing or administering medication.	GET [base]/AllergyIntolerance?category=medication
10	Correspondence		Incoming: an incoming letter about a patient, recorded as such in the patients medical record. Outbound: a letter created by a healthcare professional for a third party healthcare professional.	TODO: No HCIM. GP systems do not yet export this info.
11	Lab results	LaboratoryTestResult v4.0 (2017)	A lab test is an objectifiable diagnostic procedure. The result is the outcome of the procedure. Lab tests include vital signs like blood pressure, weight and lab results like ferro in blood. Note that GP (lab) results are normally coded using NHG Tabel 45. While some of these codes might be convertible to LOINC or SNOMED CT, this is not expected at present. Bridging code systems between primary and secondary care is part of a larger national discussion Note that the date parameter is optional and needs calculation, e.g. current-date() - 14 months. The business rules in the guide lines determine the maximum range for the returned results. If the date parameter is omitted, the maximum range is assumed	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
		BloodPressure v3.1 (2017)
		BodyHeight v3.1 (2017)
		BodyTemperature v3.1 (2017)
		BodyWeight v3.1 (2017)
		GeneralMeasurement v3.0 (2017)
		HeartRate v3.1 (2017)
		O2Saturation v3.1(2017)
		PulseRate v3.1(2017)
12	E- and P-journal entries of the SOAP (EN) or SOEP (NL) structure - recorded after introduction of online access		Information from an encounter, recorded in free text using the SOAP structure. The acronym SOAP stands for Subjective, Objective, Assessment and Plan. The E entry contains the consultation conclusion and the P entry contains potential next steps. Note that the profile for SOAP entries is yet to be created and the code system value is preliminary	TODO: LOINC code has status proposal GET [base]/Composition?type=http://loinc.org|67781-5 The basic rules for Composition apply which means that even without the _include parameter, the server is required to return these references as applicable: Composition.subject Composition.encounter Composition.author Composition.attester.party Composition.custodian Composition.event.detail Composition.section.entry This means there is no need for explicit client request along these lines.

4.2 Server - XIS

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

4.3 Custom search parameters

The custom search parameter Medications-periodofuse searches on the FHIR datatype Period in the PeriodOfUse extension, which is added to profiles on MedicationRequest and MedicationDispense. 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 are known, but not the Period, the Duration should be added to the Period.start date to calculate Period.end. The calculated Period.end date is then used to determine the search results.

4.4 List of StructureDefinitions

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.

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: nictiz.fhir.nl.stu3.zib2017, Note: any other version with the same major.minor version is compatible. See Semantic Versioning for more information.

Bijlage 1 Richtlijn Online inzage in het H-EPD door patiënt
Section	Zib NL	HCIM EN	FHIR Resource	URL Profile
1	Zorgverlener	HealthProfessional		http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
	Zorgaanbieder	HealthcareProvider	Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization
2	Patiënt	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
3			EpisodeOfCare	http://nictiz.nl/fhir/StructureDefinition/zib-Alert http://fhir.nl/fhir/StructureDefinition/nl-core-episodeofcare
4
5
8	MedicatieAfspraak	MedicationAgreement	MedicationRequest	http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement
9	AllergieIntolerantie	AllergyIntolerance	AllergyIntolerance	http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance
11	LaboratoriumUitslag	LaboratoryTestResult	Observation	http://nictiz.nl/fhir/StructureDefinition/gp-DiagnosticResult (NHG Table 45 codes of type D) http://nictiz.nl/fhir/StructureDefinition/gp-LaboratoryResult (NHG Table 45 codes of type L)
	Bloeddruk	BloodPressure
	Lichaamslengte	BodyHeight
	Lichaamstemperatuur	BodyTemperature
	Lichaamsgewicht	BodyWeight
	AlgemeneMeting	GeneralMeasurement
	Harfrequentie	HeartRate
	O2Saturatie	O2Saturation
	Polsfrequentie	PulseRate
12	E and P entry from SOAP/SOEP		Composition Observation	http://nictiz.nl/fhir/StructureDefinition/gp-EncounterReport http://nictiz.nl/fhir/StructureDefinition/gp-JournalEntry

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

5.1 Terminology

Relevant value sets can be found here. All resources can be downloaded in a .zip in XML or JSON format. In the .zip, the value sets are stored in the directory 'value sets'.

5.2 NamingSystems

Relevant NamingSystems can be found here.

5.3 Mappings

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.