The Gap in HIPAA’s Requirement for Encryption in Transit and at Rest

This post is going to get a wee bit technical so bear with me. There is a well publicized HIPAA requirement that

PHI (protected health information) must be encrypted in motion and at rest.

This requirement has been interpreted to mean that:

  • PHI transmitted over a network (or even carried via removable media) must be encrypted
  • Data on disk must be encrypted

HHS documents often refer to NIST’s Guidelines on TLS. (TLS is what has replaced SSL except in normal discussion). What the current Heartbleed problem with OpenSSL lays bare for all to see is the gaping hole in what encryption in motion can mean.

The problem is that for the most part the encryption in motion is different than the encryption at rest. Different algorithms and keys are used and different systems have responsibility for crypto. Simply put, this requires the data to be unencrypted when moving from the network to the disk.

Cloak Labs’ technology allows a message to go from one server behind a firewall to another server behind a second firewall without exposing either server to the outside world. Inbound firewall ports don’t need to be opened on either side and the data stays encrypted in webserver RAM, essentially adding an extra barrier between your sensitive data and potential attackers.

Defense in Depth: Why SSL is not Enough

April 10, 2014 / Healthcare, Security / 0 Comments

This week’s revelations of the Heartbleed defect in OpenSSL has been eye opening for the entire Internet. Bruce Schneier labeled it “Catastrophic. On the scale of 1 to 10, this is an 11.”

The Snowden revelations raised our collective concerns for the security and privacy of the internet. Even those who attribute only noble intentions to the NSA realize that if the NSA can crack a code then perhaps less savory actors can as well.

SSL is something we’ve all taken for granted as something that just works to keep internet connections secure. As computers have gotten faster key lengths have increased. The SSL algorithm itself has been replaced by TLS but the old name has stuck around. SSL has been so useful and simple that it has been embedded into every browser, almost every VPN, and now even in thermostats and smart refrigerators. The Internet security community has figuratively put almost all their eggs in one basket. That metaphorical basket has just been dropped on the floor and now we have a cleanup on aisle 4 of epic proportions.

At Cloak Labs we have reviewed our production and development systems to make sure that we are not vulnerable. Our enterprise messaging system does not use the defective version of OpenSSL and was never at risk. We did have to patch one of our WordPress servers but that was about it.

But more importantly, Cloak Labs’ messaging technology provides defense in depth. Even if we had been running a defective version of OpenSSL the RSA and AES layers used to protect your messages would have not been compromised. The security provided by AES is second to none and Cloak Labs’ robust approach to PKI makes compromise of the RSA layer virtually impossible.

At Cloak Labs we enjoy using fortresses as visual metaphors for network security. In that vein, here’s SSL:

Frontier Fort

Frontier Fort (Courtesy PublicDomainPictures)

And here’s Cloak Labs:

Vauban Fortifications

Defense in Depth as Designed by Sébastien Le Prestre de Vauban

Vauban was one of the foremost military engineers of the 17th century. He mastered the concept of fortification in depth. I learned about him studying about the past glories of France in the French expat schools I attended as a child.

Which fortress would you rather be inside of?

Dr. Michel Floyd
Cloak Labs

Athena Health: More Disruption Please

October 10, 2012 / CloudPrime, Healthcare / 0 Comments

I recently spent an amazing two days at the Point Lookout Resort in Northport, Maine with a community of “disruptors”.
Athena Health’s second annual More Disruption Please Conference, an event aimed to accelerate disruptive innovations in health care, brought together more than 100 CEOs, entrepreneurs, Venture Capitalists, academics, and software engineers to discuss ways to drive the industry towards innovation, openness and collaboration.

Traditionally, the healthcare has been an industry driven from top down. After attending this conference, I realize this is going to change dramatically. Bringing innovative technologies into healthcare will change the way information is distributed and transferred. These technologies will enable doctors to spend more time with their patients and give them better care.  The less time the doctor has to spend on paper work and transferring information, the more time they will have for their patients.

Our world is ready for a disruptive innovation in healthcare.

From my conversations at the conference, it is clear that the first phase of this disruption is the use of smartphones and the process has already begun. I decided to test this by looking for diabetes apps on my phone and 20 came up! Can you imagine the global impact this will have? Technology is global and allows us to have access to people instantly–We can have a specialist in Iceland look at our chart in seconds. Just think about the billions of users this can benefit?
While we are already seeing disruptive innovations working, I believe a dramatic difference will be seen within the next five years. In underdeveloped areas we are seeing a huge difference as they are coming from a clean sheet of paper.
Cloak Labs is a disruptive innovation. We supply the secure messaging that medical applications can interface to. Cloud computing in general will have a huge impact in healthcare. Costs of healthcare will be reduced, we will have greater access to industry specialists across the globe, and we will have easier communication. The percentage of smartphones is rapidly increasing which will enable this change.

This is not just hype, it is reality. Once the applications are in place, we will all see a disruption in healthcare and many other industries, for that matter.

The Cloud in Healthcare – Top 10 Takeaways from iHT2 San Francisco

March 30, 2012 / CloudPrime, Healthcare / 0 Comments

In the spirit of David Letterman’s top 10 lists here are our takeaways from the San Francisco iHT2 event this past week.

  1. IHPs (large integrated health providers, like university systems, etc), are by and large going with EPIC for EHR solutions, thereby automatically forgoing a degree of flexibility and any chance of real near-term interoperability.
  2. The historical problems of security, reliability, and control with Cloud-based solutions are being rapidly overcome, and the cost savings from hosting data and applications in the Cloud are becoming so compelling that increasingly complex medical organizations and systems will require the Cloud in order to be effective and efficient…..or risk becoming extinct.
  3. The HealthCare system, as usual, is the last great industrial complex to accept collaboration and efficiencies based on advances in information technology.
  4. There has been a dramatic shift in the last two years toward the use of mobile and portable devices in all aspects of care, and this will only increase.
  5. Nobody can really define the phrase  “HIPAA compliance,” it is best approached and understood as a process, it is not just about security.
  6. 30% of the vendors sponsoring were cloud-oriented.
  7. Edge, last-mile connectivity in a HIPAA compliant fashion was a common pain point from small patient practices to large integrated health providers.
  8. Cloud-based or service platforms having the ability to be more nimble and in turn handle the growing complexity of connectivity, interfacing, and interoperability are available and should be considered.
  9. The cloud mitigates the need for traditional software upgrades and release cycles.
  10. CIO’s and CMIO’s are opting to outsource for best-of-breed services and applications.  Driven by skilled resources in healthcare IT becoming increasingly scarce and more robust SaaS/cloud-based options being available.

One Person’s Experience with Healthcare Interoperability

March 22, 2012 / CloudPrime, Healthcare / 0 Comments

…or, Who Suffers When the Dots Cannot be Connected?

I have had the unfortunate experience of having my wife of over 30 years pass away from pancreatic cancer. She lived for 18 months from her initial diagnosis. Prior to that she had been a very healthy 62 year old.  During the course of her illness, she was treated in five different hospitals, was under the care of over 40 physicians, and had numerous surgical and diagnostic procedures. One might say,  “Well, this was certainly an edge case.” But hasn’t experience shown that it is the edge cases that bring out the flaws in the system? While I participated in her long and painful journey I came to realize that in spite of all the assertions made about information exchange and interoperability in healthcare, they are almost nonexistent once you go outside the four walls of a hospital.

The fact is, unless the patient or their family takes responsibility for the information that different hospitals and doctors will require when they come on board, they will have no reasonable way to have access to that data. During my wife’s illness, on numerous occasions, I had to hand carry DVDs, CDs,  or memory sticks so that other physicians could see the results of CT scans and radiology reports. I had to manually maintain a spreadsheet of her medications since there was no centralized system that was kept up to date, even where she was being treated. Obviously, the more manual recording the greater the chance for error, not to mention lost time.

I am writing this blog as a call to action. While many are wringing their hands over healthcare costs, in my opinion IT Vendors and Hospital Administrators are doing a great disservice to patients and medical personnel by not forcing their vendors to make it a high priority to improve interoperability and information exchange. As we all know, there are a number of high level committees and organizations that are working on this problem. However their progress is slow and the need is now.

Many of them have not even thought through how the Cloud can be a game changer.

The reality is that if Apple can provide iCloud so that users can upload all their content of different types to a single user ID and then deliver it to multiple devices, it is not so far fetched that the same capability could be applied to patient records. Patients typically have single identifiers. The notion that information stored in the Cloud is neither secure nor easily accessible has been proven to be a myth.

In addition, there are companies who provide low cost HIPAA compliant secure messaging solutions that can be implemented in minutes that will securely transfer data to and from the Cloud as well as between applications hosted in the Cloud.

It is my belief that if as much attention and investment is focused on medical information exchange as has been placed on making billing systems interoperable, we will have not only improved patient care  but a more efficient use of our medical resources as well.

Response to NY Times’ Steve Lohr — Healthcare Connectivity

horse-before-cartMr. Lohr, great article and thank you for covering this topic.

Any story about hospitals taking steps towards connectivity is great, but I fear that most think that connectivity is a little easier than it really is, that it’s just a matter of getting everyone together. Integrating hospital systems is challenging enough, but it’s “everyone else” that will pose the greatest challenges and thus making connectivity a fragile vision if it cannot be streamlined for smaller practices, independent physicians, clinical labs, etc.

Mr. Lohr points out that only 25% of physician practices today are computerized, and that should improve given incentive payments and consequences for non-compliance. However, the real issue is that we are putting the carriage before the horse; physicians will adopt patient management systems, EHRs, and EMRs, but the connectivity piece will still be unanswered. Furthermore, smaller practices and physician groups most likely will not understand why it is that further steps for compliance need to be taken as most of them are being educated (by the very software vendors selling them their wares) that if they merely install software that allows them to manage patient data digitally, they are going to get compensated.

Recently on a call with a hospital CIO, we discussed how they had to put a connectivity project on hold because of the 200 physician practices outside of her hospital she had to bring onto the network, only 120 had EMRs and none of them wanted to deal with having to deploy and manage a VPN. Seems trivial, but the reality is that doctors are doctors 1st and anything not related to treating patients is a distraction and is perceived to decrease their bottom line (In the Docs’ defense, VPNs are a blunt instrument and I don’t blame them).

Healthcare connectivity is a long, windy road that needs better planning, better ideas, and better solutions. The Direct Project sponsored by NHIN is a great foundation for simplifying and standardizing connectivity, but this battle also needs to be won with hearts and minds.

Direct Project — Hooray!?

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 Cloak Labs 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.

Cloak Labs 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.

Healthcare Integration & Interoperability — Part 3

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.

Part 1 | Part 2

Healthcare Integration & Interoperability — Part 2

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 application interface

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 who’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:

  • 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 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). Value Representations (VR) of a DICOM message.

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.


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.

Part 1 | Part 3

Healthcare Integration & Interoperability — A Mini Series

Completely inspired from my trip to HIMSS last week, I thought it made sense to talk about healthcare interoperability, connectivity and the component pieces to making this happen. This mini series is broken up into several parts that will cover:

  1. What is connectivity and interoperability?
  2. File protocols, formats and requirements, i.e. HL7 (including discussions on version 2 vs. 3), DICOM, EHI, and CCD;
  3. Transport protocols and interfaces: MLLP, TCP/IP, FTP, etc.;

Part 1: What is Healthcare Integration and Interoperability?

According to HIMSS, healthcare integration “is the arrangement of an organization’s information systems in way that allows them to communicate efficiently and effectively and brings together related parts into a single system.” †

The 2006 White House executive order defines Interoperability as (section 2 paragraph c):

Interoperability” means the ability to communicate and exchange data accurately, effectively, securely, and consistently with different information technology systems, software applications, and networks in various settings, and exchange data such that clinical or operational purpose and meaning of the data are preserved and unaltered.


These are great standard definitions and allow you to understand the difference between the two. Integration relates to how systems can work or collaborate for a common purpose, e.g. a patient management system working with a scheduling system. Interoperability speaks to how these systems are connected, in order to provide a continuous flow of information that improves care for the patient.

In order to achieve Interoperability, systems must be connected in a secure way, authenticating all users and allowing one healthcare application to share data with another anywhere in the country, without compromising a patient’s privacy.

From a real world scenario, what this means is that all systems must be integrated in order to achieve interoperability, i.e. a physicians patient management system must be able to authenticate and securely connect to a hospitals EMR; Ambulatory centers to pharmacies; hosted EMRs to wound treatment centers. Patient information can no longer live in just one place.

Interoperability Dimensions

(As defined by HIMSS)

  • Uniform movement of healthcare data
  • Uniform presentation of data
  • Uniform user controls
  • Uniform safeguarding data security and integrity
  • Uniform protection of patient confidentiality
  • Uniform assurance of a common degree of system service quality

No Small Task

Connecting all of these systems is no small task and is as much of an organizational challenge as it is a technological one. People and healthcare systems no longer exist within a vacuum and teams need to collaborate to make integration projects happen. These same people will need to agree on the best way to solve the connectivity problem and rely on the guidance of Health Information Service Providers to come up with solutions that meet the needs of all while adhering to the mission of improving patient care. As we continue to move forward in achieving interoperability, the scope and magnitude and of what needs to happen cannot be underestimated and careful planning must take place.

Throughout the mini-series, we will discuss the component pieces that are involved in achieving interoperability including application interfaces, file protocols, transport protocols, security & authentication, and compliance.

The Goal

Integration and Interoperability are significant pieces of the Meaningful Use objectives and the mission is to improve the care of individuals while providing them with secure, ubiquitous access to their health information. While there is no one way that can solve the challenge of interoperability, understanding the mission and the various parts of the goal can help make achieving connectivity as prescribed by the ONC and Meaningful Use.

Healthcare Interoperability Panel Discussion

Part 2 | Part 3