Constraints on PS-CA Use Case Actors: Option 2 - FHIR Health Information Exchange (HIE) Pattern Using CA:FeX
The section below captures some of the design constraints on use case actors when developing functionality to support the services mapped to those Use Case Actors.
Note: The scope of this section is limited to the constraints that are applicable to actors and transactions defined in CA:FeX Interoperability Specifications.
While global implementations are actively testing various ways to exchange patient summaries and other documents (See Pan-Canadian FHIR Exchange (CA:FeX) Interoperability Specifications: Preface), more sophisticated exchange patterns may not be as accessible for implementers in the current state. As such, PS-CA has identified the patterns in CA:FeX that early implementers are most likely to start with.
This implementation is currently constrained to only support FHIR-assembled documents in the form of a Bundle of resources of type "document" that has a Composition resource as the first resource in the bundle, followed by a series of other resources, referenced from the Composition resource, that provide supporting evidence for the document.
The two key services supported by CA:FeX are:
- CA:FeX-1: Save PS-CA to Document Repository
- CA:FeX-2A: Retrieve PS-CA from Document Repository
The following section provides key design constraints for implementation of these two required services using the CA:FeX Interoperability Specifications and FHIR standards.
Save PS-CA to Document Repository
PS-CA Producer attempts to save a PS-CA in the Document Repository. The PS-CA Producer implements the Data Source actor from the CA:FeX Interoperability Specifications by using the Save PS-CA to Document Repository service. Similarly, the Document Repository implements the Data Recipient actor from the CA:FeX Interoperability Specifications.
These actors shall use the transaction Submit Data [CA:FeX-1] of CA:FeX that executes a Submit Data Request from a Data Source to a Data Recipient.
Note: Global, pan-Canadian, and jurisdictional practices for document lifecycle management of patient summaries are still in development. For this reason, the management, verification, replacement and deprecation of documents, are out of scope of the guidance included in this release but have been included in the roadmap for future releases. This does not preclude or prevent early implementers from defining their document management practices and beginning to exercise them in their own specifications.
Submit Data [CA:FeX-1]
This message involves a request by a Data Source to transfer a PS-CA FHIR Document Bundle to a Data Recipient. The request is received by a Data Recipient which stores the received PS-CA document bundle and returns an HTTP response code.
Trigger Events
This method is invoked when the Data Source needs to submit a FHIR Document Bundle to a Data Recipient (Document 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 Bundle Resource (with type of document). The content type of the HTTP body shall be either application/fhir+json or application/fhir+xml.
Expected Actions
The Data Recipient shall accept both content 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. For additional information on HTTP response codes, refer to Response Handling in the CA:FeX Specifications v0.1, section Exchanging Documents in FHIR.
Retrieve PS-CA from Document Repository
The PS-CA Consumer and Document Repository (Central) Use Case Actors are required to implement the Retrieve PS-CA from Document Repository service.
These actors shall use the following transactions to find document metadata and retrieval of identified Patient Summary document:
- Search Data [CA:FeX-2A]
- Retrieve Data [CA:FeX-3]
Search Data [CA:FeX-2A]
This message involves a query request by Data Consumer for PS-CA FHIR Document Bundle matching the search criteria included in the request. The request is received by Data Recipient which returns a searchset Bundle containing the document(s) 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 the Data Consumer needs to discover PS-CA FHIR Document Bundles in the Document Repository matching various parameters.
Message Semantics
The Data Consumer executes a FHIR 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]/Bundle?composition
POST [base]/Bundle/_search{?&_format=[mime-type]}
Query Search Parameters
Search Document Bundle operation shall include the following search parameters:
| Query Search Parameters | Description | Usage Note |
|---|---|---|
| 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. | Applied directly on Bundle, does not require chaining. |
| type (bundle.composition.type) | This parameter, of type token, specifies the kind of composition (LOINC if possible). The use of composition.type follows the FHIR Chaining Parameters search methodology. | Will be fixed to 60591-5 for patient summary. |
| status (bundle.composition.status) | This parameter, of type token, specifies the status of the composition. The use of bundle.composition.status follows the FHIR Chaining Parameters search methodology. | Helpful in differentiating compositions that are final vs other statuses. See IPS Note on Composition.status. |
patient.identifier ( bundle.composition.patient.identifier) | This parameter, of type token, specifies an identifier associated with the patient to which the FHIR bundle is assigned. This use of patient.identifier follows the FHIR Chaining Parameters search methodology. | Should include system and value to prevent improper retrieval of patient summaries. |
Example Search Queries
Search by Type of Patient Summary
Note: This is the base that is recommended for all searches for patient summaries to build on. This type is shared by IPS and national implementations of the Patient Summary and therefore will return any patient summaries for the subject of care.
GET [base]/Bundle?composition.type=60591-5
Search by Type + Patient Identifier
GET [base]/Bundle?composition.type=60595-1&composition.patient.identifier=[system]|[value]
Search by Type + Date with qualifier
GET [base]/Bundle?composition.type=60591-5&date=gt2021-01-01
Search by Type + Staus
GET [base]/Bundle?composition.type=60591-5&status=final
Expected Actions
The Data Responder shall process the query and return a search result Bundle matching the search criteria included in the request. The FHIR standard provides encodings for responses as either JSON (application/fhir+json) or XML (application/fhir+xml). For additional information on HTTP response codes, refer to Response Handling in the CA:FeX Specifications v0.1, section Exchanging Documents in FHIR.
Security Considerations
This transaction should not return information that the Data Consumer is not authorized to access. Where authorization here is inclusive of system, app, user, and purpose, according to local policy, patient consents, and security layering. However, the transaction may return search result bundles 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. Also most of the significant resources should be included in the document, so it wouldn't be possible to strip out sensitive content, and thus the whole document should be treated as sensitive.
Retrieve Data [CA:FeX-3]
This transaction involves a request by the Data Consumer for retrieving the identified PS-CA FHIR Document Bundle from a FHIR Repository. The desired Document Bundle is identified by the target server's record ID for that PS-CA FHIR Document Bundle. The request is received by the Data Responder which returns the requested PS-CA FHIR Document Bundle and returns an HTTP response code.
This message uses the HTTP GET request to retrieve the identified PS-CA FHIR Bundle from the central FHIR repository.
Trigger Events
This method is invoked when the Data Consumer needs to retrieve a FHIR Document Bundle.
Message Semantics
The Data Consumer sends an HTTP GET request to the server based on a known resource ID from the Data Responder. The Read operation will return a document Bundle resource containing the Patient Summary Composition and linked resources.
GET [base]/Bundle/[id]
Expected Actions
The Data Responder shall process the query and respond with PS-CA FHIR Bundle matching the specified ID 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. For additional information on HTTP response codes, refer to Response Handling in the CA:FeX Specifications v0.1, section Exchanging Documents in FHIR.
Security Considerations
This transaction should not return information that the Data Consumer is not authorized to access.