MedMij:V2017.04 FHIR BGZ

Introduction

The program ‘Registratie aan de bron’ (Data capture at the point of Care) has defined Health and Care Information models (zorginformatiebouwstenen or ZIB's) for The Netherlands. Next to these ZIB's, the program ‘Registratie aan de bron’ also made a selection of these ZIB's into the so called ‘Basisgegevensset Zorg’ (Common Clinical Dataset, a Dutch version of a ‘patient summary’, further referred to as ‘BgZ’). The BgZ serves as a minimal healthcare dataset that is always appropriate for caregivers in order to provide continuity of care for a patient and can be seen as representation of a patient summary.

A total of 26 ZIB's constitute the BgZ version 1.0. The BgZ makes a subselection of the information concepts within these 26 ZIBs or restricts the ZIBs to a certain category. For example, only include the general practitioner of the patient or only the last known value of 'X'. MedMij created FHIR profiles that represent these 26 ZIBs completely, if no existing and usable profiles were available. The profiles represent their entire respective ZIB, to make them applicable in a broader context than a patient summary or even the MedMij context. An overview of the profiles can be found at the list of StructureDefinitions.

The patient journey of Thomas van Beek, provides a patient's context for exchanging a patient summary from a healthcare provider's system (XIS) to a personal health record (PHR). MedMij created a functional design of the BgZ use case. This use case consists of enabling a patient to view his own BgZ in a PHR. This page will elaborate further on the HL7 FHIR details needed to exchange the BgZ information using FHIR.

Actors involved

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

Boundaries and Relationships

The BgZ use case has similarities and differences with other use cases such as Medication Process, Vital Signs and Lab Results. These use cases use the same ZIB based FHIR profiles for exchanging information. The BgZ use case covers practically all profiles included in the other use cases. However, the BgZ differs in scope of the actual health information content that should be exchanged. For example, the BgZ conveys only the last known lab result of each type while the Lab Results use case may cover all known information.

List of invocations

This FHIR implementation guide assumes that the PHR system is able to make a connection to the XIS that contains the patients BgZ information. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the 'Afsprakenstelsel'.

Client - PHR

The PHR system can request the BgZ using individual search interactions. The search interaction searches the current resources based on some filter criteria. The interaction can be performed by an HTTP GET or command as shown:

GET [base]/[type]/{?[parameters]{&_format=[mime-type]}}

The BgZ consists of multiple FHIR resources with certain constraints. To obtain the patients BgZ, the client can use multiple individual search operations based on specified search queries. The client may also bundle the search operations in a batch. The individual requests are discussed first, followed by the batch procedure.

Individual resource requests

The table below shows in the first four columns the BgZ sections, the ZIBs that constitute those sections and the specific content of the BgZ. The last column shows the FHIR search queries to obtain the BgZ information. These queries are based on StructureDefinitions listed in this section.

Each query is performed in the context of a specific authenticated patient, for which an OAuth2 token has been retrieved using the Authentication mechanisms described in the 'Afsprakenstelsel'. This token must be passed in each call in the HTTP header named “Authorization”. Each XIS Gateway is required to perform filtering based on the patient associated with the OAuth2 token received for the request, so that only the records associated with the authenticated patient are returned. Therefore, no search parameters should be passed for patient identification.

#	BgZ Section	ZIB EN	Content	Example Search URL
1	Patient information	Patient	BSN, birthdate, gender, deceasedindicator, contact details, and general practitioner (practitioner or organization)	GET [base]/Patient?_include=Patient:general-practitioner
2	Payment details	Payer	Insurance information	GET [base]/Coverage?_include=Coverage:payor:Patient&_include=Coverage:payor:Organization
3	Treatment Directives	TreatmentDirective	Known treatment directives	GET [base]/Consent?category=http://snomed.info/sct|11291000146105
		Advance directive	Known advance directives	GET [base]/Consent?category=http://snomed.info/sct|11341000146107
4	Contactperson	Contact	First relation/contact	see Patient
5	Functional status	FunctionalOrMentalStatus	Last known functional / mental status	GET [base]/Observation$lastn?category=http://snomed.info/sct|118228005,http://snomed.info/sct|364644000
6	Problems	Concern	All known problems for the following categories: problem, condition, diagnosis, symptom, finding, complaint, functional limitation, complication.	GET [base]/Condition?category:in=http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.1--20150401000000
8	Social history	MaritalStatus	Current marital status	see Patient
		LivingSituation	Current living situation	GET [base]/Observation/$lastn?code=http://snomed.info/sct|365508006
		DrugUse	All known drug use	GET [base]/Observation?code=http://snomed.info/sct|228366006
		AlcoholUse	All known alchol use	GET [base]/Observation?code=http://snomed.info/sct|228273003
		TobaccoUse	All known tobacco use	GET [base]/Observation?code=http://snomed.info/sct|365980008
		NutritionAdvice	All known current dietary recommendations	GET [base]/NutritionOrder?status=active
9	Alerts	Alert	All known alerts	GET [base]/Flag
		AllergyIntolerance	All known information regarding allergies	GET [base]/AllergyIntolerance
10	Medication	MedicationUse	Current medication use	GET [base]/MedicationStatement?status=active &category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include:MedicationStatement:medication
		MedicationAgreement	Current prescriptions	GET [base]/MedicationRequest?status=active &category=http://snomed.info/sct|16076005&_include:MedicationRequest:medication
11	Medial aids	MedicalAid	All known medicalaids	GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device
12	Vaccinations	Vaccination	All known vaccinations	GET [base]/Immunization?status=completed
13	Vital signs	BloodPressure	Last known bloodpressure	GET [base]/Observation/$lastn?code=http://loinc.org|85354-9
		BodyWeight	Last known body weight	GET [base]/Observation/$lastn?code=http://loinc.org|29463-7
		BodyHeight	Last known body height	GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9
14	Results	LaboratoryTestResult	Last known laboratory results per type	GET [base]/Observation/$lastn?category=http://snomed.info/sct|275711006&_include=Observation:related-target&_include=Observation:specimen
15	Procedures	Procedure	All surgical procedures	GET [base]/Procedure?category=http://snomed.info/sct|365508006
16	Encounters	Contact	All hospital admissions (no outpatient contacts)	GET [base]/Encounter?class=http://hl7.org/fhir/v3/ActCode|IMP,http://hl7.org/fhir/v3/ActCode|ACUTE,http://hl7.org/fhir/v3/ActCode|NONAC
17	Planned care	PlannedCareActivity	All known planned care activities	GET [base]/ProcedureRequest?status=active
				GET [base]/ImmunizationRecommendation?
				GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&status=in-progress,preparation
				GET [base]/DeviceRequest?status=active
				GET [base]/Appointment?status=booked,pending,proposed
18	General practitioner	HealthProfessional	General Practitioner of the patient	see Patient

Batch request

A FHIR Bundle resource can be used to group the individual resources requests of the BgZ. If a bundle is used to query the BgZ, the bundle SHALL be of type = "batch".

A batch (type = "batch") consists of a series of entries. Each entry element SHALL contain a request element. Each entry has the details of an HTTP operation that informs the system processing the batch what to do with the entry. The bundle with type = batch is a transaction that is intended to be processed by a server as a group of actions in contrary to a bundle with type = 'transaction' where the entire set of HTTP operations is intended to be processed by a server as an atomic commit.

A batch interaction is performed by an HTTP POST command as shown:

POST [base] {?_format=[mime-type]}

The content of the post submission is a Bundle with Bundle.type = batch. Each entry carries request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry (note: the request is optional, but SHOULD be present). Every bundle.entry retrieves a resource using a GET method and a specified url. The XML below demonstrates a batch of requests that can be send to a server. This example can also be found here.

<Bundle xmlns="http://hl7.org/fhir">
  <id value="bundle-request-simplesummary"/> 
  <type value="batch"/> 

  <!--   Each entry is used to represent a RESTful API request
       This request retrieves a single Patient resource   -->
  <entry> 
    <request> 
      <method value="GET"/> 
      <url value="/Patient/example"/> 
    </request> 
  </entry> 
  <!--   This request will retrieve the conditions for the patient   -->
  <entry> 
    <request> 
      <method value="GET"/> 
      <url value="/Condition?patient=example"/> 
    </request> 
  </entry>
  <!--   This request will retrieve the MedicationStatements for the patient
       requested above   -->
  <entry> 
    <request> 
      <method value="GET"/> 
      <url value="/MedicationStatement?patient=example"/> 
    </request> 
  </entry>  
</Bundle> 

Example batch request

A predefined BgZ bundle batch can be found here: https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2015/1.0.0/files/133147/~xml

As mentioned earlier, within MedMij each query is performed in the context of a specific authenticated patient. Therefore the search queries do not have to contain the patient ID. However, in a broader context these queries with the patient ID may be necessary. Another batch example that contains these example patient ID's in the URLs can be found here: https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2015/1.0.0/files/133104/~xml.

Server - XIS

Important sections of the FHIR specification for a server in this use case are the RESTful API section the search section and operation section (for the nlast operation).

Response on individual resource requests

If the search succeeds, the server SHALL return a 200 OK HTTP status code and the return content SHALL be a Bundle with type = searchset containing the results of the search as a collection of zero or more resources in a defined order. The result collection can be long, so servers may use paging. If they do, they SHALL use the method described below (adapted from RFC 5005 (Feed Paging and Archiving ) for breaking the collection into pages if appropriate. The server MAY also return an OperationOutcome resource within the searchset Bundle entries that contains additional information about the search; if one is sent it SHALL NOT include any issues with a fatal or error severity, and it SHALL be marked with a Bundle.entry.search.mode of outcome.

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/Patient?identifier=[Patient-ID]/>
  </link>

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

Response for a batch request

For a batch the response the server SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. For the BgZ bundle batch, the response is a bundle of type = batch-response with multiple entries containing bundles of type = searchset that correspond to the individual search queries.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

Link to relevant FHIR specification: http://hl7.org/fhir/STU3/http.html#transaction-response

Handling errors

If the search fails (cannot be executed, not that there is no matches), the return value is a status code 4xx or 5xx with an OperationOutcome. A HTTP status code of 403 signifies that the server refused to perform the search, while other 4xx and 5xx codes signify that some sort of error has occurred. When the search fails, a server SHOULD return an OperationOutcome detailing the cause of the failure. Note: An empty search result is not a failure.

In some cases, parameters may cause an error. For instance:

• A parameter may refer to a non-existent resource e.g. GET [base]/Observation?subject=101, where "101" does not exist
• A parameter may refer to an unknown code e.g. GET [base]/Observation?code=loinc|1234-1, where the LOINC code "1234-1" is not known to the server
• A parameter may refer to a time that is out of scope e.g. GET [base]/Condition?onset=le1995, where the system only has data going back to 2001
• A parameter may use an illegal or unacceptable modifier e.g. GET [base]/Condition?onset:text=1995, where the modifier cannot be processed by the server
• A data time parameter may have incorrect format e.g. GET [base]/Condition?onset=23%20May%202009
• A parameter may be unknown or unsupported

Where the content of the parameter is syntactically incorrect, servers SHOULD return an error. However, where the issue is a logical condition (e.g. unknown subject or code), the server SHOULD process the search, including processing the parameter - with the result of returning an empty search set, since the parameter cannot be satisfied.

In such cases, the search process MAY include an OperationOutcome in the search set that contains additional hints and warnings about the search process. This is included in the search results as an entry with search mode = outcome. Clients can use this information to improve future searches.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

• 400 Bad Request - search could not be processed or failed basic FHIR validation rules
• 401 Not Authorized - authorization is required for the interaction that was attempted
• 404 Not Found - resource type not supported, or not a FHIR end-point

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

Example batch response

An example of a batch response can be found here: https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2015/1.0.0/files/133105/~xml.

The batch-response is a bundle that contains bundles of the type = searchset in the entries. These bundles of type = searchset represent the individual queries in the bundle that is posted to the server. Please note that this example does not contain actual search results. There is no patient with the identifier '123456789' on the server. Therefore all the returned bundles are empty.

Interactions, operations, search parameters

Interactions

The following logical interactions are needed for the BgZ use case:

• Search
• Batch/Transaction

Operations

The following operation is needed to support this use case.

• Last N Observations Query

The 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 vitals signs. The link will provide more detailed information and examples regarding this operation.

Search parameters

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

Search parameter types:

• token
  • Including modifier 'in'
• reference

Search result parameters:

• _include
• _revinclude

List of StructureDefinitions

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

Section	ZIB NL	ZIB EN	FHIR Resource	URL Profile	Reference to section
01	Patient	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient	Patient
02	Betaler	Payer	Coverage	http://nictiz.nl/fhir/StructureDefinition/zib-Payer	Payer
			Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization	HealthcareProvider
			Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient	Patient
03	BehandelAanwijzing	TreatmentDirective	Consent	http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective	TreatmentDirective
	Wilsverklaring	AdvanceDirective	Consent	http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective	AdvanceDirective
04	Contactpersoon	Contact	RelatedPerson	http://fhir.nl/fhir/StructureDefinition/nl-core-relatedperson	RelatedPerson
05	Funct. OfMentaleStatus	FunctionalOrMentalStatus	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus	FunctionalOrMentalStatus
06	OverdrachtConcern	Concern	Condition	http://nictiz.nl/fhir/StructureDefinition/zib-Concern	Concern
08	BurgerlijkeStaat	MaritalStatus	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient	Patient
	Woonsituatie	LivingSituation	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation	LivingSituation
	DrugsGebruik	DrugUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse	DrugUse
	AlcoholGebruik	AlcoholUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse	AlcoholUse
	TabakGebruik	TobaccoUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse	TobaccoUse
	Voedingsadvies	NutritionAdvice	NutritionOrder	http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice	NutritionAdvice
	Nationaliteit	Nationality	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient	Patient
09	Alert	Alert	Flag	http://nictiz.nl/fhir/StructureDefinition/zib-Alert	Alert
	AllergieIntolerantie	AllergyIntolerance	AllergyIntolerance	http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance	AllergyIntolerance
10	MedicatieGebruik	MedicationUse	MedicationStatement	http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse	MedicationUse
		MedicationAgremeent	MedicationRequest	http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement	MedicationAgreement
11	MedischHulpmiddel	MedicalAid	Device	http://nictiz.nl/fhir/StructureDefinition/zib-MedicalAidProduct	MedicalAid
			DeviceUseStatement	http://nictiz.nl/fhir/StructureDefinition/zib-MedicalAid
12	Vaccinatie	Vaccination	Immunization	http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination	Vaccination
			ImmunizationRecommendation	http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation
13	Bloeddruk	BloodPressure	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure	BloodPressure
	LichaamsGewicht	BodyWeight	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight	BodyWeight
	LichaamsLengte	BodyHeight	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight	BodyHeight
14	LaboratoriumUitslag	LaboratoryTestResult	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation	LaboratoryTestResult
			Specimen	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen
15	Verrichting	Procedure	Procedure	http://nictiz.nl/fhir/StructureDefinition/zib-Procedure	Procedure
16	Contact	Contact	Encounter	http://nictiz.nl/fhir/StructureDefinition/zib-Contact	Contact
17	GeplandeZorgActiviteit	PlannedCareActivity	ProcedureRequest	http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest	PlannedCareActivity
			MedicationRequest	http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement
			ImmunizationRecommendation	http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation
			DeviceRequest	http://nictiz.nl/fhir/StructureDefinition/zib-MedicalAidRequest
			Appointment	http://nictiz.nl/fhir/StructureDefinition/zib-Appointment
18	Zorgverlener	HealthProfessional	Practitioner	http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner	HealthProfessional
			PractitionerRole	http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
	Zorgaanbieder	HealthcareProvider	Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization	HealthcareProvider

Terminology, NamingSystems, Mappings

Terminology

Relevant value sets can be found in the package.

NamingSystems

Relevant NamingSystems can be found in the package.

Mappings

Relevant ZIB to FHIR value set mappings can be found in the package. All profiles include ZIB mappings. ZIB concepts are mapped in the corresponding FHIR elements using the ZIB' concept id. The top of the StructureDefinition contains meta information regarding the ZIB mapping, such as the name and uri of the ZIB. In the StructureDefinition elements the corresponding ZIB ID is given including the mapping meta information id. This is illustrated in the following example.

<StructureDefinition>
    <id value="nl-core-patient" />
    .....
    <mapping>
        <identity value="zib-patient" />
        <uri value="https://zibs.nl/wiki/Patient(NL)" />
        <name value="Zorginformatiebouwsteen Patient" />
    </mapping>
    .....
        <element id="Patient.name">
            <path value="Patient.name" />
            <short value="NameInformation" />
            <alias value="Naamgegevens" />
            <type>
                <code value="HumanName" />
                <profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
            </type>
            <mapping>
                <identity value="zib-patient" />
                <map value="NL-CM:0.1.6" />
            </mapping>
         </element>
     .....
</StructureDefinition>