A system conforming to the CA:FeX Interoperability Specifications shall claim conformance at the level of a Use Case Actor (first columns of Table 1 and Table 2 of section Core Interoperability Specification Requirements). A system may claim conformance to one or more Use Case Actors among:
- Producer
- Consumer
- Clinical Data Repository (Local or Central)
- Central Infrastructure
Producer and Consumer use case actor roles will primarily be taken up by EMR clinical solution vendors. Clinical Data Repository and Central Infrastructure 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 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 v1 Trial Implementation, 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 Actors and Transactions). The two key services supported by CA:FeX are:
- Save Document to Clinical Data Repository
- Retrieve Document 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 two services, the following three RESTful transactions have been defined:
| Service Supported | FHIR RESTful Transactions |
|---|---|
Save Document to Clinical Data Repository | 1. Submit Data [CA:FeX-1] |
Retrieve Document from Clinical Data Repository | 2. Search Data [CA:FeX-2] |
| 3. Retrieve Data [CA:FeX-3] |
Save Document to Clinical Data Repository
The Producer and Clinical Data Repository Use Case Actors are required to implement the Save Document 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 document to a Data Recipient. The request is received by a Data Recipient which stores the received FHIR documents and returns an HTTP response code.
Trigger Events
This method is invoked when the Data Source needs to submit one or more FHIR documents 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 document(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 under Exchanging Documents in FHIR.
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 Response Handling section under Exchanging Documents in FHIR.
Retrieve Document from Clinical Data Repository
The Consumer and Clinical Data Repository (Central) Use Case Actors are required to implement the Retrieve Document from Clinical Data Repository service.
These actors shall use the following transactions to find metadata and retrieval of identified clinical document:
- 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 documents using parameterized queries. The request is received by a Data Recipient 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 Bundle Resources or retrieval of documents that are anticipated to be a mix of FHIR-assembled (Composition) and FHIR-enabled (Binary) documents.
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
The following search parameters are used generically to support document retrieval.
Additional search parameters that are specific to the requirements for a specific use case or IGuide (e.g., PS-CA) may be further defined by those implementations.
Query Search Parameters | Applied to | Description |
|---|---|---|
| composition | bundle.composition | This parameter, of type reference, specifies the first resource in the bundle, if the bundle type is "document" - this is a composition, and this parameter provides access to search its contents using chaining. See FHIR Chaining Parameters search methodology. |
| timestamp | bundle.timestamp | This parameter, of type date, specifies the timestamp when the FHIR bundle was created. See FHIR http://hl7.org/fhir/R4/search.html#date for use of the date search type. |
patient.identifier | bundle.composition.patient.identifier documentReference.patient.identifier | This parameter, of type token, specifies an identifier associated with the patient to which the document is assigned. This use of patient.identifier follows the FHIR Chaining Parameters search methodology. |
| type | bundle.composition.type documentReference.type | This parameter, of type token, specifies the kind of document (LOINC if possible). The use of bundle.composition.type follows the FHIR Chaining Parameters search methodology, whereas type can be applied directly in documentReference searches. |
| author | bundle.composition.author documentReference.author | This parameter, of type reference, specifies who and/or what authored the document. The use of bundle.composition.author follows the FHIR Chaining Parameters search methodology, whereas author can be applied directly in documentReference searches. |
| date | bundle.composition.date documentReference.date | This parameter, of type date, specifies when this document reference was created. The use of bundle.composition.date follows the FHIR Chaining Parameters search methodology, whereas date can be applied directly in documentReference searches. |
Additional information on this FHIR implementation pattern including Document Search Pattern options is provided in the Search for a Document section under Exchanging Documents in FHIR.
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 under Exchanging Documents in FHIR.
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. Where 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 known documents using the document's resource id from a Clinical Data Repository. The request is received by a Data Responder which returns the requested FHIR document(s) or returns an HTTP response code.
This message uses the HTTP GET request to retrieve the identified FHIR document(s) from the central Clinical Data Repository.
Trigger Events
This method is invoked when the Data Consumer needs to retrieve FHIR document(s).
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 or an embedded attachment in DocumentReference or a Binary resource.
GET [base]/[resourcetype]?name=value&...
Additional information on this FHIR implementation pattern including Document Search Pattern options is provided in the Retrieve a Document section under Exchanging Documents in FHIR.
Expected Actions
The Data Responder shall process the GET request and respond with FHIR Document (s) matching the specified identifier included in the request. When the requested document is returned, the Data Responder shall respond with an HTTP Status Code 200. The HTTP message-body shall be the content of the requested document.
Additional information on handling responses is provided in the Response Handling section under Exchanging Documents in FHIR.
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.