Integrated Reporting Applications
1.0.0 - Trial-Implementation
This page is part of the Integrated Reporting Applications (v1.0.0: Publication) based on FHIR v5.0.0. This is the current published version. For a full list of available versions, see the Directory of published versions
This transaction is used to add, change or remove contents in a report context.
Table 2:4.150.2-1: Actor Roles
Role | Description | Actor(s) |
---|---|---|
Sender | Adds, changes or removes report contents | Content Creator |
Manager | Updates the report context | Hub |
FHIRcast: Content Sharing
FHIRcast: DiagnosticReport update Event
FHIR R5: DiagnosticReport resource
Figure 2:4.150.4-1: Interaction Diagram
The Sender sends an event to the Manager to add, change or remove content relevant to an existing 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.
The Sender determines new content should be added, existing content should be changed, or existing content should be removed from a report context.
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 update Event.
The event
.context.versionId
shall be the newest version ID of the report context known to the Sender.
The Sender should include referenced resources (with applicable content changes) as inline contained resources if possible. However, in some situations, it is beneficial to include other resources by reference instead of by value. In this case, the Sender shall specify the entry.fullurl
with the uri value that the full content can be retrieved.
Note: Using contained resources is preferred as most resources in the event are transient. Also other Subscribers that receive the events may or may not have permission to access referenced resources that are not inline.
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 Section 2:4.150.4.2.2 for error conditions.
Per FHIRcast,
context.versionId
in the request does not match the version ID of the report
anchor context, then the Manager will not apply any updates.report
anchor context.The Manager finishes processing the Update Report Content 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:
timestamp
, id
or event
are not setevent.context
does not include report
and updates
event
.hub.topic
is not a known sessioncontext.versionId
does not match the latest version ID of the report
anchor contextupdates
context key includes an entry to delete the patient
context or update the patient ID in the resource identifier
updates
context key includes an entry to delete the study
context or update the study instance UID or accession number in the resource identifier
Note: If the report context is opened with incorrect patient and/or study, the Subscriber should close the report context and open a new report context with the correct patient and/or study context, rather than using a DiagnosticReport-update event to correct the context.
If the Manager rejected the Update Report Content request, then the Manager shall return a 4xx or 5xx HTTP error response code.
The 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 update report content and configure appropriately.
This transaction is not associated with an ATNA Trigger Event.