Information Technology Reference
In-Depth Information
Beyond these issues, the federated model is increasingly seen as the more sus-
tainable HIE solution for reasons that closely parallel the economic drivers of cloud
computing. Under a federated model there is generally no central data normaliza-
tion or standardization. The Internet is used as the vehicle for moving data among
the federated EHRs with special software performing the work necessary to transfer
data in a secure, private and trusted manner.
We will now turn to discussion of some specific HIE technologies starting with
DIRECT, a specific model to support federated HIE, and CONNECT, a centralized
open source technology. Both are supported by ONC. After this we will look at a
few commercial federated HIE technologies.
DIRECT:
In March 2010 ONC launched DIRECT, a set of specifications that uti-
lizes secure email and encrypted attachments to transport information from one
EHR to another. [
5
] An important supporting element of DIRECT is a Health ISP
(HISP), a software service that provides a special electronic provider directory that
is maintained by a trusted source much as professional licensure and credentials are
maintained by the relevant state board. The HISP can also distribute special “keys”
necessary to encrypt and decrypt email attachments and can route DIRECT emails
to their proper destination.
7
To understand the potential of this federated approach we'll consider a hypotheti-
cal, but not unrealistic, “advanced” implementation of DIRECT. It might work like
the Share button on many web pages where a user can click, and an article, photo or
video is sent to a specified friend. Similarly, to send a patient summary to another
physician might only require a click on a button or link. From there it would be neces-
sary to look up the receiving physician in the HISP. Ideally, the lookup function would
be integrated into the EHR. As we discussed earlier, this sort of integration of services
from one web site into another is already very common on the Internet. Once the
receiving physician is known, the EHR would retrieve their special DIRECT email
address and their public key for use in encrypting the record as an email attachment.
The record, now encrypted, would become an attachment on a secure email message.
Since the email address came from the HISP, there is an assurance that the message
will end up where it is supposed to go. However, permission from the patient for this
information exchange must be dealt with outside of DIRECT.
The email would be sent to the DIRECT inbox of the provider to whom the patient
is being referred and, ideally, the provider's EHR would retrieve the email, decrypt it
using their private key and interpret the data, placing it into proper context in the patient's
record. For example, lab tests or physiologic measurements from the referring provider
could become part of the profiles for those values in the recipient's EHR. This last step
typically requires that the attachment is in a special format we'll discuss next. This hypo-
thetical exchange of a record using DIRECT is illustrated in
Fig. 3.1
. As with many of
the illustrations, it intentionally avoids some technical details in the interest of clarity.
7
We'll discuss encryption in more detail in the security section of this chapter but it typically
involves two “digital keys” (long strings of characters). You encrypt a message to someone using
their public key but you need a private key - something that only the recipient should have - to
un-encrypt it. This insures that only the intended recipient can read the message.
