By Matt Adams and Katie Regan
Integration and interoperability were health care buzzwords in 2015, and we expect this to be the case for 2016.
However, these words are often used interchangeably, much like electronic medical record and electronic health record (EHR) were a decade ago. On June 9, 2005, the Healthcare Information and Management Systems Society (HIMSS) Integration and Interoperability Steering Committee defined both terms: Integration: “The arrangement of an organization’s information systems in a way that allows them to communicate efficiently and effectively, and brings together related parts into a single system.”
Interoperability: “The ability of health information systems to work together within and across organizational boundaries in order to advance the effective delivery of health care for individuals and communities.” Integration must occur before interoperability, but the two are tied closely together, and providers will face many challenges when it comes to implementing technology.
Health care systems need to be aware of several key security issues when implementing or integrating technologies. Navigation of these integration challenges requires standards, implementation of emerging technology and collaboration.
Integration security concerns
As health care has become more complex and IT has become more sophisticated, security concerns have grown. Increasingly, we are seeing security and privacy issues in the headlines. These breaches are costing providers millions of dollars to address. In some cases, legal actions and heavy financial penalties are applied. To address security concerns, it is important to identify the most common issues that arise when integrating technology.
Lack of agreement on protocols for integrating systems and devices.
Health care systems and health care vendors have to agree on the type of protocol used to integrate systems and devices. For example, will they use VPN tunnel, FTP, SFTP, SSL and HTTPS? The costs to connect systems and devices range from a few thousand to hundreds of thousands of dollars. Although authentication and other security features are built into the protocols, there are still areas that health care IT professionals need to address, such as the data, itself.
Health Level 7 (HL7) as a protocol lacks built-in security and authentication.
HL7 refers to the seventh level of the International Organization for Standardization (ISO) seven-layer communication model for Open Systems Interconnect, according to Health Level Seven International. HL7 provides a set of standards that “improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all stakeholders,” according to the January 2015 Working Group Meeting. HL7 was built at a time when intra-system communication authentication (point-topoint), such as a lab system passing information to a hospital billing system, was not a focus.
However, health care has become increasingly more complex, and Health Information Systems (HIS) have made health care delivery more dispersed (PCs, tablets, smart-phones, etc.). As health care has outgrown the original intended use of HL7, we are beginning to see gaps in security coverage. Addressing these security issues requires providers to engage their in-house IT departments, hire consultants or bring in middleware.
Non-health care applications may not meet security needs.
Many devices, third-party applications and EHR developers are incorporating non-health care tools, such as Application Programming Interfaces (APIs). APIs allow application connectivity among systems by clearly defining transmission and security rules. Amazon, Facebook and Google have provided APIs during the past decade to allow outside entities, including hospital systems, to successfully integrate and communicate with their technology. However, end systems in hospitals still require clearly defined message standards. The clinical systems will dictate these. Health care IT teams need to work closely with these outside companies to tailor APIs and other non-health care applications to their security needs.
Middleware can have security flaws.
Middleware is a software tool that patches together existing, often complex systems and allows data to be exchanged between multiple applications or devices. Most large EHR health care vendors have developed proprietary middleware, such as Epic’s Bridges and Cerner’s CareAware and OPENlink, but there are also third-party companies, such as Iatric Systems, Corepoint Health and Mirth, that offer solutions.
The value of middleware is undeniable because it mediates network services to applications, but it also comes with its own set of security problems. In some instances, middleware can create a secondary path for malware to compromise an application or data. According to a TechTarget article published in 2014, “By not mixing sensitive applications and more open (Web) applications on the same platform you can reduce middleware security risks, and also make it easier and less expensive to secure what’s important.”
Navigating security challenges
Navigating these emerging security challenges means establishing standards for implementation of emerging technologies, such as Fast Health Interoperability Resources (FHIR), direct messaging and collaboration between vendors and stakeholders.
The Cybersecurity Act was signed in December 2015 as part of the omnibus spending package. One takeaway from this is the requirement for the Department of Health and Human Services to enact a cybersecurity task force composed of government, public and private stakeholders. The task force must quickly develop a plan to assess cybersecurity risks and identify EHR interoperability issues.
Prior to the Act’s passage, the ONC Health Information Technology Policy Committee, the Centers for Medicare and Medicaid Services, and the Certification Commission for Healthcare Information Technology have focused on EHR functionality.
Implementation of emerging technologies.
As health care continues to grow in size and complexity, security requirements are constantly evolving. We are seeing the development of technology, such as FHIR, Direct exchange, XML and APIs, to meet these changing needs.
FHIR is the next version of HL7. It is much easier to implement because it uses a modern Web-based suite of API technology (mobile apps and cloud technology). FHIR is composed of modular components, known as “resources," which are integrated into clinical and administrative working systems suitable for use in a wide variety of situations.
Direct exchange is a secure HIPAA-compliant way to exchange personal health information electronically, peer-to-peer. Direct exchange allows applications, such as EHRs, to send messages and attachments (files) to individual endpoints using any other application via a direct address assigned by a Health Information Service Provider (HISP). Messages and attachments are encrypted during their entire journey, and the end users’ identities are validated cryptographically.
As consumers take a more active role in the integration process, it is no longer acceptable for vendors to block collaboration. As a result, vendor representation within government, public and private collaborative efforts is steadily growing. This has helped to create programs such as Direct Project, the Argonaut project and DirectTrust.
The Direct Project, launched by the ONC in 2010, required all EHR technology certified for use within Meaningful Use programs to be capable of sending and receiving messages and attachments according to the Direct protocols. This means that Direct, a method for the exchange of health information, is available to almost all eligible providers attesting to Meaningful Use. T
he Argonaut project has over a dozen health care vendors focused on “[developing] a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for electronic health records and other health information technology, based on Internet standards and architectural patterns and styles,” according to the Argonaut wiki.
DirectTrust, a nonprofit trade alliance, focuses on establishing and maintaining “a national, transparent Security and Trust Framework upon which trust relationships for exchange technology can be scaled and federated nationally,” according to the DirectTrust “About." Thirty-six HISPs comprise this group.
The industry is moving in a positive direction, according to the ONC’s April 2015 Report to Congress on Health Information Blocking. However, lingering issues are a direct result of the lack of past collaboration. For example, the availability of a standards-based network for interoperable exchange of health information is not sufficient, itself, to motivate actual exchange. Some EHRs and their customers have business models opposed to the exchange of patient data with competitors, even those caring for the same patients. In addition, huge variation exists in the usability of EHRs’ Direct user interfaces. Some vendors have made Direct easy to use, but others have hidden Direct exchange capabilities deep within the software or left out key components, such as an “in box” or attachment generator.
The path forward
Integration is the first step toward local and global system interoperability. “Integration” and “interoperability” are often used interchangeably, partly because they have inherently similar challenges. Whether connecting a lab instrument to an information system or an entire EHR to a Health Information Exchange, the information or data must be standardized, so communication and data can be sent and received accurately and securely. HL7 did that effectively for a couple of decades.
Transport protocols (VPN, HTTPS, SFT) and middleware provided an extra security layer, which was more effective in certain environments. However, the complexity of instruments to systems and of systems to systems grows exponentially, along with resources and cost. Early-adopted or interpreted security and data standards have shown severe weaknesses as breaches of security and privacy appear in headlines across the country.
Collaborative involvement on projects such as the Argonaut, DirectTrust and governmental regulations (i.e., MU and Cybersecurity Act) are helping to close gaps and provide the motivation and possibly the monetary incentives required to fix and navigate through integration obstacles. Integrating and securing complex, electronic patient care and workflow information is a herculean undertaking, but so were the moon landing and completion of the Panama Canal.
About the authors: Matt Adams is a health care IT analyst, and Katie Regan is the clinical publications manager, at MD Buyline.