Use Case
To frame this work, we developed personas and use cases to help identify areas of readiness and areas of need to support exchange of laboratory data between EHRs and registries. This process helped identify common data elements (and their associated value sets) to support the use cases. It also helped identify the necessary operations and functions needed to support the exchange, and helped inform development of our design principles.
Personas
We drafted personas that aligned with typical scenarios for exchange of laboratory data from a practice to a cancer registry. We selected to focus on a perosna for a practice that had an existing relationship and data exchange with a registry service.
Our primary Breast Cancer Persona focuses on the expected behavior for the partners involved (an academic medical center and a cancer registry) and the core laboratory data elements expected to be transmitted for this demonstration project.
We also developed a persona to reflect a desired future state where bulk data can be moved between entities.
Use Case
Our central, illustrative use case focused on laboratory data transfer for breast cancer screening and therapy selection.
We assume that the functionality of bulk data export is not yet available. Thus, the technical services are designed to approximate a bulk exchange, but rely on functions available in our pilot context. In our Breast Cancer Persona, we refer to these as "(psuedo) bulk FHIR".
Actors
Our primary use case has two principal system actors:
Requestor
An application that initiates a data access request to retrieve patient data. This can be thought of as the client in a client-server interaction. In our case, the requestor application acts on behalf of the registry.
Responder
A product that responds to the data access request to provide patient data. This can be thought of as the server in a client-server interaction. In our case, the responder system has access to the health data stored by the practice or health system.
Users
The Requestor is designed to operate as a backend service, and the Responder is intended to be a server capable of automatically responding to client requests. Thus, in our context, users are limited to the staff who configure and deploy the applications and ensure that data exchange is happening in the expected manner.
Roles
EHR Implementer
Support configuration of the EHR Responder application, ensure that necessary data is made available through the corresponding FHIR resources, searches, and operations.
Registry Implementer
Develops and supports the backend services application that serves as the Requestor, configures and manages the secure communication, and manages the backend repository and/or data processing pipeline.
Assumptions
Technical Compliance
- EHR is able to record and exchange health data using standardized medical terminologies specified in this IG (for example LOINC, SNOMED-CT, UCUM).
- EHR is able to authenticate and integrate with a SMART on FHIR app for laboratory data transfer
- EHR can make laboratory data available using FHIR-based specifications
- EHR and registry are capable of syncronizing and maintaining data updates over time
- Registry has a revision history and curation process
- Users can identify what revisions were made, who made them, and why
Data Sharing Practices
Our personas and use case assume (and this IG) assume that health information is shared in compliance with privacy, security, and consent requirements as outlined in the agreements between the patient, the health system, and the registry and any other applicable regulations.
Bulk Laboratory Service Features
- Backend services authentication provides the necessary access and authorization in order to read necessary data.
- Typically, registries query for (or are pushed) regular updates for all eligible patients. Given that bulk data export is not currently supported, the
Requestormanages a queue of patients for whom updated data is available and makes iterative calls for laboratory data for patients in that queue.