In Simple Interop: Use Cases we set the challenge of communicating among people and Health IT systems in a manner that does not create a “walled community” where all those that practice with EHRs and HIEs have no ability to use the Internet to communicate with those that don’t. The biggest challenge in such a mixed environment is dealing with structured data. We posit that the structured data will be transferred as file attachments.
First we will review the basics of how file attachments and multimedia are packaged in the Internet protocols for email and Web posting.
MIME Provides the Package
The Multipurpose Internet Mail Extensions (MIME), which are used to send attachments in email, Although MIME was originally conceived for email it has proven a very versatile protocol, entirely independent of the protocols that specify mail transmissions. It is now used to upload or download files to or from Web servers.
MIME is also what enabled the transition from plain text email to HTML message. As I described this in Rant on Heath Information Technology Asynchrony the transition was accomplished by the simple ruse of having the sender send both a plain text copy and an HTML copy in the same message, and letting the receiver decide which to display. We propose a similar approach to breaching the walls between the “walled communities.”
Structured Data as File Attachments
Our basic approach is simple. The secure emails that are sent from one healthcare organization to another can contain free form text and structured data in file attachments. To use MIME for structured attachments it will be desirable to obtain Internet media types from the IANA in order to assure that browsers and email clients can use the files uniformly across operating systems. Internet media types are also called MIME types or content types. They are registered strings that indicate what kind of data is in a part of a MIME package. Some existing Internet content types are
and application/EDI-X12. Until the content types are obtained experimental content types are available.
Processing Structured Attachments Files
Transmission can be initiated by a user in an email client or any other program that can generate email, including EHRs or components of them.
In general we do not presume that the sender knows how the receiver will process the file. Receivers will process incoming messages in one of three ways.
The message will be viewed by a person who can read the plain-text portion of the email and may have “viewers” for some of the attachments. Viewers are programs that such as Acrobat Reader that are easily installable on client systems and display file attachments for a person to read. We postulate the availability of open source viewers for all healthcare structured formats specified as a required capability for meaningful use. Nonetheless, there is no guarantee that the recipient has viewers for all the attachment types that the sender can create. If a few researchers around the country have developed a novel way to represent gene networks or some yet uninvented bit of medical data, we want them to enable to secure exchange of patient data in this format so that industry can easily get an experience base on which to base solid standards.
From time to time, the situation will arise where information sent to a person cannot be read by that person. It can’t be represented in plain text, perhaps, and the person does not have and cannot download a viewer for the file. We accept that as the price of progress and expect the communicating parties to work it out, probably using fax or PDFs.
On the other hand, we believe that if there are viewers are available for all the standards that EHRs are required to generate or accept for each stage of meaningful use, and if physicians use PDFs for reports, EKG strips and other unstructured data, and if DICOM viewers are available we believe the level of actual interchange of structured data will rise substantially with the simple interop approach.
The message and attachments will be viewed by a person and then passed to an EHR to be added to the patient record. This depends on the EHR software providing the user with a way to present the data to the EHR. We don’t care to standardize how this happens although we will note that the user functions in general will require the user to aid the EHR in matching the data with a patient. Some EHRs may compete by making this easier for users. For example, they could examine the structured data for patient identification information and use that to accelerate the search needed to match the data with existing patients.
The “user name” portion of the health email address is not associated with a person. The email represents a transaction that goes direct into the workflow of the receiving system. For example, a health email address such as email@example.com might examine the file for structured attachments that the EHR understands for lab results. The EHR might attempt to use order number or an automated patient lookup to match the report with existing patients. Upon success it might store the data in the EHR and set up an alert for the ordering physician to review the labs. If the EHR fails to find lab attachments, finds other attachments that it cannot understand, or cannot match a patient the message would go into a workflow queue for a staff person to deal with it.
Adding HIE and Other Special Services
We can envision a number of special services built around systems that are not EHRs For example in Simple Interop: the PHR we describe a way that PHRs might use the user name part of the health internet address to file incoming information for the consumer.
The original recipient could be a system that relays a file, adding value. If the incoming email address were lab_routing@medinfo.YubaHIE.org, then the HIE might look up the ordering physician, choose to deliver both to firstname.lastname@example.org and it might amend the message to add the specific patient ID that Yuba Pediatrics uses for the patient. If the message indicates that a copy should go to a consulting physician it may be able to resolve the location of the physician from the info in the report and send the message as email or a faxed printout according to the capabilities of that physician. If the message was a positive report that must go to public health it might automatically deliver the message to public health.
Ensuring Standard “Standard File Attachments”
We expect that certification programs contemplated as part of ARRA will assure that EHRs can produce and consume standard attachments. We would like to see ONC use its influence, funding and authority to also ensure that file viewers for the standard attachments are available free for all major technology suites. Ideally these viewers will come from open source communities. A certification process could ensure that a specific communities’ viewer is more than “demoware” and installs easily. Such readers could be certified as “components” of EHRs although they are likely to be used in facilities that don’t have fully certified EHRs.
Enabling New Ideas in Structured Data
We also advocate the use of non-standard structured attachments. Indeed, we don’t think it is practical to avoid their being used in an environment that supports person-to person communications. To minimize the impact when two parties interact we advocate some policies that allow such experimentation to flourish. These include
- Using the plain text part of the message to identify the purpose and type of the structured file.
- Encourage that file viewers be produced as part of projects that create non-standard formats
These policies cannot be rigidly enforced. On the other hand, the notion of readers is widely accepted in the Internet culture.
Frankly, we hope that our approach will encourage experimentation and trial implementations of proposed new standards. We would love to see future standards become Federal imperatives only after they have been implemented and provided out inside a secure Internet infrastructure.
Such experimentation may lead to the development of interactive applications better implemented over HTTP rather than SMTP. This is no problem, our simple Interop approach is a secure shell that can incubate RESTful applications as well.
Upward Compatibility in Standard Formats
When I wrote the original specifications for HL7 version 2 I included an approach that ensured the best possible interaction between two systems running on different point releases of the standard. Under that approach:
- If a system that had upgraded to a new point release received a message from a system using the old point release, it processed that data from available in the old release and assumed “undefined” for new data items. Depending on the application it may not be able to function with undefined data but most of the times it could.
- If a system that had not upgraded received a message from a system that had upgraded, the receiver would ignore the new data. Because it had not upgraded it could not possibly need that data to fulfill its functions.
Although the HL7 v2 standards were created following this discipline it was seldom used in the field. Care delivery organizations relied more on mapping in their interface engines instead. As we scale interoperability up from connecting a few hundred systems within a large CDO to tens of thousands, it is time to revisit this principle.
This pretty much wraps up a series of posts that have evolved as the idea has grown through discussions in comments and email. There are still many loose ends, the most important of which are addressed in Simple Interop: Issues Associated with Automatic Processing.
We look forward to hearing your thoughts on this through comments. You might consider this important question, after you have read the Interim Final Rule on meaningful use, produced by ONC. Should our Simple Interop approach be put off until Stage 2 of meaningful use certification, or could it be considered a voluntary way of meeting the requirements for Stage 1?
Category: Healthcare Providers Uncategorized Vertical Industries Tags: ARRA, EHR, Health Information Exchange, Healthcare Interoperability, Healthcare Providers, HIE, Meaningful Use, NHIN, personal health record, PHR, Stimulus