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?
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
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.
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.
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.
Read Complimentary Relevant Research
Four Ways for CIOs to Cultivate Digital Dexterity in Leadership and the Workforce
To thrive in the digital era, enterprises need digital dexterity as an organizationwide competency. CIOs can boost their value by developing...
View Relevant Webinars
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.