hg:Vprepub-1 FHIR ELZ

This FHIR IG is currently under development and can not be considered stable and ready for use. For questions and change requests regarding this IG, please create a ticket in BITS.

1 Introduction

This is the implementation guide for ELZ (Dutch: Eerstelijnszorg, English: Primary care). The functional specification can be found here and is implemented using HL7 FHIR R4. This implementation guide assumes that the reader is familiar with both the functional specification and the FHIR standard.

This IG is inspired by the BSeR IG, developed and published by the HL7 Public Health work group. The goal is to align with this IG where possible and Nictiz is participating in this work group for further development and international alignment of the BSeR IG.

Apart from this document, the guidelines as specified in the general FHIR Implementation Guide apply.

2 Workflow and message structure - referral use cases

2.1 Overview

The use cases described in this IG are limited in sense of workflow: events are handled on a per use case basis where the sender does not explicitly requests a response (e.g. a status update). Future insights might contain more (use case overarching) workflow. To prepare for this workflow mechanism, the Task resource is used as the entry point for all exchanges.

2.2 Task

2.2.1 Task requirements

The requirements for the Task resource in the ELZ context are specified using the http://nictiz.nl/fhir/StructureDefinition/hg-ReferralTask profile. This profile SHALL be used for the ELZ referral use cases.

The Task instance SHALL be hosted on the server of the sending XIS. Both the sending and the receiving XIS need to be able to update the Task. The sending XIS MAY use business rules to reject an update, for example if invalid status change is used.

Both the sending and the receiving XIS SHALL monitor the Task resource for changes. It is expected that the sending XIS will use a notification mechanism to inform the receiving XIS of creation or updates of the Task, but the receiving XIS could use a polling mechanism as well.

2.2.2 Task invocations

The receiving XIS can query the Task at the sending XIS by using the Task.id which is communicated in the notification:

 GET [base]/Task/[Task.id]

Note: It is up to the receiving XIS to determine if this is a new Task or an update to an existing Task, and if it is an update, what the change entails.

The receiving XIS can update a Task hosted by the sending XIS using a PUT operation:

 PUT [base]/Task/[Task.id]

The body should be the original Task with the needed modifications. The sending XIS SHOULD check the update for errors and inconsistencies. If the update is rejected, the sending XIS SHALL response with an HTTP 422 status code and an OperationOutcome detailing the problem.

A notification/transaction mechanism for this IG is currently under a broader (international) discussion and therefore not yet specified, it is however aimed to align with this initiative.

2.3 ServiceRequest

A ServiceRequest resource is used to represent a (request for) referral. The requirements for the ServiceRequest resource in the context of this IG are specified using the http://nictiz.nl/fhir/StructureDefinition/hg-ReferralServiceRequest profile. This profile SHALL be used in referral use cases.

Each referral SHALL be captured by a dedicated ServiceRequest. When a referral is sent to multiple parties, each party receives its own unique ServiceRequest. Revoking referrals after a certain period of time based on whether action is taken or not is out of scope of this IG.

The ServiceRequest is referenced from Task.focus.

2.3.1 ServiceRequest invocations

The receiving XIS MAY use the following mechanism to retrieve the ServiceRequest:

GET [base]/ServiceRequest/[ServiceRequest.id]

2.4 Composition

A Composition resource is used to capture relevant data that supports the referral, for instance the reason for referral or guidance noted down by the general practitioner. This data is either directly included in the Composition as unstructured text or included as referenced resources. The requirements for IG are specified using the http://nictiz.nl/fhir/StructureDefinition/hg-ReferralComposition profile. This profile SHALL be used in referral use cases.

The Composition is referenced from ServiceRequest.supportingInfo.

2.4.1 Composition invocations

The receiving XIS MAY use either of the following mechanisms to retrieve the Composition and individual FHIR resources referenced in the Composition:

As a Document

The receiving XIS uses the $document operation to retrieve both the Composition and all referenced resources as a single document Bundle.

GET [base]/Composition/[Composition.id]/$document

Note: The sending XIS SHALL produce a complete Bundle containing not only the Composition and the resources listed directly in the Composition, but all the indirectly referenced resources as well.

Individual requests

The receiving XIS first retrieves the Composition resource:

GET [base]/Compositon/[Composition.id]

Then the necessary other resources referenced can be fetched using GET interactions.

The sending XIS SHALL support both mechanisms.

2.4.2 Handling unstructured text concepts

Some concepts in the data set are of data type string, as some of the relevant data is entered manually by the referrer in the context of a specific referral. This data is often not represented as a persistent object in EHRs but more likely stored as a form or a questionnaire entry. In order to send this data within the Composition, the extension http://nictiz.nl/fhir/StructureDefinition/ext-TextValue is used on Composition.section, accompanied by a distinctive code on Composition.section.code. The Composition.section.text, which provides a human-readable narrative, is mandatory when the Composition.section does not contain an entry or sub-section. Also see invariant cmp-1.

Example:

<Composition>
...
<section>
    <extension url="http://nictiz.nl/fhir/StructureDefinition/ext-TextValue">
        <valueString value="paracetamol indien nodig"/>
    </extension>
    <title value="Ingestelde behandeling"/>
    <code>
        <coding>
            <system value="http://snomed.info/sct"/>
            <code value="108631000146107"/>
            <display value="behandeling lopende (situatie)"/>
        </coding>
    </code>
    <text>
        <status value="extensions"/>
        <div xmlns="http://www.w3.org/1999/xhtml">Ingestelde behandeling: paracetamol indien nodig</div>
    </text>
</section>
...
</Composition>

3 Use cases

Currently this IG only covers the #Use_case:_Referral_from_general_practitioner_to_allied_health_professional but omits the transfer of relevant medical record entries. As development moves on, this use case will be extended and more use cases will be added.

3.1 Use case: Referral from general practitioner to allied health professional

This is the technical counterpart of hg:Vprepub-1_Ontwerp_ELZ#Usecase:_Huisarts_verwijst_naar_paramedicus as described in the functional design.

3.1.1 Actors involved

Actors		Systems				FHIR CapabilityStatements
Name	Description	Name	Actor	System role	Description	Name	Description
General practitioner	The user of a HIS	HIS	Sending XIS (server)	HZP-VPS	General practitioner information system	http://nictiz.nl/fhir/CapabilityStatement/hg-Referral-GeneralPractitionerToAlliedHealthProfessional	FHIR client/server requirements
Allied health professional	The user of a PARIS	PARIS	Receiving XIS (client)	HZP-VPO	Allied health professional information system

3.1.2 Relations between resources

4 FHIR profiles

ELZ uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This IG uses the following packages: nictiz.fhir.nl.r4.elz version 0.2.0-beta.1 or compatible nictiz.fhir.nl.r4.nl-core version 0.9.0-beta.1 or compatible Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

The FHIR profiles defined for zib publication 2020 are currently in beta status. Although major changes are not to be expected, users should be aware that these profiles might be subject to incompatible changes before a stable version is reached. Therefore, these profiles should not be regarded fit for use for real-world data exchange.

Profile name	FHIR Resource	Canonical URL
hg-ReferralTask	Task	http://nictiz.nl/fhir/StructureDefinition/hg-ReferralTask
hg-ReferralServiceRequest	ServiceRequest	http://nictiz.nl/fhir/StructureDefinition/hg-ReferralServiceRequest
hg-ReferralComposition	Composition	http://nictiz.nl/fhir/StructureDefinition/hg-ReferralComposition
nl-core-Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
nl-core-HealthProfessional-PractitionerRole	PractitionerRole	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
nl-core-HealthProfessional-Practitioner	Practitioner	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
nl-core-HealthcareProvider	Location	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
nl-core-HealthcareProvider-Organization	Organization	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
nl-core-Problem	Condition	http://nictiz.nl/fhir/StructureDefinition/nl-core-Problem

5 Release notes

Release notes can be found on the functional design page.