The PCAST Use Cases

As I posted yesterday, the PCAST Workgroup has discussed use cases which correspond to three levels of healthcare information exchange supported by a Universal Exchange Language (UEL) and Data Element Access Service (DEAS) - "push by patient of data between two points", "simple search for data", and "complex search for data".  They are intended to support PHR and EHR health information exchanges for a multitude of uses, include clinical care, population health and clinical research.  A 4th Use Case incorporates de-identified data.



Use Case 1 - Push by patient between two points.



The patient logs into a tethered PHR via username/password or other authentication mechanism provided by the clinical organization hosting the data.   The patient chooses to push the data to the non-tethered PHR of their choice.   Many possible architectures and approaches can support this including download from the tethered PHR with upload to the un-tethered PHR, a push directly from the tethered PHR to the un-tethered PHR (as Google Health and Microsoft Health support today), or the use of secure email from the tethered PHR to the un-tethered PHR using the Direct standards via a secure health email address.  In each case, the data sent wrapped in a UEL envelope containing patient identity, provenance, and privacy metadata information.     UEL Metadata might also include non-disclosing information about the categories health data available in the content package i.e. medication list, problem list, allergy list, labs, radiology images etc.



When the UEL arrives at the non-tethered EHR, data is shown to the patient, who can elect to incorporate structured and unstructured data into their existing un-tethered PHR dataset.   Then, the patient can then choose to share PHR data with clinicians, clinical researchers, or public health by pushing selective PHR data wrapped in an UEL envelope via secure transmission (such as Direct) to recipients of their choice.    Organizational certificates are needed for the senders (un-tethered PHR hosting organization) and the recipients (clinician offices, clinical research organizations, public health organizations).    Audit trails are held by senders, recipients and any Health Information Service Providers used as part of Direct transport.   Patient authentication is username/password as required by the PHRs.  Provider authentication is username/password or other modality as required by the EHR.



Summarizing the infrastructure for this approach, we will need
:

*A UEL that includes patient identity, provenance, privacy metadata, and categories of health data available in the content package.   There will need to be semantic standards for this metadata including the content/vocabulary of identity, providence, privacy metadata, and categories of health data

*Applications which are capable of wrapping content packages of clinical data in the UEL

*Applications which are capable of receiving the UEL and unwrapping content packages


*Certificate management to secure the endpoints and support privacy controls


*Policies that support push of data between two points.   

Use Case 2 - Simple Search



A patient presents to an Emergency Department and notes their records are stored at a specific clinician office and a specific hospital.    An Emergency Physician obtains patient consent to retrieve their records.    A query is created that includes patient identity, consent information, and provider authentication data.    A Data Element Access Service which serves as an entity level provider directory is securely queried to determine the Uniform Resource Identifiers (URIs) of the clinician office and hospital.   The query is sent to the URIs, which return a UEL wrapper containing identity information, provenance, patient privacy metadata based on any consents on file at the organizations hosting patient records, and non-disclosing information about the categories health data available in the content package.    The content package inside the UEL includes numerous appropriate vocabularies.   The receiving clinician can choose to incorporate structured and unstructured data into the Emergency Department record.    All exchanges are query/response.  Organizational certificates are needed for the Emergency Department,  the clinician office and the hospital.   Audit trails are held by all these organizations.   Provider authentication is username/password or other modality as required by the ED information system or national policy.



Summarizing the infrastructure for this approach, in addition to the infrastructure of Use Case 1, we will need:


*Policy for issuing queries to organizations hosting patient records


*A DEAS that includes entity level provider directory information to provide the URIs of provider data sources


*The syntax and semantics of a query for clinical data including identity information that is sent to provider organizations hosting patient information


*Applications which are capable of issuing a query to known URIs


*An approach to disambiguate identity conflicts if the query results in multiple patient matches



Use Case 3 - Complex Search

A patient presents to an Emergency Department and is non-responsive.  However, her wallet contains an ID with name and date of birth.   An Emergency Physician, based on policy which grants implied consent for unconscious patients, clicks the external search icon in their EHR.  The EHR creates a query containing patient identity, implied consent information, and provider authentication and role, then sends it to a Data Element Access Service.   The DEAS returns a list of Uniform Resource Identifiers of the organizations which hold the patient's records.   The Emergency Physician’s EHR sends a query containing patient identity, consent information, provider authentication and role to each of the URIs, with a request for problems, medications or allergies.  Each organization returns as many UEL wrapped data packages as match the query and pass the conditions of patient privacy metadata based on any consents they have on file.  Each UEL wrapped package includes identity, provenance and privacy metadata and non-disclosing information about the categories health data available in the content package.   The content package inside the UELs includes numerous appropriate vocabularies.   The receiving EHR filters and organizes the information for the clinician who can choose to incorporate structured and unstructured data into the local Emergency Department record.    All exchanges are query/response.  Organizational certificates are needed for the Emergency Department, the DEAS provider, and the organizations which contain patient records.  Audit trails are held by all these organizations.   Provider authentication is username/password or other modality as required by the ED information system or national policy.



Summarizing the infrastructure for this approach, in addition to the infrastructure of Use Case 2, we will need:


*Policy for issuing a query to the DEAS

*A DEAS which contains patient identity information, provider URIs and potentially more granular information about the types of data available at those URIs


*The syntax and semantics of a query including identity information that is sent to the DEAS.   
*Applications which are capable of querying a DEAS and then querying URIs of provider data sources specified by the DEAS, assembling the data returned into a meaningful display
*Support for privacy metadata that are returned by the DEAS and provider data sources

Interoperation among Use Cases 1-3

The Use Cases and the Levels of Exchange are not mutually exclusive.  If all three are supported, the patient in Use Case 1 can use the simple search of Use Case 2 to query for the URI of a provider they would like to push their information to; and the complex search of Use Case 3 to expose a UEL wrapped subset of their PHR to the DEAS tagged with a privacy tag indicating their desire that it be made available to someone giving them care and a provenance tag indicating that she had edited it.

Use Case 4 - De-identified aggregate data mining



A researcher wants to retrieve de-identified mammograms to investigate a new technology that provides computer assisted interpretation.    The researcher issues a query to the DEAS requesting de-identified mammograms that are reusable for research based on patient consent.    A list of URIs is returned including pointers to mammograms.   The researcher queries the URIs and receives de-identified mammograms.

Summarizing the infrastructure for this approach
*Policy for issuing a research queries to the DEAS
*A DEAS which supports de-identified queries for a specific type of data
*The syntax and semantics of a query including data type information that is sent to the DEAS.   
*Provider data sources that are capable of returning de-identified data
*An application that can query a DEAS and query provider data sources
*Support for privacy metadata that include consent to release data for research and ensure de-identification

The combination of these use cases and the security model described in yesterday's post provides a clear path forward that enables pilots and research to be done in parallel with the meaningful use activities already in progress.

As I think about the exciting years ahead - a PCAST inspired expansion of health information exchange, meaningful use stage 2 & 3, and healthcare reform, I am concerned that doing ICD-10 in the middle of all these other activities will overwhelm healthcare systems and IT organizations.   My thoughts on rebalancing and aligning all of the projects in front of us will be a blog post for next week.