IHE support for PCAST Use Cases

Today John Halamka posted Use Cases for Health Information Exchange discussed by the PCAST Workgroup.  There were four use cases:

1. Push by patient of data between two points
2. Simple Search for Data
3. Complex Search for Data
4. Deidentified Aggregated Data Mining

These are all presently supported by existing IHE Profiles, many of which have already been deployed in Health Information Exchanges in the US and around the world.

Push by patient of data between two points

This is the use case for which XPHR was designed.  As a UEL, XPHR uses CDA, which captures medications, problems, allergies, labs and references to other studies (e.g., imaging).  The metadata includes patient identity, provenance (author, source of submission, and privacy metadata).  The assumption made by IHE PCC was that an XDS registry could act as a non-tethered PHR, be able to receive pushes from their providers EHRs.  It could also support input using IHE's XDR profile, or using XDM via The Direct protocol.

These profiles include requirements to support ATNA, which requires user authentication, certificates on both sides of the communication, audit logging by all entities engaged in communication.

The IHE BPPC profile supports capture of patient consent, and supplies metadata about consent.

With regard to the Infrastructure John suggests is needed for this approach:

• The XDS, XDR and XDM profiles include metadata on patient identity, provenance and privacy.
• Categories of health data are already captured in the metadata as specified in the vocabularies selected in the  HITSP C80 Clinical Document and Message Terminology Component, in section 2.2.3.15 Document Metadata, and in the LOINC codes for document sections using in the HITSP C83 CDA Content Modules.
• Providers of Applications capable of wrapping content packages of clinical data in the CDA format can be found here. 
• Providers of Applications capable of receiving the CDA format and "unwrapping" the content can be found here. 
• Certificate management can be through X.509 certificates supported by a number of different providers.
• And I agree, that policies are needed, but that's outside of the IHE scope.

Simple Search

For this use case, the IHE BPPC Profile can be used to capture the patient consent. Queries can be created using the IHE XDS Stored Query or XCA profiles to locate information for a patient from numerous sources specified in URIs as web service endpoints.  These are the very same query/response exchanges already supported in the NwHIN.  As before, XDS Stored Query and XCA require ATNA which supports authentication, audit and encryption of the exchange.

Again, on Infrastructure suggested:

• Policy is needed, but is outside of IHE's scope.  The profiles are built to support wide variation in policy.
• Syntax and semantics for XDS queries have been well established.
• Applications capable of performing the queries are listed here.  Some of the current deployments can be seen here.  This is already available in NwHIN implementations, and through the CONNECT Open Source. 
• An approach to identity patients using the IHE XCPD profile has already been specified (pdf) by the NwHIN Spec Factory.  That profile supports disambiguation of patient identity.

Complex Search

Complex search is different from the perspective of the PCAST use cases, but technically implemented using the same capabilities.  What differs are policies.

• IHE XUA can be used to communicate provider identity and role in the query transaction.
• The "DEAS" is an XDS Registry and eMPI supporting XCPD, or an XCA and XCPD Gateway
• Syntax and semantics for this are already specified. 

De-identified Aggregated Data Mining
This one is the "weakest" of the use cases given that John doesn't talk about the challenges of deintification.  In fact the use case he gives provides data that is probably as accurate as a fingerprint for identifying a person ... a radiological image.

• Policy is again out of scope, but please note that IHE profiles are always designed to support a wide variation in policy due to their International nature.
• IHE is developing a handbook (doc) on this topic this year.
• The IHE MPQ profile release last year is one of the infrastructure components that can be used to support this capability.  

As John notes in his post, Policy is required for all of these use cases.  I'd love to see a workgroup focused on the policy issues irrespective of any standards or technology.