Asymmetric Risks in Value Chains

October 28, 2014 / Integration, Security / 0 Comments

Big_&_Small_PumkinsBusiness need to connect with other businesses to trade and add value. Making trading fast and efficient means integrating software systems. And that means risk.

Letters, faxes, and telegrams may seem slow and quaint but at least they had the virtue of being safe. In today’s environment clicking on an unsafe link or opening an innocuous file can potentially lead to a billion dollar loss or even the end of your company.

Following last year’s massive Target breach attention has moved to Wall Street; the JPMorgan breach is causing state and federal regulators to add to the already massive internal pressures to improve security. One particular area of attention is the risk that comes from 3rd party vendors.

New York State’s top financial regulator, Benjamin M. Lawsky, emphasized the gathering danger to the financial system when vendors’ security is lax.

There are several critical problems in dealing with 3rd party risk. The first one is that the risk exposure is hugely asymmetric in most cases: one party has much more to lose than the other. This leads to the second problem which is that the smaller party can’t afford to spend nearly as much as the larger one on cybersecurity. The skill of their security staff will be lower, they will have fewer tools at their disposal, they may even be too small to afford round-the-clock monitoring. They also probably cannot afford enough insurance to compensate their larger partner for losses.

The first instinct of the larger party is to seek to impose their internal security standards on the smaller party; the goal is to avoid the smaller party becoming the weak spot in the fortress wall. This has the effect of raising trading costs. If the smaller party is a vendor then that vendor will need to raise their prices to cover the extra security costs. At some level those costs may become prohibitive; at my previous company we ended up no-bidding certain RFPs because the attendant security overheads were too high relative to the deal size. The next thing to suffer is agility: vendors whose security has been certified become automatically preferred for future work because of the time and expense involved in certifying new vendors. This reinforces the upward pressure on prices as incumbents are protected from new competitors. Innovation suffers as well.

How can businesses integrate with their value chain without taking on untenable, asymmetric risks? The Cloak Labs Global Virtual Bus provides businesses with a way to loosely couple with their partners. Using a combination of cryptographic and network techniques, the Global Virtual Bus can insulate each partner from the security risks of the other. Credentials do not need to be exchanged, firewall ports do not need to be opened, connecting servers do not need public IP addresses.

Learn More! Download the White Paper!

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.


How Cloak Labs Transforms Enterprise Messaging

Our customers need resilient, secure and easy-to-deploy application  messaging solutions that meet their changing demands. As more and more buzz around the cloud, application migration, security and compliance percolate to the surface, Cloak Labs has peaked the interest of more and more CIOs and Infrastructure Managers.

Transform: Cloak Labs enables enterprises of all sizes and industries to transform how they connect applications. Our cloud-based infrastructure provides scalability, embedded security, resliency and economies of scale. Because of the Cloud, our customers can rely on a service based messaging infrastructure, allowing managers to focus on mission critical tasks instead of deploying and managing costly VPNs and hardware.

Manage and Serve: As a service, Cloak Labs provides a robust network that guarantees the delivery of every message as well as providing “military grade” security and encryption.

Build: With Cloak Labs you can build application interfaces in minutes regardless of the application or transport protocol.

Consume: Cloak Labs’ application messaging services are easy to consume and do not require any hardware installation or IT training.


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

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.

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.

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.

Reference

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


New Healthcare Integration Challenges for ISV’s

With new regulation comes new opportunity. New healthcare requirements around the digitization of health information has caused a wide variety of start-ups and services to surface. Innovation is great, but there are very few standards being adhered to, causing a lot of headaches for ISV’s who are working with new customers to implement their systems.

If a hospital, physician, or clinical lab would like to start using a new product or service, that application needs to be able to communicate with older systems that may not be ready for retirement. Who will be responsible for ensuring that the two systems can interface to each other? How much will this cost and what impact will it have on deployment schedules? This typically falls on the vendor and a solutions specialist needs to be brought in.

Take for example a PMS system at a physician practice that now needs to communicate with a scheduling system that resides in a data-center off-site. The physician PMS will need to exchanges HL7 SIU messages with the scheduling system securely, meeting HIPAA requirements for health information exchange.

In order for this to happen, a secure connection between the two endpoints needs to be established, application interfaces need to be built, ports to the firewall need to be opened, and eventually a mechanism for ensuring each endpoint is authenticated must be implemented (See Wikipedia Article under Security Rule). What seemed to be a simple roll-out of a new system now requires professional services, network changes, and protocol conversion if there is a different transport protocol in use.

These integrations and road blocks can increase sales cycles and implementation times, making it harder to sell while decreasing margins for the ISV. Not to mention, the burden this may place on the customer.

Once an integration occurs, it is also necessary to monitor and maintain the network, which requires IT resources that may not have previously existed or may not have the bandwidth to support an increasing number of integration points.

As part of your integration strategy, it is important to evaluate a build vs. buy strategy:

– What will be the cost impact of rolling a VPN and application interface for each endpoint?

– What will be the cost of managing and maintaining that network?

– Who will bear the cost?

– What impact will this have on implementation times and sales cycles?

– As compliance regulations change, how will this impact your solution and margins?

Healthcare interoperability is an extremely important part of HIPAA regulations and a lot of health IT professionals will be focused on it, but as an ISV, connectivity may not be a part of your core offering, making it a distraction instead of an opportunity. If the numbers do not add up, it may make sense to use an application integration service as part of your value proposition to the customer, making implementation smoother, and decreasing network costs.


Application Interfaces: VPNs are not the answer

You have a new application, vendor or hospital that you need to interface to. Everyone in meeting grumbles about how the application interface will be built, where the resources will come from, and who’s budget will take the hit for adding the new partner.

To get started, you start thinking about everything that will need to happen:

1. A new VPN connection will need to be created to bring the new trading partner onto the network… paperwork with the hosting company or telco, network configuration changes, firewall ports opened, etc.

2. Depending on the application or partner you are working with, you need to understand what interfaces you will need support/build, e.g. does the application have a specific transport protocol you are not familiar with, is there a specific message protocol that you will need to convert

3. Specialist that have worked with these types of interfaces will need to be selected and contracted

4. Depending on how many connections you are creating, you may need to bring on additional staff to manage and support these connections

5. If any value added services such as guaranteed delivery or file tracking need to be implemented, this will increase the scope of contract work

6. Each connection will need to be tested thoroughly

VPNs provide the basic necessity of secure connectivity, but they are a unwieldy solution for IT organizations that are faced with deploying many connections and are limited on technical resources, time, and money.

When working with new trading partners, healthcare application interfaces, or vendors, VPNs may not make the most sense for your needs. Think about some of the problems you may face when adding new VPNs and how you can mitigate those pain points:

1. Are there other secure, application connectivity solutions available? If so, do they offer the most basic needs for interoperability?

2. Does the VPN solution offer file-level tracking, encryption, guaranteed delivery and web portals to view message and data traffic?

3. Are there solutions available that do not require changes to the firewall and/or network

4. Is there a solution that will require minimal IT support, reducing the total cost of ownership for maintaining secure outbound connections?

5. Will these connections continue to meet changing government standards for connectivity or will additional work need to be done to keep them compliant?

6. Is there a solution available that does not take weeks or months to implement?

There are many more questions to be answered, but the basic question is “can you find a better way?”. As technology advances and the Cloud becomes a more trusted platform for offering services, it may be time to start seriously evaluating alternatives to VPNs.


Preparing for Health Application Interoperability

2011 is going to see a dramatic increase in the adoption of EHR software and digital patient information exchange will become an even greater priority in order to meet Stage 1 meaningful use requirements.

If you are an IT Manager, this looks like it will require an all hands on deck and a huge shift in how things have been run throughout your organization. Since all patient data will need to be exchanged digitally in a safe and reliable way, you will be tasked with:

  • Ensuring application interfaces can connect internally as well as make connections outbound through your firewall
  • Making sure your IT ecosystems are documented carefully to determine where the holes are in internal and outbound connectivity
  • Allocating resources for managing all new connections and configuring your firewall to accept new connections
  • Dedicating staff to managing the new network; either adding to overhead or detracting from other initiatives within the organization

Some things to think about in 2011 as you prepare to meet these new requirements are:

1. Meaningful Use Incentives: Registration for the EHR Incentive program started on January 3rd: http://www.healthcareitnews.com/news/government-ehr-incentive-program-ready-go

2. New Infrastructure: New processes will need to be learned as you begin interfacing to all the EHRs, PMS’, HIEs, Physician Groups, Clinical Labs, etc. being brought onto the network.

3. Security: All patient health information will need to be encrypted and transported securely in order to meet HIPAA compliance.

4. Training: Staff will need to be trained and allocated to manage these networks. As your network continues to grow, so will the resources required to support and manage it. Changes in your firewall will need to happen and application interfaces will need to be built.

5. Solution Providers: HISPs (Health Information Service Providers) will need to be selected. Not everything can/should be done in-house, so you will need to determine how to minimize the total impact of these new application interoperability requirements. Your EMR may already provide application interfaces, but it is possible that many of your systems do not support outbound connectivity.

2011 will bring a lot of change for the healthcare industry as a whole, and with that change, progress. Despite the huge burden these new regulations will have on IT departments large and small, the end game will produce a cohesive, secure and reliable patient information exchange that improves the quality of care for all Americans.