Gartner Blog Network

Guest David McCallie on Simplifying Interop

by Wes Rishel  |  December 1, 2009  |  19 Comments

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.

  1. Provider to provider uses within a covered entity (these are standard internal-to-the-EMR use-cases)
  2. Provider to payer (X12 claims, claims-attachments, etc.)
  3. Provider to external providers, for currently consented care (fax today, “secure structured messaging” in the future)
  4. Provider to external entities and business associates for currently consented care (e.g., labs, imaging, DUR vendors, etc.)
  5. 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”)

  1. Provider to quality reporting services (either via aggregators or direct reporting)
  2. Provider to Public Health (state and federal)
  3. Provider to the federal agencies (FDA, DEA, etc.)
  4. Payer to quality reporting
  5. Payer to the federal agencies

C.      Not yet regulated – awaiting rulings under ARRA for “meaningful use” etc.

  1. Provider to patient (“provide summary of care”, etc.)
  2. Patient to provider (provider portal services as well as direct care management interactions, etc.)
  3. 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)
  4. 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

Category: interoperability  vertical-industries  

Tags: arra  ehr  health-internet  health-it  healthcare-interoperability  healthcare-providers  meaningful-use  nhin  stimulus  

Thoughts on Guest David McCallie on Simplifying Interop

  1. David C. Kibbe, MD MBA says:

    David: I agree in principle with your intelligent outline here, and would be eager to work with you and others to help bring this scenario to fruition in 2010. One question: You write that “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.” Is this a new, physical network, or simply the Internet with the appropriate security and privacy protocols and directory apps in place? If the latter, I think there are several existing networks capable of handling messages in this manner. One is the SureScripts hub and network, another is NaviNet. There may be others. In any case, I hope you’re not suggesting a brand new, multi-billion dollar national network to be built. Among other problems, that would take a long time to develop. Why not use what is already available?
    Kind regards, DCK

  2. David,

    In your breakdown of HIE coverage, how does the EHR support this part of the HITECH act?

    ARRA H. R. 1—154
    In applying section 164.524 of title 45, Code of Federal Regulations, in the case that a covered entity uses or maintains an electronic health record with respect to protected health information of an individual—
    (1) the individual shall have a right to obtain from such covered entity a copy of such information in an electronic format and, if the individual chooses, to direct the covered entity to transmit such copy directly to an entity or person designated by the individual, provided that any such choice is clear, conspicuous, and specific;

    Once the consumer can voluntarily choose their “entity” what is the difference between C1, C2, C3 and C4? Why would we need separate EHR access protocols for the different C cases?


  3. David McCallie says:

    David K,

    Thank you for the question. I certainly don’t mean to imply the creation of a “new” network. I would expect that the “secure messaging” network should leverage existing Internet standards. I am working on a more specific proposal, but to simplify, I would suggest using existing standard mail protocols (SMTP, etc.) over secure channels (TLS.)

    I considered several alternatives: Secure email (S/MIME) is probably too complicated since it requires a massive PKI infrastructure at the end-user level. And using ordinary email with user-encrypted messages doesn’t scale well due to the problems associated with out of band sharing of passwords. So, I would propose using regular email over secure channels. I would oppose any fully-proprietary messaging frameworks. There is so much well-developed functionality in email, it would be a shame to have to reinvent that wheel.

    One way to build the network would be to adopt a hub-and-spoke model where the hubs (EMR vendors, HIE organizations, etc.) would supply secure messaging directly to their end-users (EMR Inbox, etc.) via custom services over HTTPS, and would in turn forward the messages to other hubs using standard SMTP over TLS. All hub-to-hub traffic would be completely standards-based, but hub-to-end-user traffic could optionally be proprietary to allow for deep embedding of secure messaging into the EMR workflow (“inbox” functions.) The hubs would be responsible for credentialing and authenticating their end-users, following a national standard for minimum required security. It might make sense to consider a new ONC-managed “top level domain” (.NHIN ?) to facilitate the process of segregating this secure traffic.


    You make a very good point. The core assumption of the “C” use-cases is predicated on the requirement that the patient has a right to a copy of his or her record. I separated out the specific C1 and C2 use-cases mainly because current proposed “meaningful use” requirements make the assumption that direct provider-to-patient messaging will be required in 2011 whereas full-blown PHR connectivity (via as-yet-unspecified HIE models) won’t occur until 2013 or beyond. I agree that eventually these use-cases collapse into the same model.


  4. Don Simborg says:

    Hurrah to David McCallie for his simplification blog on interoperability. His framework for separation of interoperability transactions not only simplifies and clarifies the issue, but has cleanly separated out a group of transactions (his “C” category) that are confusing and, in my view, interfering with our job #1 which is to get on with interoperability for the transactions in his categories A and B. I would actually move his categories C1 and C2 into A since they can be considered patient portals into a provider EHR and are already covered by consents. It is category C3 which creates all the problems.

    Now we can debate category “C3” where I have strong disagreement with David McCallie regarding its suggested handling – the aggregation of patient data into a PHR or other entity totally under the control of the consumer for use in “not-yet-consented” episodes of care. Consumer empowerment (which I strongly support and advocate) is different from consumer populism which is how I characterize some of the public pronouncements of people and companies proposing such aggregations. There is a difference between empowering consumers and pandering to consumers for the promotion of commercial interests which what some (but certainly not all) of the advocates of untethered PHRs are doing.

    Aggregating patient data outside of provider controlled databases for use in “not-yet-consented” episodes of care is not only unnecessary, but a distraction from and deterrent to achieving useful interoperability for optimum patient care. It is a misguided attempt not only at consumer empowerment, but as an “alternate” pathway to solving provider interoperability. There is no need to aggregate patient data outside of provider organizations for either patient empowerment or improving patient care that is provided by multiple providers – even when those providers have not yet achieved the interoperability through David’s category A. When a patient’s providers have solved the interoperability problems defined in category A, which will now be much easier if we can focus on that without the distraction of dealing with category C3, the patient will be served well. For those providers that have not yet solved category A of interoperability, the solution is already provided in David’s proposal for a “national email-like network for secure point-to-point messaging – one that supports structured (CCD,CDA) as well as unstructured (PDF, text) messages…” The only thing I would add is to make sure we empower the consumer to control when these are to be triggered for those “not-yet-consented” episodes of care and what can be included in those messages.

    This does not eliminate the need for or value of independent, untethered, internet-based and consumer controlled applications which provide wellness and lifestyle advice, patient health and disease education, social networking and patient support groups. Just don’t confuse these applications with patient records or provider interoperability mechanisms.

  5. Wes Rishel says:

    David, to your section C, we may want to consider a fifth variation: shown as #5 below.

    1. Provider to patient (“provide summary of care”, etc.)
    2. Patient to provider (provider portal services as well as direct care management interactions, etc.)
    3. 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)
    4. Provider to new “health 2.0” services as authorized by patient (medication review service, care coordination services, etc.)
    –>5. Health 2.0 to and from “record aggregator services” where the authority comes from the patient.

  6. Charles Parisot says:

    Thank for your posting. Tiering the needs is indeed a great analysis foundation.
    However, I disagree with your analysis of the XDS family of protocols. HITSP has selected it because of its powerful simplification force for the middle layer (above the WS-SOAP transport) and below the content (e.g. CDA/CCD) to support a wide range of use cases such as those you analyze.
    More specifically, with XDR, the national e-mail-like network for secure point-to-point messaging is addressed, but in a way that allows to scale up to the sharing of records, as leveraged by the NHIN with XCA.
    In our analysis we really need to learn for those that are well ahead of the US, such as the most health information connected country in the world, Denmark. After more than 10 years of nation-wide deployed point-to-point, it has found out that it is extremely hard to move beyond because it had not the selected standards designed to extend. We should avoid the same mistake of driving a point-to-point approach without also enabling the sharing where policies support it.

  7. David McCallie says:

    Thank you for both the endorsement and the critique. I agree with your point that C1 and C2 are really special cases of secure messaging, and are covered under HIPAA TPO. I separated them out into “C” mostly because I think connecting providers via a secure point to point email-like network is a different step than connecting providers to consumers (via the same secure messaging network.) Providers all understand the role of the fax. Secure messaging simply replaces that with a secure channel that can contain structured messages instead of just TIF.

    But I disagree, Don, about the value of consumer-aggregated longitudinal record. I personally want to have an automatically-constructed longitudinal record of my care, and if I had it, I would certainly use it to facilitate future care interactions. We may have to “agree to disagree” on this point. One comment though — I do believe that all provider-originated data should be digitally signed and thus be non-repudiable. If a consumer-controlled service presents a provider-authored document as genuine, the system must be able to verify that it is indeed genuine and unaltered.

    I like your suggestion of a C5 use-case. I think there are exciting opportunities for this “new middle” space – where consumers elect to share their aggregated data with new services that can offer alternatives and extensions to traditional treatment models.

    Thank you for your insights, however, I will disagree with your conclusions drawn from the experience in Denmark (and other countries.) The whole point of separating secure messaging from patient data aggregation (XDS) is to give the US a way to move forward by de-coupling the controversial (data aggregation) from the routine (provider to provider messaging.) I too admire Denmark’s top-down healthcare model, but I don’t think it is necessarily very relevant to the way we make decisions here in the US. I also don’t see any specific advantage of XDR for the messaging format when it appears that standard MIME encodings (of CDA, CCD, PDF, etc.) would work just as well, and are readily supported. Running a secure messaging network by using SMTP over mutually-authenticated TLS (as per RFC 2595) seems to me to be the simplest and least complex way to move forward. Also, the raw data content of the messages would be using HITSP-approved content formats, so the same data could be easily pushed to appropriate PHR-services once we settle on how to regulate and control these data aggregation services. “Separation of concerns” may help us move forward.


  8. This discussion is turning into a most inspiring and fruitful contribution to our field. Thanks to David for starting this. In trying to focus on the road forward for interoperability, looking at provider to patient communication (the C category mainly) may be a powerful lever into achieving interoperability. However, I am more triggered by Charles Parisot’s comment on current experience in countries around the world. Not all these experiences stem from a top-down model like Denmark of England. Based on these experiences I’ve tried to structure the provider to external provider category, which helps to identify the applicability of secure messaging and the road forward for more advanced infrastructures like XDS. On I’ve detailed this effort under the borrowed heading of “Interoperability made simple”.

    Basically, my argument is that the focus on standardized re-use sparks much of the debate about privacy, confidentiality and trust among the providers themselves. So, rather than helping them improve healthcare, our solutions seem to create barriers to change. By detailing different use cases for provider to provider communication we might be able to select appropriate technologies without losing sight of the road ahead.

  9. Glenn Keet says:

    Great post and replies. Thanks all.

    I have to agree with Don regarding the PHRs and disagree with David. You do not need your own PHR database with your longitudinal record in order to facilitate care. HIEs and the NHIN will take care of this problem long before there is suffiicent widespread adoption of PHRs to make it practical. Ultimately I agree that a model where the data follows the patient is potentially a superior schema, but we are a long way from that becoming practically feasible.

    As an aside, Axolotl coined and trademarked a term called Clinical Messaging more than a decade ago to describe the secure, email-like push movement of data from source to recipient, where the source or recipient could be a hospital, lab, radiology center, ambulatory care practice, etc. We envisioned in 1995 that this would replace fax, and in our operating HIEs it largely has. I believe way too many people think of HIE as a query-only model. We have long believed in the “push” model, with the pull (query) mode necessary only for certain use cases (ER user, consulting physicians with no prior relationship to the patient, data access from external medical trading area, etc.) I bring this all up in support of the notion of attacking the low-hanging fruit of HIE. The electronic push model requires no new patient consent beyond that already in place for paper processes, yet when broadly implemented in a medical trading area can alone handle 99% of all necessary HIE transactions.

  10. Shane Taylor says:


    This is an excellent thread. Thank you for all the thoughts coming down as this is very insightful. I have re-read the relevant posts that sparked this topic and I wanted to point to a comment in an earlier thread (that no one commented on as of yet) in case those reading this thread missed it (as some of my colleagues have) and since there are no comments (as of yet), others may have missed it as well. This comment seems to have stuck in my head above many others and, for me, has more merit the longer I think about it.

    Before that, some quick thoughts…

    From the above post and comments, I think the hub-and-spoke analogy is spot on, I think the email analogy is a good analogy on the surface (and should look this simple from the surface), but is more complicated under the hood, and I do think that XDS will be involved. I also agree with the PHR / Health Bank being highly involved. Personally, I tend to think the Health Bank is the long term strategy (though many will disagree) but I disagree that the PHR will be that official “Health Bank” any time soon (though many will disagree with disagreement) and “I” would love to have this control as a patient. However, I don’t think either of these opinions are what needs to be focused on right now as they will be debated for some time and I (and others who may think those things) could be completely wrong. I mean, honestly… who actually knows? I think they will play out however they naturally play out. My concern is how the communication for any of this actually gets done – not where the information actually ends up or the protocol that actually (in the end) delivers the goods.

    I don’t want to restate Liam Davis-Mead’s comment in my own words, so I have referenced it below. The simplification of all this messaging is absolutely needed, and I do like the simplified framework posted above by David, but what I want to reference again (via Liam’s comment) is how all this can actually get done – regardless of what technology or main housing of patient information wins. The concept is “Health Internet Service Provider” (HISP) and has the analogy to how the Internet was given momentum and actually moved forward with Internet Service Providers (ISP). All the while, the standards, protocols, repositories, technologies, etc. were being battled over and naturally evolved. But ISPs formed the backbone to the Internet and let all this happen. At first you had to go to the government or an educational facility (like a university) if you wanted on the Internet (analogy to NHIN and current incarnation of what a RHIO is perceived as), then other non-governmental ISPs came along. No longer do you have to go to the government or a university to get on the Internet – but you can if you want to – as they are still Internet Service Providers today. The exchange of health information (regardless of what health information) needs to have a road network (like the Internet) and it doesn’t belong to any one service provider (I just don’t see the government completely controlling this network – only some of it). RHIOs “could” be a HISP but won’t be the only ones. The Connect protocol will be used to transfer information, but it won’t be the only one. Health Banks and PHRs will be places to hold information (whether it is for the patient, provider, or both) but they won’t be the only ones. There needs to be federal, state, and commercial Health Internet Service Providers just like there are federal, state, and commercial Internet Service Providers. This is what gives all the technology debates wings and allows things to actually get done. Then they will evolve. Implementation is the only thing that will actually drive progress. I think Health Information exchange can happen if the approach is fundamentally viewed as how the Internet exchanged information over time. Otherwise, all the debates won’t get the actual implementation occurring to push the exchanging of health information forward.

    Wes Rishel’s original post and Liam Davis Mead’s original comment is located here:

    I apologize for making this total comment so large, but for convenience, I have reposted Liam’s comment here as I absolutely think it has large merit for all those reading this post and warrants more than posting the link only which I would normally do. If someone comments on it, it would be nice to have in this post instead of having to bounce back and forth.


    Liam Davis-Mead // Nov 24, 2009 at 1:20 am

    I like the way Wes and David are making a distinction between “push” and “pull” transactions–I think it’s an extremely useful distinction. In some way the push model is _much_ simpler, and in fact it’s more easily facilitated by current IHE profiles. It’s also no coincidence that it more closely mirrors the current paper process. Sure, you can think of calling the other office and requesting a record as a query, but you’re not going to get any data until they push it to you through that fax machine.

    As far as the trust issue, David is spot on about third party “end-user aggregating organizations”. This is precisely the role fulfilled by those root Certificate Authorities implicitly trusted by your web browser…Verisign, Thawte, etc., except those organizations do not typically provide mutual authentication, which is what’s needed here. He’s also correct that these organizations need to provide directory services. I see these types of organizations as being what Shane described as “Health Internet Service Providers” in his comment to the previous blog post (”Simple Healthcare Interop for Easy Applications”). They would provide these authentication and other services directly to end users — in this case, that means providers.

    I seriously doubt, however, that it will be the EMR vendors fulfilling this role. I suspect that they will continue to do what they do best, which is to provide differentiated software offerings for clinical settings of a wide variety of scales and specialties. I suspect that Shane’s HISPs will operate at more of a least-common-denominator level, and will communicate with other HISPs, as well as client software (the EMRs), via standardized and open protocols (IHE / HITSP profiles, etc). I also suspect that there will be a multitude of these service providers, as Shane initially mentioned, and then Jim followed up with a similar thought.

    I would also suggest that it is precisely these HISPs who should also provide the message handling — routing, reliable delivery, and delivery notification. There need not be a single central exchange or switch, and it need not be proprietary (I would suggest that the IHE profiles have much to offer here). However, the message routing will need to be coordinated at some level, and it seems easiest to place this level at the level of the aforementioned “end-user-aggregating” organizations, and have these gateways act as service providers that take care of all three parts: mutual authentication, directory services, and message handling.

    Now, RHIOs could provide these services, and indeed, their participation in the NHIN as NHIEs would seem to require it, but the existence of RHIOs is not _necessary_ to provide these services. RHIOs (and by extension, the NHIN) are a much more heavyweight solution, hence the current discussion, which basically asks, “Isn’t there an easier way?”

    There is another critical component that I believe HISPs would provide, and that is durable auditing of disclosures. If a physician practice implements an EMR that utilizes local storage, and they have some sort of glitch or crash that wipes out all of their patient records, that’s a big headache for that provider organization, but at least it’s localized to that organization. If that same data loss implies, however, that they are no longer able to furnish a disclosure audit to their patients (because that information was stored in the EMR), then we have a problem.

    Of course, we have the same problem today if all of an office’s paper records burn up in a fire, but I think that’s one of the areas where we want to try to improve over paper.

    To use a (poor) analogy: Microsoft, Cisco, and Level 3 all care about TCP/IP at some level. Microsoft has to code its client software (e.g. Internet Explorer) with some knowledge of it, Cisco has to design devices that can intelligently move it from place to place, and Level 3 has to provide the physical connectivity to pass it between Cisco’s devices. (This is a gross oversimplification, but that’s what you get) This is three separate markets, yet they form an ecosystem, as without any one of them, the other two would be pretty useless. To draw the parallels to the current discussion, I’d say that the EMR vendors play a similar role to Microsoft, Shane’s HISPs play Cisco’s role, and we can simply leverage the existing Internet to take the place of the physical connectivity provided by Level 3’s fiber. A set of core IHE / HITSP profiles would be the “TCP/IP” here.

    I also think that David’s email analogy is fine as far as it goes: from an end-user’s point of view, sending an email _is_ a simple point-to-point, direct connection (and we should strive for a model in which clinicians see precisely this level of complexity). But behind the scenes, that message can be routed between many different SMTP servers, each using mechanisms such as DNS to perform discovery of other servers. There’s all sorts of routing and message handling that happens out there, but it’s thankfully hidden from the consumers of the technology. You could draw a parallel between the work done by these SMTP servers on our behalf and the services provided by HISPs.

    So, I see four key services provided by these HISPs: mutual authentication of the endpoints (not unlike trusted root CAs); directory and discovery services (not unlike DNS); secure message handling and routing (not unlike Cisco and the rest of the decidedly grungy, unsexy plumbing of the Internet that we all take for granted); and auditing. As a stopgap, these service providers could also offer a fifth key service: legacy interfaces, such as interfacing with legacy EMR vendors through mechanisms such as HL7, or operating fax gateways so that paper-based providers can receive records from electronic sources. But in general, these sorts of proprietary interfaces should be frowned upon, and their use limited to “last mile” connections.

    On a last note, the more I think about the term “Health Internet Service Provider” (HISP), the more I seem to like what it implies. It is not as if the government or the healthcare industry is short on acronyms, but thinking of it this way may help others see a different model (similar to ISPs) about how health exchange can occur on a national or even global level.

  11. David McCallie says:

    Before the half-life of this thread goes to zero, I want to add a few comments to the excellent observations of the other posts.

    First, thank you all for what I perceive to be a basic endorsement of the blog’s core proposal –> that developing a national infrastructure for “push” style secure clinical messaging is a reasonable way to immediately move forward on the “national health information / health internet” front.

    Let me respond to some specific points. Shane/Liam — I like the notion of “HISP” — that’s basically what I was getting at with the term “hub” The hub/HISP providers would deliver various “NHIN” services to their end-users, and would be responsible for a variety of the “last mile” problems, such as end-user credentialling an authentication, etc.

    As to the necessary infrastructure to create a secure email-like network, I think we’ll need more than a blog post, but here are the core suggestions:

    1) The core messaging protocol would be SMTP (+MIME, etc) delivered point to point over mutually-authenticated TLS channels. The details on one way to do this are spelled out in RFC3207.

    2) RFC3207 specifically allows for any SMTP server to refuse to talk to any other requesting node which does not meet specific TLS requirements, including the ability to reject conversation with any “unknown” node

    3) One way to guarantee the identity of the secure nodes might be to require that all HISP/HUB nodes to obtain their TLS X509 certificates from a designed CA (perhaps ONC or NIST could play that role?) Each node on the network would only be allowed to talk, via TLS, to other known nodes, as determined by their root Certificate. I believe that this would yield an end-to-end secure message network.

    4) End-user directory services could be HUB-based initially, much the way email directories are today. Over time, a national directory service could emerge, though that’s not critical in the early going, any more than it was for email to be successful.

    Glenn (and Don and others),

    When I used the term “PHR” what I meant was a “personally-controlled health record (PCHR)” — which would be more like a “health record bank” than a “traditional” PHR. And when I suggest that PCHRs (or HRBs) should be at the core of any longitudinal record aggregation, what I mean is that the PCHR would play the role of the XDS “affinity domain” instead of the region’s local “affinity domain.” In this model, the provider’s EMR would connect on a per-patient basis to the necessary affinity domain. For many patients, that would be the local HIE domain, but for those patients who want to take control of their record, they could opt to supply the URL of their chosen PCHR as their affinity domain. What we’d have then is an NHIN that was a “network of PCHRS and HIEs” instead of a “network of just HIEs” — the exact same technology would be in place, but the organization, location, and control of the data would be very different. That’s a too-short summary, but perhaps it clarifies my thoughts.

    Thank you all for the great conversation.

  12. A consensus on a simple Push model for standard health records would be tremendous progress.

    The Internet already deals with “guaranteeing” the identity of secure nodes by using well known Certificate Authorities like Verisign that issue higher grade SSL certs to banks and anyone else willing to go through the process. Does healthcare really need a special CA?

    But if healthcare does need a special CA, how would that CA be different from the NHIN Coordinating Committee (see ) that will be authorizing participants in the NHIN?

    I propose that there will be two kinds of Push messages on the health internet: (a) messages that are directly authorized by the patient can go to anywhere as long as the patient accepts the SSL cert and (b) messages that are implicitly authorized by the patient through a treatment consent and that may be restricted to an NHIN or equivalent cert.


  13. Charles Parisot says:

    What is great in this thread is that there is effective learning form each other comments.

    To David: e-mail push (over SMTP) is precisely supported by IHE-XDM. It supports three media: secured e-mail attachments, USB and CD-R. The e-mail attachment is precisely what you propose. Because it is part of the IHE XD* family of profiles it includes enough metadata to enable recipient, without opening the set of documents transferred, to route into multi-IT system organizations.

    To those who support a point-to-point push, full agreement that this is critical to simplify policy issues. However, one critical pitfall needs to be avoided.
    ==> An envelope needs to wrap the document payload with sufficient health meta-data (what Lim calls the health internet routing) to allow basic exchange workflow (replacing documents sent in error, sets of related documents) and empower any of the Hubs (as suggested by many) to support a pull service without processing the document content. This precisely what XDR adds, that David may have missed. This will allow us to start with a push model, without preventing the pull-model, where the policies are in place.

  14. Liam Davis-Mead says:

    Excellent points, all. I really think this discussion is defining some very helpful concepts for framing how we think about health information exchange.

    As David M. mentions, the “last-mile” connection may well be proprietary, in order to provide a more seamless experience for the provider. The hooks into the EMRs need to take advantage of already supported interfaces, such as HL7 2.x and XDS, rather than requiring the coordination of all the major players to implement _new_ standards, even if those new standards are conceptually as simple as direct messages exchanged via secure SMTP. That’s one of the reasons I see an opening for third parties–these Health Internet Service Providers–to implement some sort of gateway functionality, much as my residential ISP operates an SMTP server for my benefit.

    I also want to thank everyone for giving some legs–and a name, in Shane’s case–to the HISP notion that I’ve been mulling over for some time. I never liked the “Regional” qualification for RHIOs (I can already send a fax or an email across the globe…how’s that for “Regional”?), and “Health Information Exchange” gets treated like a noun far too often, conjuring up images of a huge centralized data broker / warehouse. I much prefer the connotation of a Service Provider, whose sole purpose is to provide services to their clients–the providers and patients. And, just like today’s ISPs, they would have to communicate between each other via open standards, thus increasing the network effect for their clients.

    I also agree with Adrian’s point that we should look at reusing the existing e-commerce PKI for endpoint authentication, as long as we’re talking about gateway-level authentication. If every provider will require their own individual certificate (which could open up new use cases), then perhaps that might better be managed by a national credentialing body, similar to NPI / DEA numbers, etc.

  15. Tom Morrison says:

    This is breakthrough thinking and an important first step in evaluating more broadly how interoperability can be accomplished in health care. We need to stop talking about the miracle of the ATM machine, based on data standards, and start talking about the miracle of 90 million independent web sites that we all know how to locate and use. Architecturally the Web has a simple conceptual framework that we all know: a standard “platform” in the browser with an established “workflow” that we all use called a search engine. With that simple framework, hundreds of millions of people have direct access to 90 million independent web sites and all of this occurs without a common data model. In fact, the data model is relevant only in the context of an individual site.

    Clearly, this Web architecture alone has been an insufficient architectural framework to enable the automation of health care because of its unique requirements. However, extending the Web-like approach of enabling multiple proprietary screens to flow automatically into workflows in provider offices can make a significant contribution to interoperability.

    At NaviNet for example, we have deployed a Web-like model to over 800,000 providers leveraging the common “workflow” of checking for eligibility and benefits. We are delivering hundreds of millions of real-time transactions/business processes using a model that can support but does not require data standards to create interoperability. We have leveraged this basic workflow to deliver clinical alerts and PHR’s – not just as static data but as a real-time capability that allows providers to engage in a process to reply and update inaccuracies in those alerts. The model has been popular with providers and has enabled the delivery of hundreds of unique and proprietary real-time business processes for our sponsors.

    The challenge of creating a single data model for interoperability across our complicated and specialized industry is becoming increasingly evident. This challenge will become even clearer as we advance in personalized medicine and begin to reform our payment processes.

    Go David Go – but let’s not stop at just an email-based vision of the art of the possible.

  16. Basically, YES!!
    Some observations:
    First, you mention the idea of ‘preconsented’ cases. Under HIPAA, sharing information for treatment or billing is even more open than ‘preconsented'; consent is considered given unless specifically denied. Thus no consent at all is needed to send medical information to a treating physician requesting it. This eases the ‘request-pull’ scenario considerably.
    Second, the concept of NHIN as ‘an automatic electronic fax-on-demand’ system exactly meets the needs of the medical community for fast, easy availability of medical history when it’s needed. Outside of securing the actual transmission, and providing a secure directory listing, ALL the security & privacy issues can and should be dealt with outside of NHIN.
    Unfortunately, by stating this , over on the NHIN direct Google group, I’ve stirred up a storm of indignation that “of course” they have to ensure robust trust by designing an elaborate system, instead of relying on HIPAA and fallible medical offices to maintain the sacred security of PHI.
    I don’t have the standing to make them listen to reason- perhaps you, or someone you know, does? Otherwise, we’re going to have anklets to protect against the bites of sharks- and an overly complex, difficult and expensive system that too much trouble to use.

  17. Wes Rishel says:

    Jan, thanks for raising some important points. No proposed approach should be considered that does not address those points.

    I will have to describe the idea further in order to address them.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.