vpk:V3.1 FHIR eOverdracht: verschil tussen versies
(HOTFIX: Simplifier template usage) |
(HOTFIX: Simplifier template usage) |
||
| Regel 1.803: | Regel 1.803: | ||
=FHIR CapabilityStatements= | =FHIR CapabilityStatements= | ||
| − | * {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities-phase-one|CapabilityStatement server}} | + | * {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities-phase-one|title=CapabilityStatement server}} |
| − | * {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities-phase-one|CapabilityStatement | + | * {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities-phase-one|title=CapabilityStatement client}} |
=Footnotes= | =Footnotes= | ||
<references /> | <references /> | ||
Versie van 21 okt 2020 15:08
|
|
Work in progress - See official publication here. |
Introduction
This page details the HL7 FHIR requirements for exchanging the data in the eOverdracht described in the functional design.
Implementation of these transactions is spread over multiple phases. In the first phase of the Proeftuin a simplified version of both the Aanmeldbericht en Overdrachtsbericht are being used. Both messages exist of four HCIMs listed in the table below. The Aanmeldbericht is send to the recieving organisation, which after confirmation of recieving the aanmeldberricht, gets send the Overdrachtbericht. Phase two consists of the complete Aanmeldbericht as well as an incomplete Overdrachtsbericht. The Overdrachtsbericht is a subset of 11 HCIM's (complete set used in Aanmeldbericht) and an unstructured PDF containing the remaining data which are not part of the HCIM's. Phase three is the complete dataset of the Aanmeldbericht, Overdrachtsbericht Volwassenen, Overdrachtsbericht Kinderen 0-1 jaar, Overdrachtsbericht Kinderen 1-18 jaar as PUSH messages.
This implementation guide assumes that the reader is familiar with FHIR(STU3).
Overarching FHIR principles
- This implementation guide does not provide information on finding the right XIS, nor does it provide information about security. It is assumed that the sending XIS is able to make a connection with the receiving XIS.
- All FHIR resources used within eOverdracht SHALL conform to the profiles listed in this implementation guide and SHALL include the profile canonical URL in their
meta.profileelement.
Package and dependencies
eOverdracht uses the FHIR Packaging mechanism to conveniently bundle all examples, profiles and other conformance resources you need into a single download. The eOverdracht package has a dependency on the Nictiz Zib2017 package .
Example instances
Example instances of the FHIR messages can be found on Simplifier:
Use case 1A: Send Overdrachtsbericht volwassenen (PUSH)
NB: The use cases as publiced here are with reservation. Depending on the outcome of a discussion about the scenario's with third parties implementing this standard, the use cases might differ. However the cotnent of the uses cases will remain the same as stated below.
Introduction
The Send Overdrachtsbericht scenario is used by the sending XIS to send the relevant data for the patient care to the receiving XIS. The structure of the eventual scenario is described in the functional design and additionally in Opbouw Overdrachtsbericht Volwassenen.
Actors
| Transaction group | Transaction | Actor | Role |
|---|---|---|---|
| Send Overdrachtbericht (PUSH) | Send Overdrachtsbericht | Healthcare professional at organization A (using a XIS) | Sends Overdrachtsbericht |
| Healthcare professional at organization B (using a XIS) | Receives Overdrachtsbericht |
Invocation
The Send Overdrachtsbericht transaction is an HTTP POST method on the target XIS's base, where the body of the POST request is a FHIR document according to #Structure of the Overdrachtsbericht (complete). See #Sending documents for more information.
Trigger events
This transaction is invoked when the sending XIS needs to send the Overdrachtsbericht to the receiving XIS.
Expected response
The document Bundle should be processed as a transaction by the receiving XIS. See #Processing documents for more information.
Structure of the Overdrachtsbericht (complete)
The Overdrachtsbericht consists of multiple FHIR resources, which are assembled into a FHIR document. See #Creating documents for information on how to assemble this document.
The table below lists the FHIR profiles[1] that are applicable for the pilot implementation of the Overdrachtsbericht transaction.
Use Case 2A: Send overdrachtsbericht kindzorg
NB: The use cases as publiced here are with reservation. Depending on the outcome of a discussion about the scenario's with third parties implementing this standard, the use cases might differ. However the cotnent of the uses cases will remain the same as stated below.
Introduction
The Send Overdrachtsbericht scenario is used by the sending XIS to send the relevant data for the patient care to the receiving XIS. For the use case "kindzorg" we distinquish between two age categories:
- Child between 0-1 years of age (zie ook inhoudelijke opbouw van de verpleegkundige overdracht voor kinderen tussen 0-1 jaar)
- Child between 1-18 years of age (zie ook inhoudelijke opbouw van de verpleegkundige overdracht voor kinderen tussen 1-18 jaar)
Actors
| Transaction group | Transaction | Actor | Role |
|---|---|---|---|
| Send Overdrachtbericht (PUSH) | Send Overdrachtsbericht | Healthcare professional at organization A (using a XIS) | Sends Overdrachtsbericht |
| Healthcare professional at organization B (using a XIS) | Receives Overdrachtsbericht |
Invocation
The Send Overdrachtsbericht transaction is an HTTP POST method on the target XIS's base, where the body of the POST request is a FHIR document according to #Structure of the Overdrachtsbericht (Child 0-1) or #Structure of Overdrachtsbericht (Child 1-18). See #Sending documents for more information.
Trigger events
This transaction is invoked when the sending XIS needs to send the Overdrachtsbericht to the receiving XIS.
Expected response
The document Bundle should be processed as a transaction by the receiving XIS. See #Processing documents for more information.
Structure of the Overdrachtsbericht (Child 0-1)
The Overdrachtsbericht consists of multiple FHIR resources, which are assembled into a FHIR document. See #Creating documents for information on how to assemble this document.
The table below lists the FHIR profiles[1] that are applicable for the implementation of the Overdrachtsbericht transaction.
Structure of Overdrachtsbericht (Child 1-18)
The Overdrachtsbericht consists of multiple FHIR resources, which are assembled into a FHIR document. See #Creating documents for information on how to assemble this document.
The table below lists the FHIR profiles[1] that are applicable for the implementation of the Overdrachtsbericht transaction.
Use case 3A: Send Aanmeldbericht (PUSH)
NB: The use cases as publiced here are with reservation. Depending on the outcome of a discussion about the scenario's with third parties implementing this standard, the use cases might differ. However the cotnent of the uses cases will remain the same as stated below.
Introduction
The Send Aanmeldbericht scenario is used by the sending XIS to send the relevant data for the patient intake to the receiving XIS, and constitutes a subset of the Overdrachtsbericht. The structure of the eventual scenario is described in the functional design and additionally in Opbouw Aanmeldbericht. For the pilot a limited subset is implemented.
Actors
| Transaction group | Transaction | Actor | Role |
|---|---|---|---|
| Send Aanmeldbericht(PUSH) | Send Aanmeldbericht | Healthcare professional at organization A (using a XIS) | Sends Aanmeldbericht |
| Healthcare professional at organization B (using a XIS) | Receives Aanmeldbericht |
Invocation
The Send Aanmeldbericht transaction is an HTTP POST method on the target XIS's base, where the body of the POST request is a FHIR document according to #Structure of the Aanmeldbericht. See #Sending documents for more information.
Trigger events
This transaction is invoked when the sending XIS needs to send the Overdrachtsbericht to the receiving XIS.
Expected response
The document Bundle should be processed as a transaction by the receiving XIS. See #Processing documents for more information.
Structure of the Aanmeldbericht
The Aanmeldbericht consists of multiple FHIR resources, which are assembled into a FHIR document. See #Creating documents for information on how to assemble this document.
During phase 1, the Aanmeldbericht is based 4 HCIMs (Patient, Betaler, Contactpersoon en Zorgaanbieder) and uses a PDF to send the remaining data unstructured. The table below lists the FHIR profiles[1] that are applicable for the pilot implementation of the Aanmeldbericht transaction. All resources SHALL conform to the profiles listed in this table and SHALL include the profile canonical URL in the meta.profile element.
| Section | FHIR profile | FHIR resource | HCIM name | HCIM version | Remarks |
|---|---|---|---|---|---|
| - | eOverdracht aanmeldbericht | Composition | - | - | Declaration of the Send Aanmeldbericht transaction. |
| Datum overplaatsing | eOverdracht-TransferDate | - | - | - | DateTime extension used in eOverdracht composition profiles |
| Persoonsgegevens | nl-core-patient | Patient | Patient | v3.1(2017NL) | - |
| zib-Payer | Coverage | Betaler | v3.1(2017NL) | - | |
| nl-core-relatedperson | RelatedPerson | Contactpersoon | v3.1(2017NL) | - | |
| Sturende organisatie | nl-core-organization | Organization | Zorgaanbieder | v3.1.1(2017NL) | - |
| Ontvangende organisatie | nl-core-organization | ||||
| Medische diagnose | zib-Problem | Condition | Probleem | v4.1(2017NL | - |
| Voorgeschiedenis | zib-Problem | Condition | Probleem | v4.1(2017NL | - |
| Let op | zib-Alert | Flag | Alert | v3.2(2017NL) | - |
| Vrijheidsbeperking | zib-FreedomRestrictingMeasures | Procedure | VrijheidsBeperkendeMaatregelen | v3.1(2017NL) | - |
| Actuele patiëntenproblemen | zib-Problem | Condition | Probleem | v4.1(2017NL) | - |
| Afspraken patiënt | zib-ProcedureRequest | ProcedureRequest | OverdrachtGeplandeZorgActiviteit | v3.1(2017NL) | - |
| Wensen en behoeften patiënt en/of naasten | - | - | - | - | Declared as a text section. See eOverdracht aanmeldbericht profile. |
| Voeding/vocht | zib-FeedingTubeSystem | DeviceUseStatement | SondeSysteem | v3.2(2017NL) | - |
| zib-Infusion | DeviceUseStatement | Infuus | v3.2(2017NL) | - | |
| Uitscheiding | zib-Stoma | Observation | Stoma | v3.2(2017NL) | - |
FHIR Documents
Both the Aanmeldbericht and the Overdrachtsbericht are sent as a FHIR Document. A document is a FHIR Bundle that assembles all relevant resources that need to be exchanged, together with a Composition resource that summarizes and references all these resources.
A FHIR document is immutable and considered to be attested by a healthcare professional.
Creating documents
To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.
Profiles have been created for both the Composition and the document Bundle resources for each transaction within eOverdracht. All documents SHOULD adhere to these profiles, which are summarized in this implementation guide at the transaction level.
Sending documents
The document should be sent as an HTTP POST operation on the target XIS's base:
POST [base] {?_format=[mime-type]}
where the body of the POST request is the document.
Processing documents
The document Bundle should be processed as a transaction by the receiving XIS and each Bundle.entry should be treated as a create interaction for the Bundle.entry.resource. When the receiving XIS cannot create a new resource because of incorrect data or business rules, it should perform a rollback of the creation of any previous entries.
On success, the target XIS SHALL respond:
- With the HTTP status code 201 Created.
- With the Location header containing the new logical id and version id of the created resource version.
- With a response body set to a Bundle of type "transaction-response", containing one entry for each entry in the request, in the same order, with the outcome of processing the entry. The sender may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server.
On failure, the target XIS SHALL respond:
- With an HTTP status code set appropriate to the processing outcome:
- When the resource syntax or data is incorrect or invalid, the status code should be 400 Bad Request.
- When the server rejects the content of the resource because of business rules, the status code should be 422 Unprocessable Entity.
- Additional HTTP status code may be used if more appropriate.
- With a response body set to a FHIR OperationOutcome resource with detailed error messages describing the reason for the error.
FHIR CapabilityStatements
Footnotes
- ↑ 1,0 1,1 1,2 1,3 Please note that the direct links to the various conformance resources below will take you to the latest version, which might not match the package version. At time of writing, there is no way to render the conformance resource as found in the package. This is on the roadmap for Simplifier.