Integrated Reporting Applications
0.1.1 - ci-build
Integrated Reporting Applications, published by IHE Radiology Technical Committee. This is not an authorized publication; it is the continuous build for version 0.1.1). This version is based on the current content of https://github.com/IHE/RAD.RTC-IMR/ and changes regularly. See the Directory of published versions
This transaction is used to open a report context. Report contexts are opened within an existing reporting session.
Table 2:3.X3.2-1: Actor Roles
Role | Description | Actor(s) |
---|---|---|
Sender | Opens a report context | Image Display Report Creator Worklist Client |
Manager | Manages opened context | Hub |
FHIRcast: Request Context Change
FHIRcast: DiagnosticReport open Event
Figure 2:3.X3.4-1: Interaction Diagram
The Sender sends an event to the Manager to open a report context. The Sender shall support sending such messages to more than one Manager.
The Manager shall support handling such messages from more than one Sender.
A Sender uses this transaction when:
This message is a FHIRcast Request Context Change request. The Sender is the FHIRcast Subscriber. The Manager is the FHIRcast Hub.
The event.context
shall conform to DiagnosticReport open Event.
Additional, the contexts in the event.context
shall conform to the Table 2:3.X3.4.1.2-1:
Table 2:3.X3.4.1.2-1: Context Requirements
Key | Optionality | Context Requirements
— | — | –
report
| REQUIRED | Conform to the DiagnosticReportContext resource
patient
| REQUIRED | Conform to the PatientContext resource
study
| REQUIRED* | Conform to the ImagingStudyContext resource
Note: Rows with ‘*’ in the Optionality column have constraints different from baseline FHIRcast Request Context Change request.
If the Sender resumes a previously opened report, then the Sender shall reuse the previous report
, patient
and study
contexts, but shall assign a new event.id
.
If the Sender is retrying this context change request due to not receiving a response from the Manager for a prior request, then the Sender shall use the same event.id
. If the Manager received the original request, this allows it to detect that it is a duplicate message.
If the Sender retries the request due to an error response from the Manager, then the Sender shall assign a new event.id
to indicate that it is a new request.
The Manager shall receive and validate the request. See 2:3.X3.4.2.2 for error conditions.
Per FHIRcast, this report
context will become the current context in this reporting session.
If the report
, patient
and study
contexts in the request match an existing report context which has not been closed, then the Manager shall update that report context and set it to be the current context.
The Manager finishes processing the Open Report Context request.
This message is a FHIRcast Request Context Change response. The Sender is the FHIRcast Subscriber. The Manager is the FHIRcast Hub.
The Manager shall return 400
Bad Request error if:
timestamp
, id
or event
are not setevent.context
does not include report
, patient
and study
event
.hub.topic
is not a known sessionreport
context in the request matches an existing report context, but either patient
or study
context do not matchThe Manager may return other applicable HTTP error status codes.
If the response is an error, then the Sender may consider retrying the request.
See IRA Security Considerations
Local policy should consider what users and systems have permissions to open a report context and configure appropriately.
This transaction is not associated with an ATNA Trigger Event.