Fortunately NHIN will not even tell you that the Direct Project is the end-all solution to making the ubiquitous exchange of health information a reality.

That being said, many interpret it as a simple evolutionary step to secure health information exchange and compliance. Let’s take a look at what the Direct Project is and specifies:

1. The Direct Project is a specification or recommendation about how secure health information exchange can be achieved via the SMTP protocol,

2. In order to interface to the Direct Project network, you will still need to rely on a health information service provider,

3. Each participant in the Direct Project will have a published Health Domain Name or HDN which is used for authentication; this will look like an email address or domain to users and is how other participants will identify each other

There are many other requirements that outline what is needed to adhere to the Direct Project specification, but above are the high-level concepts. In itself, it is a great and elegant approach to solving the problem of interoperability and health data exchange, but there are some items of concern that need to be addressed when determining how to gain widespread adoption:

1. While some vendors are supporting the Direct Project in software patches and new releases of software, what does this mean for healthcare professionals that do not have applications that will comply? How will they interface to the Direct Project?

2. What about large hospitals or groups that have many systems from multiple vendors? Will their router be able to interface to the Direct Project network without increasing the work load of already over-stretched IT staff?

3. While some vendors have updates and patches for adhering to the Direct Project specification, are there other requirements needed in order to comply, e.g. changes to a hospital’s SMTP server?

At CloudPrime we are very excited about the Direct Project and believe it does provide a solid foundation for improving health information exchange. Our concern, however, is that it will require that healthcare providers to allocate over-stretched resources to meet the requirements of Direct and get their health IT systems to integrate with the network even if their EMR/EHR supports Direct.

We believe that as an added goal of the Direct Project, implementation and integration should not be difficult and that health IT folks need a solution that will minimize the impact to their workflows and current workload.

CloudPrime is defining a better way for health IT professionals to take advantage of everything the Direct Project has to offer while minimizing the impact to their IT infrastructure and workflows.

In the last blog we discussed 4 major file types/documents that are used in healthcare data exchange: HL7, DICOM, CCD and CCR. In order to exchange these data types, application interfaces need to be deployed to allow for the integration of disparate healthcare systems.

Today, we will cover how applications communicate or interface with each other.

Interfaces typically use what is called a transport protocol, which “provides end-to-end communication services for applications within a layered architecture of network components and protocols.”†

The most common transport protocol in use is TCP or Transmission Control Protocol. Sometimes referred to as TCP/IP, it allows for applications to stream data to each other. For example, if you have a Patient Management System that generates HL7 SIU messages (scheduling messages) and that application interfaces to an HL7 routing engine, it is likely that the two interfaces would communicate via TCP.

In healthcare, there is a subset of TCP known as MLLP which adds specific delimeters to messages to denote the beginning and end of a message. The receiving application needs to know where one message ends and another begins in order to deliver the correct information to the system. In TCP, you would do this by specifying a length header, or more simply put, the details about where messages start and end. With MLLP, specifiying length headers is not necessary as the transport protocol inserts the delimiters for applications to know where the messages begin and end. Confusing, I know!

Sometimes, it may not be necessary or preferred to use TCP/MLLP for streaming data, and applications will use Simple File Transfer or file drop. This is accomlished by outputing the messages and storing them in a directory on the computer or server. Another application or interface checks the folder for new messages and consumes them when they are written to the directory.

Interfaces need transport protocols to exchange information and it is common for systems to need to communicate over various connectivity services, making integration somewhat challenging. Talking with your health information service provider and/or your integration specialist can help you understand the best method for interfacing healthcare applications together.

† Wikipedia, http://en.wikipedia.org/wiki/Transport_Layer

Yesterday we briefly covered what healthcare integration and interoperability is and what it means to the healthcare industry. In today’s segment, we will be discussing some of the file protocols that are used in conjunction with continuity of care and interoperability.

The file protocols that we will focus on today are some of the more popular formats: HL7, DICOM, CCD & CCR.

HL7 File Protocol

Much like the blood cell in the human system, HL7 messages are the lifeblood of healthcare data exchange. Established in 1987, Health Level 7 (HL7) is a non-profit organization that’s mission is to “[provide] standards for interoperability that improve care delivery, optimize work flow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients.”†

In more simple terms, HL7 is a file protocol through which care providers leverage a standard for sharing patient data. HL7 messages are broken into specific types that relate to a specific event within a patient record, also known as a trigger event [see list below]:

• ACK — General acknowledgment
• ADT — Admit discharge transfer
• BAR — Add/change billing account
• DFT — Detailed financial transaction
• MDM — Medical document management
• MFN — Master files notification
• ORM — Order (pharmacy/treatment)
• ORU — Observation result (Unsolicited)
• QRY — Query, original mode
• RAS — Pharmacy/treatment administration
• RDE — Pharmacy/treatment encoded order
• RGV — Pharmacy/treatment give
• SIU — Scheduling information unsolicited ‡

Each on of these trigger events is created by a hospital system and will need to be shared not just across internal systems, but also with hospitals, HIEs, physician groups, clinical labs, etc. that may reside outside of a healthcare providers network. Not each message type is relevant to all applications and many hospitals that maintain dozens of systems will leverage HL7 routing engines to deliver messages to the appropriate destination.

While the HL7 message protocol is a standard widely adopted healthcare providers, it is sometimes seen as Stephane Vigot of Caristix puts it, as a “non-standard standard”. What Mr. Vigot is saying is that even though the protocol specifies syntax and message headers for identifying pertinent information, different systems may use different templates. Take patient “sex” for example: one hospital may register a patient as either male or female and another may have up to 6 attributes relating to the patient’s sex. As a result, when systems are integrated, HL7 messages need to be normalized so that the systems know where to look for the information.

Version 2.x vs Version 3

Probably the most important thing to know about HL7 version 2.x vs. version 3 is that the latter has not been embraced by the healthcare industry yet. Version 2.x is a textual, non-XML based file format that uses delimiters to separate information.˚ Version 3 on the other hand is an XML based file format.

DICOM

DICOM stands for Digital Imaging and Communications in Medicine. Like HL7, DICOM is a file format for exchanging patient data, but is used in conjunction with systems that exchange medical images. DICOM messages are the file protocol of choice for PACS (Picture Archiving and Communication Systems).

For a list of all the Value Representation (VR) of a DICOM message, you can visit: ftp://medical.nema.org/medical/dicom/2009/09_05pu3.pdf

Continuous Care Document (CCD) & Continuous Care Record (CCR)

These two documents perform very similar functions, and are considered summary documents. Both CCD and CCR are XML based documents and provide a summary of a patients healthcare history. Included in a CCD or CCR document is a human readable section that covers the patients care history as well as pertinent patient information such as demographics, insurance information, and administrative data.^

The major difference between the two revolves around how closely one is tied to HL7 standards than the other and how much easier one fits into the current workflow of a particular health IT system. While some see CCD and CCR as competing standards, Vince Kuraitus of e-CareManagement argues that “the CCD and CCR standards are more complementary than competitive.” The basis of his opinion revolves around the ”the right tool for the job” metaphor and HIEs adoption of CCD doesn’t say much.

Summary

Integration and interoperability need file protocol standards and as the healthcare IT industry keeps evolving, many of the ambiguities of the current standards will eventually (hopefully) be normalized and conformity will prevail. In the meantime, HL7 2.x, DICOM, CCD/CCR are here to stay and will continue to be the lifeblood of integration and connectivity.

† http://www.hl7.org/about/index.cfm?ref=common

‡ http://www.corepointhealth.com/resource-center/hl7-resources/hl7-messages

˚ http://en.wikipedia.org/wiki/Health_Level_7#HL7_version_2.x

^ http://en.wikipedia.org/wiki/Continuity_of_Care_Document