Gartner Blog Network


Simple Interop: The Health Internet Node

by Wes Rishel  |  December 15, 2009  |  20 Comments

In Simple Interop: How To Go About It I talked about a simple interop model. Today’ post is a proposal for how to exploit the power of the Internet to the max while adding adequate security.

McCallie and I offer it to all those who would listen. The diagram at the end of this post helps to illustrate the ideas.

The goal here is to establish a framework for secure communications among healthcare organizations and between healthcare organizations and patient/consumers. Although we propose some specific uses (protected email and transactions among EHRs) our premise is that the framework will support a much broader set of use cases and Internet technologies.

Enough of the bragging, on to specifics.

A health domain name is a regular Internet domain name, propagated through the regular domain name service. There are only a few things that make it special: (1) it is listed in a special directory of domain names associated with the US Health Internet; and (2) the organization that owns a healthcare domain name will not use it unless it maintains a current valid digital certificate that can be used to authenticate TLS connections. Healthcare organizations will typically have two domain names a regular domain name and a health domain name.

It would be great if a convention were to be adopted so that the healthcare domain names are recognizably related to domain names, such as UShealth.somehospital.org being associated with the hospital that has the domain name somehospital.org. However such a convention is not required. It would be strictly for the convenience of people having to remember their health domain names. Health domain names are used in health Internet nodes and health Internet clients (defined below).

A health Internet registrar is any organization that has been accredited by the US government to accept registered domain names, validate that the organization registering the domain name exists and has a valid digital certificate. Health registrars need not have any special credentials as healthcare organizations. They would contribute the registration information to a national registry of health domain names. Presumably, just as other domain name registrars they would charge a fee commensurate with their services for creating and maintaining healthcare domain names. Because the franchise to be a health Internet registrar is not exclusive, we expect that competition would keep the prices acceptably low.

We expect that there will be a 411 service for health domain names. The design is not trivial, however, because of concerns about this service being used to send spam.

A health internet node is a set of one or more servers operated by a single organization under a healthcare domain name. (The servers we refer to here include plain-old Internet servers, such as SMTP servers or HTTP servers.) An organization that operates a health Internet node agrees to configure them to certain levels of security. The levels of security that an organization agrees to in order to operate a health internet node include the following:

  • It won’t accept connections from outside its security perimeter that are not mutually authenticated and encrypted using TLS and digital certificates.
  • It will check that the digital certificate of the connecting client remains valid.
  • It won’t accept such connections that don’t offer a cybersuite that is sufficiently secure by standards set by ONC. (Aa cybersuite is defined in the TSL Internet RFC as the combination of cryptographic and hashing algorithms used to establish secure communications.
  • It will accept such connections using at least one cybersuite that has been established by ONC.

A health internet client is an IT system associated with a healthcare domain name. These systems are the clients that use the servers of healthcare internet nodes. Some organizations may operate healthcare clients but not operate servers. Many small practices would fall into this category.

The organization that uses health Internet clients has a health domain name but it does not operate a health Internet node. That would be maintained by a third-party organization. A wide variety of organizations may operate health Internet nodes on behalf of other organizations. For example, vendors of EHRs targeted at small practices may operate a health internet node on behalf of their clients, where each client has its own health domain name.

The above material comprises the basic framework that we propose. Pretty simple, huh?

Health Email.

We now extend the proposal to apply the framework and robust, widely available Internet facilities for a specific use case: interpersonal and interorganizational messaging. Those that have followed this thread that this is the start of a “fax machine on steroids.”

A health email address is nothing but an Internet email address for which the domain name is a health domain name. As with any email address the object that is referred to in the user portion of the email address could be almost anything. Some examples might include

reports_in@UShealth.alameda_family_physician.com

emergency_department@UShealth.somehospital.org

drMarySmith@UShealth.SmithandJones.com.

It would be desirable if a 411 service were to exist for all health email addresses.  This is larger and more dynamic than a 411 service of health domain names. We do not think it is necessary to get a lot of mileage out of health Internet email. In the meantime addresses will be passed as they are now, on business cards, on letterheads, on public web sites, spoken over the phone, included in trading partner agreements, etc.

A health email message is a message sent to a health email address. Such a transmission may contain protected personal health information. Sending data as a health email message does not offer the sender any assurance that the recipient is really a valid recipient under HIPAA or other regulations. That continues to be done the “old fashioned way” by knowing the recipient. Perhaps sometime in the future a 411 service could be built that offers legally acceptable assurance that the recipient really is a  healthcare provider. That would be great, however we do not anticipate this proposal waiting for the availability of such a service.

Health email messages will follow the conventions of email. In particular, they may have MIME attachments. We expect that ONC will promote the use of healthcare-specific standard formats for some attachments, particularly when they are prepared by or expected to be consumed by EHRs. However, we do not propose to limit health email messages to those that are in a standard format nor to tie this proposal to specific standard formats.

Achieving Meaningful Use Where HIEs Do Not Exist.

The use of standard attachments, however, opens up the opportunity for health email messages to be used for inter-system communications such as receiving structured lab results, transmitting CCDs from one practice to another and transmitting information to vaccination or chronic care registries. This proposal does not yet address certain features that are important for computer-to-computer transmissions including guaranteed delivery and irrefutable records of transmission and reception. Even if other services based on HTTP are required, the fundamental framework defined by the definitions here will support it. Using this framework for email and computer-to-computer messaging assures that the framework will meet specific needs and many imaginative uses not yet conceived.

In the diagram below we have examples of the kinds of organizations that might operate health Internet nodes and health Internet clients. Essentially large firms that now operate their own SMTP and HTTP servers would probably also operate the servers that support there health domain name. Practices and other organizations that outsource the operation of their mail and web servers would probably do the same  for their health Internet nodes.

We imagine that a new category of organization that we imagine will appear, the health Internet service provider (HISP). In addition to operating the node it seems likely that HISPs would assist their customers in registering healthcare domain names and find other business opportunities much as ISPs do today.

Small healthcare organizations would benefit by using an HISP for health email even if the small organization does not have an IT system. We can imagine HISPs offering web-based email clients for those organizations.

A small healthcare organization might also rely on its EHR vendor to operate a health Internet node on behalf of the small organization’s domain name. As the use of this approach for computer to computer transmissions grows this will be a very attractive value add.

Patient/Consumer Communications

Patients/consumers generally won’t have their own healthcare domain names. Nonetheless HISPs could register domain names specifically for their use in supporting consumers and offer those consumers secure email with healthcare organizations.

Looking Further Down the Road

This framework is not limited to simple messaging among people organizations or systems. The fundamental framework of health domain names can serve as a basis for any kind of communications that are already supported on the Internet, provided only that they are built up over TLS.

Other Claims

This proposal finesses the issue of a national public key infrastructure. It implies that there is one for the organizations that communicate using healthcare domain names but does not imply the need for a PKI encompassing all the individuals involved in healthcare.

We have specifically avoided S/MIME as an approach to secure communications because it implies a PKI for individuals.

SimpleInteropHISP1

Category: healthcare-providers  interoperability  vertical-industries  

Tags: arra  ehr  emr  health-internet  health-it  healthcare-interoperability  healthcare-providers  nhin  

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio


Thoughts on Simple Interop: The Health Internet Node


  1. David McCallie says:

    Wes,
    Thank you for nicely summarizing these ideas.

    The following IETF RFC may be of use in defining the details of how to create secure channels for SMTP using TLS.

    RFC3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security

    ( http://www.ietf.org/rfc/rfc3207.txt )

    –david

  2. Brian Ahier says:

    Great post. This is very thought provoking. I like the idea of a top-level domain – possibly .hc

  3. […] This post was mentioned on Twitter by Brian Ahier, Nathan Wright. Nathan Wright said: Simple Interop: The Health Internet Node: In addition to operating the node it seems likely that HISPs would as.. http://bit.ly/7XBVV4 […]

  4. Peter Basch says:

    This idea has lots of appeal and could solve the problem of secure push and possibly query (a privileged / authenticated query to all domains where the patient has had care) Any idea of the costs of creating / maintaining such a system compared to the cost of HIE buildout / maintenance across the country (including the NHIN).

  5. Mark Frisse says:

    Wes,

    This is very timely in light of the NHIN working group today. Great articulation. Thanks in particular for the figure.

    Mark

  6. Great blog Wes. Pleasure reading and hope this provokes more dialog on some of the ideas you have nicely offered up.

  7. […] Go here to see the original:  Simple Interop: The Health Internet Node […]

  8. Wes, thank you for taking the time to describe this in detail. This post really helped me see what you and David were describing, and I think that this is absolutely a viable method to facilitate HIE in this country. For those that are concerned how on earth this will morph or scale into a distributed or federated pull system to handle patient-directed exchange or longitudinal queries, I think the answer is (or should be) — it won’t. The resources and effort devoted to current pull implementations (such as XDS) will not be for naught, nor will the resources and effort devoted to the proposed simple push system once the challenges of the pull model are overcome. I see these being two complementary technologies that don’t compete, even if some of the technical aspects overlap.

    As an analogy, when the web (a pull medium) came along, it didn’t replace email (a simpler, push medium). It did largely replace the existing pull media, such as FTP and Gopher, but its usage profile was so much different than email that the two have managed to coexist very well, and even build on one another. Webmail systems such as Hotmail and Gmail revolutionized the way we as consumers interact with our inboxes, but under the hood, Webmail servers still rely on the same, simple, underlying protocols to communicate with one another, and with all the other email servers on the internet. Conversely, the ability for all email clients to send and receive HTML email has made for a much richer experience.

    So I think it’s worth keeping in mind that the core push-vs-pull distinction is really describing a difference in usage profiles, which will necessarily involve much different (but complementary) technologies. It just happens that one of them is (a lot) simpler than the other, so we may as well talk about how it might be implemented now, while we’re still working on solving some of the challenges with the other.

    I’ve got some suggestions for refinements and other thoughts on this over on a new blog at blog.recordnexus.com; I didn’t want this comment to be as long-winded as some of my previous ones!

    All in all, this is really starting to come together, I think. I’d greatly appreciate any feedback the group has on my refinements.

  9. […] sender to receiver rather than queried for by the receiver.  Wes’s latest posts (here and here) really sort of put it all together for me, and I now see what it is they’re proposing. I […]

  10. Shane Taylor says:

    I will make my comment fairly brief, but I wanted to link to a post on the EHR Scope Blog talking about the ONC Meeting Update.

    http://www.ehrscope.com/blog/onc-meeting-update/#utm_source=feed&utm_medium=feed&utm_campaign=feed

    It talks about the the presentation by Aneesh Chopra, Workgroup Chair of the HIT Standards Committee, that offered the Top Ten Recommendations from the Implementation/Adoption Experience Hearing on 10/29/09. As stated directly from the presentation, the top 10 Implementation Recommendations included:

    1. Keep it simple
    * Think big but start small
    * Recommend standards as minimal as required to support a necessary policy objective or business need, and then build as you go

    2. Don’t let “perfect” be the enemy of “good enough.
    * Go for the 80 percent that everyone can agree on.
    * Get everyone to send the basics (meds, problems, allergies, labs) before focusing on the more obscure.

    3. Keep the implementation cost as low as possible
    * Minimize costs associated with implementation standards, including royalties, licensing fees and other expenses
    * Open the NIST interoperability certification testing processes

    4. Design for the little guys.
    * Make sure the endorsed standards are as broadly implementable as possible, so diverse participants can adopt it, and not only the best resourced.

    5. Do not try to create a one-size-fits-all standard
    * Do not mandate or attempt to create a one-size-fits-all standard that adds burden or complexity to the simple use cases.

    6. Separate content and transmission standards.
    * Separate content standards from transmission standards; i.e. if CCD is the html, what is the https?
    * Separate the network layer from the application layer.
    * Avoid linking changes between senders and receivers.

    7. Create publicly available vocabularies and code sets
    * Ensure they are easily accessible and downloadable, with straightforward means to update or upgrade

    8. Leverage the web for transport “health internet”
    * Use what already works in transporting information securely on the Internet.
    * Decrease complexity as much as possible to shorten the learning curve of implementers.

    9. Position quality measure so they motivate standards adoption
    * Strive for quality reporting to be an automated by-product of using certified technology and standards, lowering the administrative burden of reporting to the lowest extent possible.

    10. Support Implementation
    * Make Implementation Guides available that are human readable, with working examples and testing tools.
    * Facilitate implementers’ use of Implementation Guides with effective national communication plans.
    * Publish open source reference implementations.

    Most of these recommendations are addressed by this approach. This is being discussed at the right levels. The nice thing about this is that it is much easier for people to wrap their heads around and thus can be realistically implemented in a shorter time frame. Exchanging health information by pushing is better than not exchanging it at all. In fact, it provides a huge amount of value while the pulling is being fleshed out. Nice work, guys!

  11. David Booth says:

    A few comments:

    – Standards for HIPAA-compliant secure email would be helpful. Thanks for raising this point.

    – I don’t see a need to create a registry of sites that support such standards, nor a need for special domain names.

    – A much larger issue is *semantic* interoperability: the recipient’s ability to automatically process and *understand* the content by machine. Our best hope for that is RDF, a standard developed under the W3C Semantic Web initiative:
    http://www.w3.org/2001/sw/
    RDF can be both precise and extremely extensible in capturing health information. At the Cleveland Clinic we have been using RDF very effectively in the Heart and Vascular Institute:
    http://www.w3.org/2001/sw/sweo/public/UseCases/ClevelandClinic/

    – It is worth remembering that email *can* be used as a transport mechanism for automated systems – not just human-to-human communication. This was done very effectively by the MOSIS project ( http://mosis.com/ ) some 25 years ago, long before HTTP was invented. MOSIS customers submitted integrated circuit designs by email, and their submissions were processed automatically by machine. Although REST-based HTTP interfaces are great for “pull” interactions, email is very convenient for “push”, it has a very low entry barrier, and it can be used both by machines and humans.

  12. Jim Klein says:

    Your proposal for a simple “push-centric” interoperability architecture is brilliant. The refinements offered by Liam Davis-Mead are excellent as well.

    Hopefully your position on the ARRA-mandated HIT Standards Committee will lead to CMS adopting this approach.

  13. Wes,

    It does my heart good to finally hear others promoting the virtues of a node-to-node cyberinfrastructure for the NHIN. For the past 5 years, we’ve been touting the value of such an architecture for providing the technological “glue” that enables all authorized parties to exchange patient data securely and inexpensively using PKI encrypted e-mail attachments.

    At this link [ http://healthcaretechnology.ning.com/forum/topics/novel-p2p-publishsubscribe ], we described a P2P pub/sub node network architecture that uses such a system enabling comprehensive data to be pushed asynchronously between patients/consumers, primary care physicians, specialists, hospitals, labs, regional and state HIEs, a national data repository, research organizations, and others.

    It includes a novel way to minimize bandwidth needs and computer resource consumption, interoperate with any applications via APIs, and accommodate any standards (including data format and terminology standards). It does this by using data grid templates reflecting information models the end-users need, as well as small delimited data files that can transmit huge amounts of information quickly and easily between disparate systems, as well as translate and transform the data as needed.

    I welcome any feedback.

  14. And here’s a link to a related post about how cloud computing, client-server, and node-to-node can work together via the NHIN:
    http://healthcaretechnology.ning.com/forum/topics/combining-cloud-computing
    Steve

  15. Following are some thoughts about the TDL concept:

    It’s useful, imo. Note that we’ve applied the messaging rules for managing email attachments to the email’s subject line (even body text and file attachment names could be used).

    The file attachment should always remain encrypted end-to-end (in transit and at rest).

    Since certificate authorities don’t typically verify that a person or organization who receives a digital certificate is actually who s/he or claims. Thus, to increase the security of the “.hc” domain and PKI certificate, there ought to be an independent organization that functions like a notary public to assure people are who they say they are. I know of at least one such company (a partner of ours).

  16. I talk a little more about the TLD idea here. CAs do absolutely verify what it is that the certificate is meant to certify. If they did not, the certificates they issued would be worthless. However, we’re simply very used to dealing with certificates used for e-commerce, which simply verify the website’s identity rather than an individual.

    These certificates, for example, say nothing definitive about the company operating the website or its management, and the CA issuing such a certificate need verify essentially nothing, as deploying the certificate to a domain other than the one which appears in the certificate will be flagged by customer’s browsers.

    Some organizations such as banks and the larger online e-commerce sites are now using the extended validation (EV) certificates that give you a green or blue bar in your browser, and additionally display the name of the legal entity for whom the certificate was issued. The CA will, in this case, perform additional checks to ensure that the entity does in fact exist, and the certificate request was in fact issued by a duly-authorized agent of that entity. So while I could probably apply for an ordinary server identity certificate for “amazon.com” (which would be worthless to me as it would be rejected by any browser visiting my site, unless my site happened to be at amazon.com), there’s no way I could apply for an EV certificate.

    Again, not every CA will issue every type of certificate, because they’re not comfortable performing or certifying these additional verification processes.

    I’m suggesting that something similar could be implemented for the certificates used in secure health messaging.

  17. […] ← Simple Interop: The Health Internet Node […]

  18. “[CAs] simply verify the website’s identity rather than an individual.”

    Yes, that’s what I meant. The gap is failure to tie a certificate to an individual. If, for example, I went to an authority and was given an electronic “token” on a USB stick (possibly based on a biometric index) that associated me (and only me) with a certificate, wouldn’t it provide the greatest authentication?

    I’m asking because we’re investigating the best way to guarantee that an encrypted email attachment is sent, received and opened ONLY by the designated persons. While PKI includes such authentication capabilities, do CA’s providing PKI certificates assure that only I can decrypt the attachment if I got the certificate online through their basic authentication process? Would the EV certificate suffice?

  19. And when I previously wrote that TLD could be useful, I wasn’t indicating that it would provide adequate security or is even necessary for security. Instead, I was referring that it could provide a logical means for organizing e-mail addresses in a mesh node architecture, as well as for providing criteria for implementing data workflow rules (although an email subject line would suffice). Security, otoh–which involves encrypting-decrypting a data file attached to the email that a publishind node sends to its subscribing nodes–would be based on the use of CA certificates (PKI), whether TLD is used or not.

    Nevertheless, if an international TLD solution could somehow add to the security of patient data exchange–even if it takes years to accomplish in a fair and reasonable manner–then I’m all for it! The complexities you note on your blog are, imo, valid concerns and good reasons for not making it a requirement at this time.

  20. […] Simple Interop: The Health Internet Node we described a simple scheme for enabling the Internet for secure communications among healthcare […]



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.