In a chain of posts that includes Simple Healthcare Interop for Easy Applications I am advocating a layered approach to standards that cherry-picks the easy cases and approaches them using Internet standards that are widely used and, if necessary, easily adapted. One of my co-conspirators in this line of thinking is David McCallie, a fellow-member of the HIT Standards Committee. In this guest posting he identifies the easy cases — those for which there is enabling policy and precedent. This is important, because much of the complexity in protocols such as the XDS family comes from the need to solve issues where the privacy policies are complex, variable or unknown.
Setting national policies for HIE (Health Information Exchange) is hard, due in part to the many potential conflicts that arise around control of PHI data (state vs. federal organization, provider vs. patient vs. payer access control, centralized vs. distributed architecture, etc.) To help break through the logjam of HIE policy decisions, I would like to propose that we could analyze and partition various HIE use-cases in terms of the “governing policy” for each HIE use-case. By partitioning HIE into manageable sub domains, we might be able to make more rapid progress towards the vision of a national “health Internet.”
Here is a simplified framework for analysis of HIE data interchange:
A. Regulated under HIPAA “Treatment, payment, or healthcare operations exemptions” (TPO) – as governing episodes of care that are already consented to by the patient.
- Provider to provider uses within a covered entity (these are standard internal-to-the-EMR use-cases)
- Provider to payer (X12 claims, claims-attachments, etc.)
- Provider to external providers, for currently consented care (fax today, “secure structured messaging” in the future)
- Provider to external entities and business associates for currently consented care (e.g., labs, imaging, DUR vendors, etc.)
- Provider to electronic service providers such as eRx, X12 eligibility checks, formulary query, etc
B. Regulated under HIPAA other “permitted uses” (§ 164.512 Uses and disclosures for which an authorization or opportunity to agree or object is not required – which fall outside of “healthcare operations”)
- Provider to quality reporting services (either via aggregators or direct reporting)
- Provider to Public Health (state and federal)
- Provider to the federal agencies (FDA, DEA, etc.)
- Payer to quality reporting
- Payer to the federal agencies
C. Not yet regulated – awaiting rulings under ARRA for “meaningful use” etc.
- Provider to patient (“provide summary of care”, etc.)
- Patient to provider (provider portal services as well as direct care management interactions, etc.)
- Provider to “record aggregator services” (services such as HIE, PHR, or HealthBanks, which accumulate a longitudinal record for a patient, either directly or via record locators)
- Provider to new “health 2.0” services as authorized by patient (medication review service, care coordination services, etc.)
The first two groups (A,B) are covered by existing law and regulations. For most (all?) of the A and B use-cases, there are no major consent or privacy issues, since these are already carefully regulated data flows. For most of the A and B use-cases, there are well-defined technical standards in place, such as HL7 for lab data interchange, X12 for claims and eligibility, and NCPDP for eRx. Regional HIE infrastructure may (or may not) add value in coordinating these specific services, but no new regulatory framework is necessary. And note that none of these data flows require that any data be aggregated outside of the EMR or the data source.
The only glaring architectural and standards gap in the A and B use-cases is a national standard to replace the fax for purposes of pre-consented secure messaging. I believe we need a national email-like network for secure point-to-point messaging – one that supports structured (CCD,CDA) as well as unstructured (PDF, text) messages, along with a secure national directory of verified provider addresses. I believe that such a network could be readily built using existing email and LDAP standards, routed over a secure transport layer (TLS.) Note that in all of these use-cases, the provider has control of the decisions about how the data should flow. The patient is only involved to the degree that they authorize these data interchanges by consenting to treatment.
For C, however, there is a need for HHS (and other agencies) to issue new regulations around these new use-cases. For C1 and C2, secure messaging would work, as soon as consumers can join the secure messaging network. Since the consumer is obviously “in the loop,” consent and privacy issues should be relatively easy to manage. For C3, however, the issues are more complex since by definition the consumer’s data is being aggregated for use in not-yet-consented episodes of care. And since the episodes have not yet occurred, the providers cannot be easily named in advance. This “record locator” function is a major domain of interest for HIE entities. However, I would suggest that for the C3 use-case, the consumer should have control of the data flow decisions, rather than the provider or a regional HIE, since the data is being aggregated for the benefit of the consumer, not for the provider or for the HIE.
I believe that the longitudinal (aggregated) record should “follow the patient” rather than “follow the provider.” Consumers change providers, travel, and move to other parts of the country. There is no value gained by splitting their longitudinal record over multiple regional HIEs. Health Banks / PHRs provide one means to meet the goal of a consumer-controlled longitudinal record. By coordinating the privacy and access control via the consumer’s chosen PHR or Health Bank, we could greatly simplify the build-out of a national network of longitudinal records – the “health internet.” Each patient could select a PHR service and be issued a “health URI” which would identify their record. The consumer then provides this URI to those providers whom they wish to have access their longitudinal record. A national “PHR locator service” (perhaps along the lines of the FHA’s CONNECT software) could be used to locate a consumer’s PHR and to provide access in case of emergency. Thus, for purposes of data aggregation (class C3 above,) a “network of PHRs” would replace a “network of HIEs.”
Numerous photography sharing services (SmugMug, Flickr, Picasa, etc.) offer services like this today that allow full control over our digital photographs – should our personal health records be any less convenient or powerful?
David McCallie Jr, MD | VP Medical Informatics | Cerner Corporation