IHE PaLM - Radiology Pathology Concordance (RPC)
0.1.0 - ci-build

IHE PaLM - Radiology Pathology Concordance (RPC), published by IHE IT Infrastructure Technical Committee. This is not an authorized publication; it is the continuous build for version 0.1.0). This version is based on the current content of https://github.com/IHE/PaLM.RPC/ and changes regularly. See the Directory of published versions

## 2:90. Send Concordance Report [LAB-90]

This section corresponds to transaction [LAB-90] of the IHE Technical Framework. Transaction [LAB-90] is used by the Content Creator and Content Consumer Actors. The [LAB-90] transaction describes how to send data from a Content Creator to a Content Consumer.

### Scope

The Send Concordance Report [LAB-90] transaction is used to transfer a structured concordance report from a Content Creator to the Content Consumer

### Actors Roles

Table: Actor Roles

Actor | Role
--- | ---
Content Creator | The Content Creator is responsible for the creation of a FHIR MeasureReport containing correlated radiology and pathology data
Content Consumer | The Content Consumer receives the concordance report containing correlated results

### Referenced Standards

FHIR-R4 HL7 FHIR Release 4.0

### Interactions

Figure: Send Concordance Report Interactions

#### Send Concordance Report Message

This transaction transmits RPC-conformant messages containing correlated results from the content creator to the content consumer. The Send Concordance Report is implemented as a FHIR create Transaction defined in the RESTful API implementation guide: https://www.hl7.org/fhir/http.html#create

The format for this transaction is as follows: POST/PUT [base]/MeasureReport

##### Trigger Events

Examples of events which might trigger a Send Concordance Report transaction include, but are not limited to:

- Completion of a radiology and pathology report where results are collected and a concordance report is created immediately
- An overnight batch job where the report is created whenever the function is run

##### Message Semantics

The Content Creator creates an RPC conformant message containing correlated results that meets the requirements of the RPC Measure. The Content Creator SHALL send the message using Send Concordance Report and the Content Consumer SHALL consume the message according to the RPC Measure. The table below describes the request.

| Description
--- | ---
URL | The RPC Profile does not prescribe the form of the URL to be advertised by a Content Consumer except that the scheme of the URL SHALL be “https.”
Headers | The Update request SHALL contain a Content-type header identifying the payload
| Type:Content-type: application/fhir+xml
| Type:Content-type: application/fhir+json
| The request MAY contain any additional headers. For example, a Content Consumer may require an Authorization header.
| A Content Consumer MAY support additional parameters
BODY | The body of a RPC Send Concordance Report request SHALL contain a valid RPC data payload as described in Section 8.2 of this profile.

The report SHALL contain the following elements: subject A required patient or group reference period The start and end of the reporting period group.coding.code A required reference for a valid report stratifier.stratum.value A required value for each report

##### Expected Actions

The Content Consumer SHALL processes the RPC message received and return the status of the transaction as a Send Concordance Report Result as defined in Section 3.Y.4.2.

#### Send Concordance Report Response Message

This transaction is an acknowledgement of RPC POST Content transaction from the Content Consumer to the Content Creator. The Send Concordance Report Response is implemented as an HTTP response. It is expected to be made synchronously.

##### Trigger Events

A Content Consumer sends a Send Concordance Report Response when the Concordance report is received from the Content Creator.

##### Message Semantics

The Send Concordance Report Result is implemented as an HTTP Response. The response may include content in the body to provide an implementation specific informative message on the completed status of the transaction. The response shall contain an HTTP status code. The table below describes the codes which may be produced by the Content Consumer which have a specific meaning related to the transaction.

Note that a Content Creator should be prepared to handle additional status codes not particular to the transaction, such as authorization, server or network error codes. HTTP status codes correspond to FHIR HTTP 3.1.0.4.2 Rejecting Updates (https://www.hl7.org/fhir/http.html#rejecting-updates).

###### Table 3.Y.4.2.2-1: Send Concordance Report Result status codes

HTTP Status Code | Interpretation
--- | ---
200 | Send Concordance Report Request was successfully processed
202 | Send Concordance Report Request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.
303 | The response to the Send Concordance Report when the task is complete can be retrieved from another URL. When received in response to a Send Concordance Report, the client should presume that the server has received the data and should issue a redirect with a separate GET message.
400 | Bad Request - message content is badly formed or invalid
401 | Not authorized - authorization is required for the interaction that was attempted
404 | Not found - resource type is not supported
405 | Method not allowed - the resource did not exist prior to the update, and the server does not allow client defined ids
409/412 | Conflict - invalid identifier in the message content.
415 | Unsupported content-type or media
422 | Unprocessable entity - The MeasureReport does not adhere to RPC Profile on the required fields, etc.
501 | The request method is not implemented.

##### Expected Actions

A Content Consumer SHALL respond with appropriate error codes in the event of receiving an invalid MeasureReport according to the FHIR 3.1.0.4.2 Rejecting Updates. This response should include the appropriate code detailed in Table 3.Y.4.2.2-1 in a FHIR OperationOutcome resource.

### CapabilityStatement Resource

Server implementing this transaction shall provide a CapabilityStatement Resource as described in ITI TF-2x: Appendix Z.3 indicating the transaction has been implemented.

- ​Requirements CapabilityStatement for Content Creator
- ​Requirements CapabilityStatement for Content Consumer

### Security Considerations

See RPC Security Considerations

This profile is assumed to use patient data. The appropriate security precautions are expected to be taken to protect PHI, these should include the precautions outlined in the PaLM Security Environment Considerations in PaLM TF-1: Appendix A.

Transport of RPC data SHOULD be safeguarded according to jurisdictional guidelines. To protect data integrity these SHOULD include encryption of the transport layer and the use of an appropriate mutual authentication mechanism which meets these guidelines.

Content Consumers should also take adequate account of security considerations related to the generic processing of RPC documents.

#### Security Audit Considerations

There is no specific ATNA security audit event that is associated with this transaction.

##### Client Audit

'’TODO: the specifics’’

##### Server Audit

'’TODO: the specifics’’