vpk:V3.1 FHIR eOverdracht: verschil tussen versies
| Regel 182: | Regel 182: | ||
{{NoteBox|List of StructureDefinitions for eOverdracht pilot. This section is not part of the normative content for eOverdracht.}} | {{NoteBox|List of StructureDefinitions for eOverdracht pilot. This section is not part of the normative content for eOverdracht.}} | ||
| − | The table below lists the StructureDefinitions that are applicable for the pilot implementation of the transaction 'Aanmeldbericht'. Implementation of the transaction 'Aanmeldbericht' is spread over multiple phases. Phase one consists of the implementation of four HCIMs. The remaining information from eOverdracht may be sent unstructured in a PDF file, through the addition of a | + | The table below lists the StructureDefinitions that are applicable for the pilot implementation of the transaction 'Aanmeldbericht'. Implementation of the transaction 'Aanmeldbericht' is spread over multiple phases. Phase one consists of the implementation of four HCIMs. The remaining information from eOverdracht may be sent unstructured in a PDF file, through the addition of a Composition.section that references a Binary resource, which shall be placed inside the FHIR document Bundle. The profile on Composition, listed in the table below, provides the details. |
{| class="wikitable" style="horizontal-align: right" | {| class="wikitable" style="horizontal-align: right" | ||
Versie van 8 mei 2019 15:16
{{#customtitle:FHIR Implementation Guide eOverdracht v3.1|FHIR Implementation Guide eOverdracht v3.1}}
Introduction
This page details the HL7 FHIR requirements for exchanging the Verpleegkundige eOverdracht data described in this functional design.
Use case: Send eOverdracht Aanmeldbericht
Introduction
The send eOverdracht Aanmeldbericht transaction is used by the sending XIS to send the relevant data to the receiving XIS. In addition to the functional design, the structure of this transaction is described in Opbouw eOverdracht aanmelding.
Actors
| Transaction group | Transaction | Actor | Role |
|---|---|---|---|
| Send eOverdracht Aanmeldbericht(PUSH) | Send aanmeldbericht request | Healthcare professional (using a XIS) | Sends aanmeldbericht to the receiving XIS |
| Send aanmeldbericht response | Receiving XIS | Sends acknowledgement message to sending XIS |
Invocations
Sending XIS: request message
The send eOverdracht Aanmeldbericht message uses the HTTP POST method on the target XIS's base.
Trigger Events
This message is invoked when the XIS needs to send an eOverdracht Aanmeldbericht to the receiving XIS.
Message Semantics
Because the data needed in the Aanmeldbericht will most likely consist of multiple FHIR resources, a document Bundle is used. This allows for bundling and sending a set of resources in a single interaction.
The interaction is performed by an HTTP POST command as shown:
POST [base] {?_format=[mime-type]}
The body of the post submission is a Bundle with Bundle.type = document. The first entry contains a Composition resource, and each subsequent entry contains a resource that is referenced from the Composition resource. By sending it to the target's base, the document Bundle will be processed as a transaction and each Bundle.entry will be treated as a create interaction for the entry.resource.
Read more:
The Composition resource in the Bundle SHALL conform to the eOverdracht Aanmeldbericht profile listed below. The table also lists profiles that represent ZIBs that can be used for the data exchange of the referenced resources.
The resources in the message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.
The Bundle resource SHALL contain all resources that are referenced from the Composition resource, each in a separate Bundle.entry.
Examples
Aanmeldbericht
Bundle
Expected Actions
On receipt of the submission, the receiving XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.
XIS: response message
The target XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.
Trigger Events
The target XIS completed processing of the send eOverdracht Aanmeldbericht message.
Message Semantics
The target XIS SHALL return a Bundle with type set to transaction-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.
A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.
When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error, and perform a rollback of the creation of any previous entries.
Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):
- 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
- 404 Not Found - resource type not supported, or not a FHIR end-point
- 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail
Read more: create transaction
Expected Actions
The sending XIS processes the results according to application-defined rules.
List of StructureDefinitions
The profiles listed in the table below represent their entire respective HCIM and are applicable in a broader context than the exchange of eOverdracht information.
A package is available that conveniently bundles all examples, profiles and other conformance resources you need into a single download. This version of the information standard depends on Nictiz package 1.1.x 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.
The FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.
For even more background information:
- What is the problem that packaging could address
- Introducing the Simplifier FHIR Package Server (includes what problem packaging addresses)
- Firely Torinox introduction (this is one of the tools that's useful for working with FHIR packages)
- The HL7 wiki that outlines the base specification
|
|
It is not required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages. |
List of StructureDefinitions - eOverdracht pilot
|
|
List of StructureDefinitions for eOverdracht pilot. This section is not part of the normative content for eOverdracht. |
The table below lists the StructureDefinitions that are applicable for the pilot implementation of the transaction 'Aanmeldbericht'. Implementation of the transaction 'Aanmeldbericht' is spread over multiple phases. Phase one consists of the implementation of four HCIMs. The remaining information from eOverdracht may be sent unstructured in a PDF file, through the addition of a Composition.section that references a Binary resource, which shall be placed inside the FHIR document Bundle. The profile on Composition, listed in the table below, provides the details.
| Zib naam | Zib versie | FHIR Resource | FHIR Profile |
|---|---|---|---|
| - | - | Composition | http://nictiz.nl/fhir/StructureDefinition/eOverdrachtAanmeldbericht-phase-one |
| Patient | v3.1(2017NL) | Patient | http://fhir.nl/fhir/StructureDefinition/nl-core-patient |
| Betaler | v3.1(2017NL) | Coverage | http://nictiz.nl/fhir/StructureDefinition/zib-Payer |
| Zorgaanbieder | v3.1.1(2017NL) | Organization | http://fhir.nl/fhir/StructureDefinition/nl-core-organization |
| Zorgverlener | v3.2(2017NL) | Practitioner | http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner |
| PractitionerRole | http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole |
Examples - eOverdracht pilot
Aanmeldbericht
Bundle
Interactions, operations, search parameters
Interactions
The following logical interactions are needed for the send eOverdracht Aanmeldbericht transaction:
Operations
No operations are defined or needed for this transaction.
Search parameters
No search parameters are defined or needed for this transaction.