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
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 require more workflow and it is conceivable that the FHIR Task resource will be used to fulfill that. At this point in time, the ServiceRequest and Composition resources are sufficient for the use cases described in this IG. In a later stage, more (mostly zib based) resource profiles will be added for the transfer of the medical record.
2.2 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.
2.3 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. 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.
2.3.1 Handling free 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.
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 Introduction
|
|
The RESTful interactions for this use case have not been determined yet. The following is an initial proposal that can be used for testing purposes. |
Because sending a referral consists of a ServiceRequest and Composition resource along with supporting resources, a transaction interaction interaction can be used. This allows for creating a set of resources in a single interaction and makes it possible to include referenced secondary resources if needed.
A transaction interaction is performed by an HTTP POST command as shown:
POST [base]
The body of the POST submission is a Bundle with Bundle.type=transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the transaction of what to do for the entry. (Note: Bundle.request is optional in FHIR, but SHALL be present, even for the resources which aren't ServiceRequests or Compositions. See FHIR:V1.0_FHIR_IG_R4#Including_.22secondary.22_resources_when_sending_information for more information.)
The resources included in the bundle SHALL conform to the profiles listed in the table below.
3.1.2 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.3 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. |
| Profile name | FHIR Resource | Canonical URL |
|---|---|---|
| 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.
