Send ClinicalReportResearch
Purpose and relevance
This page describes the electronic and structured exchange of a ClinicalReportResearch (CRR) from a healthcare organization to a consumer. The functional design is defined infrastructure-agnostic and independent of any technical implementation.
As described in the scope & usage section, the CRR standardizes a common information need and provides an information architecture that can be technically implemented in the various applications used in the Belgian healthcare landscape.
Information
This CRR is made up of a prioritized set of CBBs. The selection of CBBs is based on their prevalence of use in electronic health record (EHR) systems and existing data collection definitions (DCDs). The CRR template only has the Patient CBB as a mandatory element. All other CBBs within this CRR are optional and have no set upper limit on how often they are used, in order to facilitate reuse as much as possible. DCD's that make use of the CRR can express their selection of required (mandatory) information.
LaboratoryTestResults are not included in the CRR, as these results should be sent as LaboratoryTestResult messages (see the LaboratoryTestResult Implementation Guide). Although not directly shown in the model below, the CBBs referenced from the main CBB, such as PharmaceuticalProduct, referenced from MedicationAgreement, are included in the CRR as well.
ClinicalReportResearch
A CRR is sent per patient in a structured manner using CBBs, as shown in the below-rendered model of a CRR. BackboneElements represent sections that organize and give context to the CBBs, ensuring readability and structure.
Actors
The following actors are defined:
| Actor | System | Definition |
|---|---|---|
| ClinicalReportResearch Provider | EHR | A system maintaining a CRR over time, such as an EHR (electronic health record). |
| ClinicalReportResearch Consumer | HD4DP | A system acquiring a CRR, such as the HD4DP (healthdata.be for data providers) application. |
Process
This section explains the process for sending a CRR message from the ClinicalReportResearch Provider to the ClinicalReportResearch Consumer. It consists of four parts: preconditions, triggers, process steps, and postconditions.
Precondition
- The Provider has treated the patient and information is recorded in the EHR.
- The Provider and Consumer have agreed on when and which information needs to be exchanged.
- The Provider is authorized to send the requested patient data to the Consumer.
- The Provider is able to make a secure connection with the Consumer.
Trigger events
- No specific trigger events for sending a CRR message here.
- Agreements made by the Provider and Consumer can involve triggers.
Process steps
- The Provider sends a CRR message, per patient, to the Consumer.
- The Consumer receives the CRR message and processes it.
- The Consumer responds indicating it successfully received the message or detailing why it cannot process the message.
- In case of a failed CRR message, the Provider may try again (with an updated message) or use another method not described here to provide the information to the consumer.
Postcondition
- The Consumer has received the CRR message.
Response message
The receiving system sends a confirmation response message. When a CRR message cannot be processed due to errors or business logic, the response message contains the details of the error. Technical specifications will elaborate on the appropriate response and error messages.
Transactions
| Transaction group | Transaction | System | Role |
|---|---|---|---|
| ClinicalReportResearch (PUSH) | Send CRR message | EHR | Provider |
| Receive CRR message | HD4DP | Consumer |
Sequence diagram
