A system conforming to the CA:FeX Interoperability Specifications shall claim conformance at the level of a Use Case Actor (first columns of the Tables in Core Interoperability Specification Requirements). A system may claim conformance to one or more Use Case Actors among:
- Data Source
- Data Consumer
- Data Recipient
- Data Responder
Data Source and Data Consumer use case actor roles will primarily be taken up by EMR clinical solution vendors. Data Recipient and Data Responder use case actor roles can be taken up either by EMR clinical solution vendors or jurisdictions depending on the implementation approach that the jurisdiction decides to adopt. Similarly, the Data Consumer can be a Patient Portal, in which case the use case actor can be taken up either by a vendor or jurisdiction depending on the approach and policies defined regarding patient / subject of care access to their personal health information (PHI).
In order to implement a system that fully supports the CA:FeX Interoperability Specifications, the system shall be able to demonstrate that it conforms to every required actor and transaction for which it is claiming conformance.
Constraints on Use Case Actors
The section below captures some of the design constraints on use case actors when developing functionality to support the services mapped to them.
Note: The scope of this section is limited to the constraints that are applicable to actors and transactions defined for CA:FeX Interoperability Specifications (See section CA:FeX Actors and Transactions). The key services supported by CA:FeX are:
- Save Document to Clinical Data Repository
- Retrieve Document from Clinical Data Repository
- Save Data to Clinical Data Repository
- Search and Retrieve Data from Clinical Data Repository
- Fetch Document References from Clinical Data Repository
The following section provides key design constraints for implementation of these two required services using RESTful APIs based on CA:FeX and FHIR standards. To support these services, the following three RESTful transactions have been defined:
| Service Supported | FHIR RESTful Transactions |
|---|---|
Save Document to Clinical Data Repository | Submit Data [CA:FeX-1] |
Search and Retrieve Document from Clinical Data Repository | Search Data [CA:FeX-2] |
| Retrieve Data [CA:FeX-3] | |
Save Data to Clinical Data Repository | Submit Data [CA:FeX-1] |
Search and Retrieve Data from Clinical Data Repository | Search Data [CA:FeX-2] |
| Retrieve Data [CA:FeX-3] | |
Fetch Document References from Clinical Data Repository | Search Data [CA:FeX-2] |
| Retrieve Data [CA:FeX-3] |
Save Data or Document to Clinical Data Repository
The Producer and Recipient Use Case Actors are required to implement the Save Document to Clinical Data Repository service or the Save Data to Clinical Data Repository service.
These actors shall use the FHIR transaction Submit Data [CA:FeX-1] of CA:FeX that executes a Submit Data request from a Data Source to a Data Recipient.
Submit Data [CA:FeX-1]
This message involves a request by a Data Source to transfer a FHIR resources (Documents or individual resources) to a Data Recipient. The request is received by a Data Recipient which stores the received FHIR resources and returns an HTTP response code.
Trigger Events
This method is invoked when the Data Source needs to submit one or more FHIR resources to a Data Recipient (Clinical Data Repository).
Message Semantics
This message uses the HTTP POST method on the target Submit Data endpoint to convey the metadata and the FHIR Resource(s) as a FHIR transaction. The Data Source shall initiate a FHIR “transaction” using a “create” action by sending an HTTP POST request method composed of a FHIR Resource. The media type of the HTTP body shall support application/fhir+json and should support application/fhir+xml. Additional information on this FHIR implementation pattern is provided in the Submit a Document section and the Submit Data section section in the CA:FeX FHIR Implementation Guide.
Expected Actions
The Data Recipient shall accept media types application/fhir+json and application/fhir+xml. On receipt of the submission, the Data Recipient shall validate the resources and respond with one of the HTTP response codes and an OperationOutcome, if applicable. Additional information on handling responses is provided in the Response Handling section of the CA:FeX FHIR Implementation Guide.
Retrieve Data or Document from Clinical Data Repository
The Consumer and Responder Use Case Actors are required to implement the Retrieve Document from Clinical Data Repository service or the Retrieve Data from Clinical Data Repository service.
These actors shall use the following transactions to find metadata and retrieval of identified clinical information:
- Search Data [CA:FeX-2]
- Retrieve Data [CA:FeX-3]
Search Data [CA:FeX-2]
This message involves a query request by a Data Consumer to find FHIR Resources using parameterized queries. The request is received by a Data Responder which returns a Bundle containing the matching search parameters.
The Data Consumer may use HTTP GET or HTTP POST based searches. The Data Responder shall support both GET and POST based searches.
Trigger Events
When a Data Consumer needs to discover a list of FHIR Resources that match search parameters.
Message Semantics
The Data Consumer executes an HTTP search request against the Data Responder endpoint (FHIR Repository).
The Data Consumer may use HTTP GET or HTTP POST based searches. The Data Responder shall support both GET and POST based searches.
GET [base]/[resourcetype]?name=value&...
POST [base]/[type]/_search{?[parameters]{&_format=[mime-type]}}
Query Search Parameters
Search parameter requirements can be found in the Search Parameter page and the CapabilityStatement page of the CA:FeX FHIR Implementation Guide.
Expected Actions
The Data Responder shall process the query and return a search result matching the search criteria included in the request. The FHIR standard provides encodings for responses as either XML or JSON.
Additional information on handling responses is provided in the Response Handling section of the CA:FeX FHIR Implementation Guide.
Security Considerations
Data Responder SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code. This transaction should not return information that the Data Consumer is not authorized to access (authorization here is inclusive of system, app, and user according to local policy, patient consents, and security layering). However, the transaction may return search bundle that have Reference elements that the Data Consumer may not have access to. This is to say that the authorization need only be to the content returned in the Bundle. There may be references (URLs) for which the content is not authorized. This is considered proper as the Data Consumer would need to retrieve the content pointed to by those references, and at that time the proper authorization decision would be made on that context and content. In this way it is possible for a Data Consumer to get Resources that are pointing at data that the Data Consumer is not authorized to retrieve. Thus, the URLs used must be carefully crafted so as to not expose sensitive data in the URL value.
Retrieve Data [CA:FeX-3]
This message involves a request by a Data Consumer for retrieving a known FHIR Resource using the resource id from a Clinical Data Repository. The request is received by a Data Responder which returns the requested FHIR Resource or returns an HTTP response code.
This message uses the HTTP GET request to retrieve the identified FHIR Resource from the central Clinical Data Repository.
Trigger Events
This method is invoked when the Data Consumer needs to retrieve a FHIR Resource.
Message Semantics
The Data Consumer sends an HTTP GET request to the server based on a known resource id from the Data Responder. This operation will return a Bundle that was previously identified in a search/or prior retrieval of FHIR Resources.
GET [base]/[resourcetype]?name=value&...
Additional information on this FHIR implementation pattern is provided in the Document Exchange Guidance in the CA:FeX FHIR Implementation Guide.
Expected Actions
The Data Responder shall process the GET request and respond with a FHIR Resource that matches the specified resource id included in the request. When the requested resource is returned, the Data Responder shall respond with an HTTP Status Code 200. The HTTP message-body shall be the content of the requested resource.
Additional information on handling responses is provided in the Response Handling section of the CA:FeX FHIR Implementation Guide.
Security Considerations
Data Responder SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code. This transaction should not return information that the Data Consumer is not authorized to access.
Fetch Document References from Clinical Data Repository
The Consumer and Responder Use Case Actors are required to implement the Fetch Document References service.
These actors shall use the following transactions to find the list of documents and retrieval of identified clinical documents:
- Search Data [CA:FeX-2B]
- Retrieve Data [CA:FeX-3]
Search Data [CA:FeX-2]
This message involves the execution of the FHIR $docRef operation by a Data Consumer to fetch FHIR Resources using Operation-defined criteria (input parameters) to narrows the clinical document references that are created and/or returned. The request is received by a Data Responder which returns a "searchset" Bundle that includes document references that match the provided input parameters.
The Data Consumer may use HTTP GET or HTTP POST based searches. The Data Responder shall support both GET and POST based searches.
Trigger Events
When a Data Consumer needs to discover a list of documents that match search parameters.
Message Semantics
The Data Consumer executes the $docRef operation against the Data Responder endpoint (FHIR Repository).
The Data Consumer uses HTTP GET to execute the operation.
GET [base]/DocumentReference/$docref?patient=[id]
Query Search Parameters
Input parameter requirements can be found in the Operations page of the CA:FeX FHIR Implementation Guide.
Expected Actions
The Data Responder shall execute the operation and return a "searchset" Bundle that includes document references that match the provided input parameters. The FHIR standard provides encodings for responses as either XML or JSON.
Additional information on handling responses is provided in the Response Handling section of the CA:FeX FHIR Implementation Guide.
Security Considerations
Data Responder SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code. This transaction should not return information that the Data Consumer is not authorized to access (authorization here is inclusive of system, app, and user according to local policy, patient consents, and security layering). However, the transaction may return search bundle that have Reference elements that the Data Consumer may not have access to. This is to say that the authorization need only be to the content returned in the Bundle. There may be references (URLs) for which the content is not authorized. This is considered proper as the Data Consumer would need to retrieve the content pointed to by those references, and at that time the proper authorization decision would be made on that context and content. In this way it is possible for a Data Consumer to get Resources that are pointing at data that the Data Consumer is not authorized to retrieve. Thus, the URLs used must be carefully crafted so as to not expose sensitive data in the URL value.