vpk:V3.1 FHIR eOverdracht Proeftuin: verschil tussen versies
(Regroup the information about the overdrachtsbericht) |
(Restructured and expanded the IG for the eOverdracht pilot) |
||
Regel 2: | Regel 2: | ||
=Introduction= | =Introduction= | ||
+ | |||
This page details the HL7 FHIR requirements for exchanging the data in the Verpleegkundige eOverdracht Proeftuin pilot described in [[vpk:V3.1 eOverdracht Proeftuin|this functional design]]. | This page details the HL7 FHIR requirements for exchanging the data in the Verpleegkundige eOverdracht Proeftuin pilot described in [[vpk:V3.1 eOverdracht Proeftuin|this functional design]]. | ||
− | + | Implementation of these transactions is spread over multiple phases. Phase one consists of the implementation of four HCIMs for both the Aanmeldbericht and the Overdrachtsbericht. 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. | |
− | = | + | =Aanmeldbericht= |
− | The | + | ==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 [[vpk:V3.1_Opbouw_eOverdracht_aanmelding|Opbouw eOverdracht aanmelding]]. | ||
+ | |||
+ | ==Structure of the Aanmeldbericht== | ||
+ | |||
+ | The Aanmeldbericht consists of multiple FHIR resources, which are assembled into a FHIR Bundle. The table below lists the FHIR StructureDefinitions that are applicable for the pilot implementation of the 'Aanmeldbericht' transactions. | ||
{| class="wikitable" style="horizontal-align: right" | {| class="wikitable" style="horizontal-align: right" | ||
− | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | | + | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | FHIR profile |
− | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | | + | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | FHIR resource |
− | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | | + | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | HCIM name |
− | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width: | + | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | HCIM version |
+ | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | Remarks | ||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/eOverdrachtAanmeldbericht-phase-one eOverdrachtAanmeldbericht-phase-one] | ||
+ | | Composition | ||
| - | | - | ||
| - | | - | ||
− | | | + | | Only applicable to the Send Aanmeldbericht transaction |
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-patient nl-core-patient] | ||
+ | | Patient | ||
| Patient | | Patient | ||
| v3.1(2017NL) | | v3.1(2017NL) | ||
− | | | + | | - |
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Payer zib-Payer] | ||
+ | | Coverage | ||
| Betaler | | Betaler | ||
| v3.1(2017NL) | | v3.1(2017NL) | ||
− | | | + | | - |
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-organization nl-core-organization] | ||
+ | | Organization | ||
| Zorgaanbieder | | Zorgaanbieder | ||
| v3.1.1(2017NL) | | v3.1.1(2017NL) | ||
− | | | + | | - |
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner nl-core-practitioner] | ||
+ | | Practitioner | ||
| rowspan="2" |Zorgverlener | | rowspan="2" |Zorgverlener | ||
| rowspan="2" |v3.2(2017NL) | | rowspan="2" |v3.2(2017NL) | ||
− | |||
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole nl-core-practitionerrole] | ||
| PractitionerRole | | PractitionerRole | ||
− | | | + | |- |
+ | | - | ||
+ | | Binary | ||
+ | | - | ||
+ | | - | ||
+ | | Can be used to send unstructured PDF data. | ||
+ | |} | ||
+ | |||
+ | ==Use case: Send Aanmeldbericht (PUSH)== | ||
+ | ===Actors and transactions=== | ||
+ | |||
+ | {| class="wikitable" style="horizontal-align: right" | ||
+ | ! Actor | ||
+ | ! Role | ||
+ | ! Transaction | ||
+ | |- | ||
+ | | Healthcare professional | ||
+ | | Initiates sending of aanmeldbericht from the sending XIS to the receiving XIS | ||
+ | | | ||
+ | |- | ||
+ | | Sending XIS | ||
+ | | Sends signup message to the receiving XIS | ||
+ | | Send Aanmeldbericht | ||
+ | |- | ||
+ | | Receiving XIS | ||
+ | | Sends acknowledgement message to sending XIS | ||
+ | | Aanmeldbericht response | ||
|- | |- | ||
|} | |} | ||
− | === | + | ===Transaction: Send Aanmeldbericht=== |
+ | ====Trigger events==== | ||
+ | This transaction is invoked when the XIS needs to send the Aanmeldbericht to the receiving XIS. | ||
+ | |||
+ | ====Message Semantics==== | ||
+ | The Aanmeldbericht is sent as a [https://www.hl7.org/fhir/STU3/documents.html FHIR Document]. To create this document, a FHIR Composition resource should be created according to the profile listed in table XXX. This Composition resource references each of the relevant resources. The Composition resource and the relevant resources are subsequently assembed into a FHIR Bundle resource which ''Bundle.type'' set to ''document''. The Composition resource should be the first entry in the Bundle. | ||
+ | |||
+ | For the Bundle, the following rules apply: | ||
+ | * The Bundle resource SHALL include all the resources listed in table XXX, each in a ''separate Bundle.entry''. | ||
+ | * The resources in the message SHALL be a valid instances of these profiles listed in table XXX. | ||
+ | * All resources SHALL include their related profile canonical URL in the ''meta.profile'' element in order to show compliance. | ||
+ | * The Bundle (MAY/SHOULD??) include the resources that are linked from the included resources | ||
+ | |||
+ | {{NoteBox|A FHIR Document is an immutable statement which can't be updated once it's created, it can only be superseded by a new Document. Updating falls outside the scope of the current design.}} | ||
+ | |||
+ | The Send Aanmeldbericht transaction is an HTTP POST method on the target XIS's base: | ||
+ | POST [base] {?_format=[mime-type]} | ||
+ | where the body of the POST request is the assembled Bundle. | ||
+ | |||
+ | ====Expected actions==== | ||
+ | The document Bundle should be processed as a [http://hl7.org/fhir/STU3/http.html#transaction transaction] by the receiving XIS and each ''Bundle.entry'' should be treated as a ''create'' interaction for the ''Bundle.entry.resource''. When the resource syntax or data is incorrect or invalid and cannot be used to create a new resource, or when the server rejects the content of the resource because of business rules, it should perform a rollback of the creation of any previous entries. | ||
+ | |||
+ | ===Transaction: Aanmeldbericht response=== | ||
+ | ====Trigger events==== | ||
+ | The target XIS completed processing of the Send Aanmeldbericht transaction. | ||
+ | |||
+ | ====Message semantics==== | ||
+ | The target XIS responds to the Send Aanmeldbericht transaction with an HTTP Response, where: | ||
+ | * The status code SHALL be set appropriate to the processing outcome. 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. | ||
+ | * On success, the response body SHALL be set to a FHIR Bundle resource containing one entry for each entry in the request, in the same order, with the outcome of processing the entry. | ||
+ | * On failure, the response body SHOULD be set to a FHIR OperationOutcome resource with detailed error messages describing the reason for the error, and perform a rollback of the creation of any previous entries. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ==Examples== | ||
* [https://simplifier.net/nictizstu3-zib2017/eOverdracht-Aanmeldbericht-phase-one-example Aanmeldbericht Composition] | * [https://simplifier.net/nictizstu3-zib2017/eOverdracht-Aanmeldbericht-phase-one-example Aanmeldbericht Composition] | ||
− | * [https://simplifier.net/nictizstu3-zib2017/eOverdracht-Aanmeldbericht-phase-one-Bundle-example Aanmeldbericht | + | * [https://simplifier.net/nictizstu3-zib2017/eOverdracht-Aanmeldbericht-phase-one-Bundle-example Aanmeldbericht Document] |
− | == | + | =Overdrachtsbericht= |
+ | ==Introduction== | ||
+ | During the pilot, the transfer information is based on a subset of the Overdrachtsbericht Volwassenen (transfer message for adults). The implementation is split in multiple phases. Phase one consists of the implementation of four HCIMs. The remaining information from eOverdracht may be sent unstructured in a PDF file. | ||
− | + | ==Structure of the Overdrachtbericht phase 1: 4 HCIMs + PDF== | |
− | |||
− | |||
− | |||
During phase 1, the Overdrachtsbericht is based on the same 4 HCIMs as the aanmeldbericht (Patient, Betaler, Zorgaanbieder, Zorgverlener). | During phase 1, the Overdrachtsbericht is based on the same 4 HCIMs as the aanmeldbericht (Patient, Betaler, Zorgaanbieder, Zorgverlener). | ||
{| class="wikitable" style="horizontal-align: right" | {| class="wikitable" style="horizontal-align: right" | ||
− | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | | + | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | FHIR profile |
− | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | | + | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | FHIR resource |
− | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | | + | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | HCIM name |
− | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width: | + | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | HCIM version |
+ | !style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | Remarks | ||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/eOverdracht-OverdrachtsberichtVolwassenen-phase-one eOverdracht-OverdrachtsberichtVolwassenen-phase-one] | ||
+ | | Composition | ||
| - | | - | ||
| - | | - | ||
− | | | + | | Only applicable to the Send Aanmeldbericht transaction |
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-patient nl-core-patient] | ||
+ | | Patient | ||
| Patient | | Patient | ||
| v3.1(2017NL) | | v3.1(2017NL) | ||
− | | | + | | - |
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Payer zib-Payer] | ||
+ | | Coverage | ||
| Betaler | | Betaler | ||
| v3.1(2017NL) | | v3.1(2017NL) | ||
− | | | + | | - |
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-organization nl-core-organization] | ||
+ | | Organization | ||
| Zorgaanbieder | | Zorgaanbieder | ||
| v3.1.1(2017NL) | | v3.1.1(2017NL) | ||
− | | | + | | - |
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner nl-core-practitioner] | ||
+ | | Practitioner | ||
| rowspan="2" |Zorgverlener | | rowspan="2" |Zorgverlener | ||
| rowspan="2" |v3.2(2017NL) | | rowspan="2" |v3.2(2017NL) | ||
− | |||
− | |||
|- | |- | ||
+ | | [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole nl-core-practitionerrole] | ||
| PractitionerRole | | PractitionerRole | ||
− | |||
|- | |- | ||
+ | | - | ||
+ | | Binary | ||
+ | | - | ||
+ | | - | ||
+ | | Can be used to send unstructured PDF data. | ||
|} | |} | ||
− | == | + | ==Structure of the Overdrachtbericht phase 2: 15 HCIMs + PDF== |
TBD. | TBD. | ||
− | == | + | ==Use case: Send Overdrachtsbericht (PUSH)== |
− | ==== | + | ===Actors and transactions=== |
− | |||
− | |||
− | == | + | {| class="wikitable" style="horizontal-align: right" |
+ | ! Actor | ||
+ | ! Role | ||
+ | ! Transaction | ||
+ | |- | ||
+ | | Sending XIS | ||
+ | | Sends transfer message to the receiving XIS | ||
+ | | Send Aanmeldbericht | ||
+ | |- | ||
+ | | Receiving XIS | ||
+ | | Sends acknowledgement message to sending XIS | ||
+ | | Aanmeldbericht response | ||
+ | |- | ||
+ | |} | ||
+ | ===Transaction: Send Aanmeldbericht=== | ||
+ | ====Trigger events==== | ||
TBD. | TBD. | ||
+ | |||
+ | ====Message Semantics==== | ||
+ | The Overdrachtsbericht is sent as a [https://www.hl7.org/fhir/STU3/documents.html FHIR Document]. To create this document, a FHIR Composition resource should be created according to the profile listed in table XXX. This Composition resource references each of the relevant resources. The Composition resource and the relevant resources are subsequently assembed into a FHIR Bundle resource which ''Bundle.type'' set to ''document''. The Composition resource should be the first entry in the Bundle. | ||
+ | |||
+ | For the Bundle, the following rules apply: | ||
+ | * The Bundle resource SHALL include all the resources listed in table XXX, each in a ''separate Bundle.entry''. | ||
+ | * The resources in the message SHALL be a valid instances of these profiles listed in table XXX. | ||
+ | * All resources SHALL include their related profile canonical URL in the ''meta.profile'' element in order to show compliance. | ||
+ | * The Bundle (MAY/SHOULD??) include the resources that are linked from the included resources | ||
+ | |||
+ | {{NoteBox|A FHIR Document is an immutable statement which can't be updated once it's created, it can only be superseded by a new Document. Updating falls outside the scope of the current design.}} | ||
+ | |||
+ | The Send Aanmeldbericht transaction is an HTTP POST method on the target XIS's base: | ||
+ | POST [base] {?_format=[mime-type]} | ||
+ | where the body of the POST request is the assembled Bundle. | ||
+ | |||
+ | ====Expected actions==== | ||
+ | The document Bundle should be processed as a [http://hl7.org/fhir/STU3/http.html#transaction transaction] by the receiving XIS and each ''Bundle.entry'' should be treated as a ''create'' interaction for the ''Bundle.entry.resource''. When the resource syntax or data is incorrect or invalid and cannot be used to create a new resource, or when the server rejects the content of the resource because of business rules, it should perform a rollback of the creation of any previous entries. | ||
+ | |||
+ | ===Transaction: Aanmeldbericht response=== | ||
+ | ====Trigger events==== | ||
+ | The target XIS completed processing of the Send Aanmeldbericht transaction. | ||
+ | |||
+ | ====Message semantics==== | ||
+ | The target XIS responds to the Send Aanmeldbericht transaction with an HTTP Response, where: | ||
+ | * The status code SHALL be set appropriate to the processing outcome. 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. | ||
+ | * On success, the response body SHALL be set to a FHIR Bundle resource containing one entry for each entry in the request, in the same order, with the outcome of processing the entry. | ||
+ | * On failure, the response body SHOULD be set to a FHIR OperationOutcome resource with detailed error messages describing the reason for the error, and perform a rollback of the creation of any previous entries. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ==Examples== | ||
+ | * [https://simplifier.net/nictizstu3-zib2017/eOverdracht-OverdrachtsberichtVolwassenen-phase-one-example-1 Overdrachtsbericht Composition phase 1] | ||
+ | * [https://simplifier.net/nictizstu3-zib2017/eOverdracht-OverdrachtsberichtVolwassenen-phase-one-example-bundle Overdrachtsbericht Bundle phase 1] |
Versie van 27 jun 2019 12:47
{{#customtitle:FHIR Implementation guide Proeftuinen eOverdracht v3.1 (InZicht)}}
Introduction
This page details the HL7 FHIR requirements for exchanging the data in the Verpleegkundige eOverdracht Proeftuin pilot described in this functional design.
Implementation of these transactions is spread over multiple phases. Phase one consists of the implementation of four HCIMs for both the Aanmeldbericht and the Overdrachtsbericht. 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.
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.
Structure of the Aanmeldbericht
The Aanmeldbericht consists of multiple FHIR resources, which are assembled into a FHIR Bundle. The table below lists the FHIR StructureDefinitions that are applicable for the pilot implementation of the 'Aanmeldbericht' transactions.
FHIR profile | FHIR resource | HCIM name | HCIM version | Remarks |
---|---|---|---|---|
eOverdrachtAanmeldbericht-phase-one | Composition | - | - | Only applicable to the Send Aanmeldbericht transaction |
nl-core-patient | Patient | Patient | v3.1(2017NL) | - |
zib-Payer | Coverage | Betaler | v3.1(2017NL) | - |
nl-core-organization | Organization | Zorgaanbieder | v3.1.1(2017NL) | - |
nl-core-practitioner | Practitioner | Zorgverlener | v3.2(2017NL) | |
nl-core-practitionerrole | PractitionerRole | |||
- | Binary | - | - | Can be used to send unstructured PDF data. |
Use case: Send Aanmeldbericht (PUSH)
Actors and transactions
Actor | Role | Transaction |
---|---|---|
Healthcare professional | Initiates sending of aanmeldbericht from the sending XIS to the receiving XIS | |
Sending XIS | Sends signup message to the receiving XIS | Send Aanmeldbericht |
Receiving XIS | Sends acknowledgement message to sending XIS | Aanmeldbericht response |
Transaction: Send Aanmeldbericht
Trigger events
This transaction is invoked when the XIS needs to send the Aanmeldbericht to the receiving XIS.
Message Semantics
The Aanmeldbericht is sent as a FHIR Document. To create this document, a FHIR Composition resource should be created according to the profile listed in table XXX. This Composition resource references each of the relevant resources. The Composition resource and the relevant resources are subsequently assembed into a FHIR Bundle resource which Bundle.type set to document. The Composition resource should be the first entry in the Bundle.
For the Bundle, the following rules apply:
- The Bundle resource SHALL include all the resources listed in table XXX, each in a separate Bundle.entry.
- The resources in the message SHALL be a valid instances of these profiles listed in table XXX.
- All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.
- The Bundle (MAY/SHOULD??) include the resources that are linked from the included resources
A FHIR Document is an immutable statement which can't be updated once it's created, it can only be superseded by a new Document. Updating falls outside the scope of the current design. |
The Send Aanmeldbericht transaction is an HTTP POST method on the target XIS's base:
POST [base] {?_format=[mime-type]}
where the body of the POST request is the assembled Bundle.
Expected actions
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 resource syntax or data is incorrect or invalid and cannot be used to create a new resource, or when the server rejects the content of the resource because of business rules, it should perform a rollback of the creation of any previous entries.
Transaction: Aanmeldbericht response
Trigger events
The target XIS completed processing of the Send Aanmeldbericht transaction.
Message semantics
The target XIS responds to the Send Aanmeldbericht transaction with an HTTP Response, where:
- The status code SHALL be set appropriate to the processing outcome. 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.
- On success, the response body SHALL be set to a FHIR Bundle resource containing one entry for each entry in the request, in the same order, with the outcome of processing the entry.
- On failure, the response body SHOULD be set to a FHIR OperationOutcome resource with detailed error messages describing the reason for the error, and perform a rollback of the creation of any previous entries.
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.
Examples
Overdrachtsbericht
Introduction
During the pilot, the transfer information is based on a subset of the Overdrachtsbericht Volwassenen (transfer message for adults). The implementation is split in multiple phases. Phase one consists of the implementation of four HCIMs. The remaining information from eOverdracht may be sent unstructured in a PDF file.
Structure of the Overdrachtbericht phase 1: 4 HCIMs + PDF
During phase 1, the Overdrachtsbericht is based on the same 4 HCIMs as the aanmeldbericht (Patient, Betaler, Zorgaanbieder, Zorgverlener).
FHIR profile | FHIR resource | HCIM name | HCIM version | Remarks |
---|---|---|---|---|
eOverdracht-OverdrachtsberichtVolwassenen-phase-one | Composition | - | - | Only applicable to the Send Aanmeldbericht transaction |
nl-core-patient | Patient | Patient | v3.1(2017NL) | - |
zib-Payer | Coverage | Betaler | v3.1(2017NL) | - |
nl-core-organization | Organization | Zorgaanbieder | v3.1.1(2017NL) | - |
nl-core-practitioner | Practitioner | Zorgverlener | v3.2(2017NL) | |
nl-core-practitionerrole | PractitionerRole | |||
- | Binary | - | - | Can be used to send unstructured PDF data. |
Structure of the Overdrachtbericht phase 2: 15 HCIMs + PDF
TBD.
Use case: Send Overdrachtsbericht (PUSH)
Actors and transactions
Actor | Role | Transaction |
---|---|---|
Sending XIS | Sends transfer message to the receiving XIS | Send Aanmeldbericht |
Receiving XIS | Sends acknowledgement message to sending XIS | Aanmeldbericht response |
Transaction: Send Aanmeldbericht
Trigger events
TBD.
Message Semantics
The Overdrachtsbericht is sent as a FHIR Document. To create this document, a FHIR Composition resource should be created according to the profile listed in table XXX. This Composition resource references each of the relevant resources. The Composition resource and the relevant resources are subsequently assembed into a FHIR Bundle resource which Bundle.type set to document. The Composition resource should be the first entry in the Bundle.
For the Bundle, the following rules apply:
- The Bundle resource SHALL include all the resources listed in table XXX, each in a separate Bundle.entry.
- The resources in the message SHALL be a valid instances of these profiles listed in table XXX.
- All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.
- The Bundle (MAY/SHOULD??) include the resources that are linked from the included resources
A FHIR Document is an immutable statement which can't be updated once it's created, it can only be superseded by a new Document. Updating falls outside the scope of the current design. |
The Send Aanmeldbericht transaction is an HTTP POST method on the target XIS's base:
POST [base] {?_format=[mime-type]}
where the body of the POST request is the assembled Bundle.
Expected actions
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 resource syntax or data is incorrect or invalid and cannot be used to create a new resource, or when the server rejects the content of the resource because of business rules, it should perform a rollback of the creation of any previous entries.
Transaction: Aanmeldbericht response
Trigger events
The target XIS completed processing of the Send Aanmeldbericht transaction.
Message semantics
The target XIS responds to the Send Aanmeldbericht transaction with an HTTP Response, where:
- The status code SHALL be set appropriate to the processing outcome. 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.
- On success, the response body SHALL be set to a FHIR Bundle resource containing one entry for each entry in the request, in the same order, with the outcome of processing the entry.
- On failure, the response body SHOULD be set to a FHIR OperationOutcome resource with detailed error messages describing the reason for the error, and perform a rollback of the creation of any previous entries.
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.