Vdraft/FHIR GPCare ParamedicalCare: verschil tussen versies
Regel 11: | Regel 11: | ||
Apart from this document, the guidelines as specified in [[FHIR:V1.0_FHIR_IG_R4|general FHIR Implementation Guide]] apply. | Apart from this document, the guidelines as specified in [[FHIR:V1.0_FHIR_IG_R4|general FHIR Implementation Guide]] apply. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=Workflow and message structure= | =Workflow and message structure= |
Versie van 2 nov 2022 19:05
|
This FHIR IG is currently under development and can not be considered stable and ready for use. |
1 Introduction
This is the implementation guide for the information standard GP Care and Paramedical care (Dutch: Huisartsenzorg en Paramedische Zorg). This standard is described in this functional specification and implemented here 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 general FHIR Implementation Guide apply.
2 Workflow and message structure
2.1 Overview
The use cases described in this information standard 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. 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 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 it's 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.2.1 Status
The status of the ServiceRequest SHALL only be updated by the sender/requester as only they can determine whether the order is active or needs revocation.
2.2.2 Actionable tag
To indicate that the ServiceRequest is a resource that has to be acted upon by the receiver, the actionable tag is used. Tags are Coding elements present in Resource.meta.tag
used for workflow management. When a ServiceRequest is created to send a referral, sending systems SHALL use meta.tag
with .system
= http://terminology.hl7.org/CodeSystem/common-tags and .code
= actionable.
It is up to systems to determine how and when the transactions using the actionable tag are handled from a functional perspective. Systems may store the resource including the actionable tag or remove it either upon storing or when the request is acted upon. However, systems SHALL make sure the tag is removed when serving or sending the resource as part of an informative transaction.
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 use case 2.5 "Huisarts verwijst naar paramedicus" as described in the functional design.
3.1.1 Introduction
3.1.2 Sequence diagrams
Normal flow | Cancel referral |
---|---|