FHIR Implementation Guide ELZ 0.2.0-beta.1
|
|
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). This 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.
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 information standard 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 information standard.
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 the Composition resource in the context of this information standard 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
$documentoperation 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 usingGETinteractions.
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_paramedic and specifically just the referral and not the transfer of relevant medical record entries. As development moves on, more use cases will be added. |
3.1 Use case: Referral from general practitioner to paramedic
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 | Description | Name | Description |
| General practitioner | The user of a HIS | HIS | General practitioner information system | n/a | n/a |
| Paramedic | The user of a PARIS | PARIS | Paramedic information system | n/a | n/a |
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:
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. |
5 Release notes
Release notes can be found on the functional design page.
