The Difference Between HL7 and APIs: What CIOs Need to Know to Succeed with the 21st Century CURES Act Final Rule

The 21st Century CURES Act Final Rule is a major change for healthcare data interchange.   The reason being is because patients are now entitled to use Application Programming Interfaces to download their health data into their application of choice.  Further reinforcing the original intent of HIPAA, this empowers patients to download their data and use it as they see fit.  This legislation demonstrates an evolution of technology since the original HIPAA Security Rule. 

How does this fit in with what CIOs need to know?   Since this is an evolution, there are new technologies that have to be integrated into the stack to be able to appropriately use this and provide our patients with the assurance that we are securing their data.  We’re going to go over the history of the Security Rule, its intent, and take a tour through how we’ve leveraged technologies over the years to gradually support more and more of it.  We’re then going to cover the core technologies and principles behind a successful Fast Health Interoperability Resources (FHIR) implementation to support patients’ needs securely.  These technologies, OAuth2, FHIR, and a robust API Security Program, support the intent of the 21st Century CURES Act Final Rule.  Our goals here are to be able to assist in understanding the gaps between the protection we have now, and what we need in the future.

The intent of the HIPAA Security Rule is to enforce the confidentiality, integrity, and availability of healthcare data using authentication, cryptographic hashing, and encryption.   Data has to be restricted to only those who have a defined need in payment, treatment, or operations.  Patients also have access to those records.  However, at the time it was written, many of those records were still paper.  People carried around bad faxes, printouts, or bad data.

The original standardized data interchange format in healthcare was Health Level 7 (HL7).  HL7 provided a common format that applications could use to send data about patients to each other.  Many applications still use it.  There are two versions currently in use.  HL7 version 2, which is still the prevalent version, uses a delimited format to exchange data.  HL7 version 3, which is a more modern version, uses eXtensible Markup Language (XML) to provide self-describing data.  This means that analysts looking to debug HL7 may have a much easier time debugging data elements.  Mediums to exchange interface data can be text files transported over secure or insecure means, or a straight TCP connection between applications.  Encryption was not common when first implemented.  Neither was robust integrity checking.

However, with the Security Rule, organizations needed to secure data in transit.  For data interchange, that meant that Secure Shell, FTP over SSL, and Secure FTP replaced existing file transfer protocols in many implementations.  Transport Layer Security (TLS) was also used to transfer data securely over the Web.  These protocols, particularly Secure Shell/Secure FTP, have controls to protect the integrity of data while being transported, and to identify when someone tries to alter data in real-time during transit.

This doesn’t address encryption at rest.  This was marked as addressable in 45 CFR 164.312 (e)(2)(ii), which requires organizations to encrypt data as appropriate.  Many organizations thought that addressable means that they would address it later.  Further clarifications from the Office For Civil Rights (OCR) illustrated that organizations need a plan for encrypting data at rest.  Advanced Encryption Standard (AES) in 128 or 256-bit key lengths from multiple storage vendors was used here to enable that protection.  Microsoft’s BitLocker and the multitude of numerous Windows, Linux, UNIX, and SAN file systems also provide that level of support.

This got us to a point where we could interchange data between organizations securely.  However, it does not scale to the levels we need to support a large number of patients.  This is where OAuth2, defined in standard RFC 6749, and supported by the Internet Engineering Task Force (IETF) comes in.  This supports a standard authentication format that applications can use to identify users properly.  This is a standard numerous web sites and applications use now.  As it’s an RFC and IETF standard, it’s free for anyone to develop against and use.

Now that we know who is accessing the data, we need to make sure that the data itself has not been altered.  TLS only protects data in transit.  We need to use FHIR functions such as IntegrityCheckAlgorithm to make sure the data we send over has been not been altered.  FHIR uses a 256-bit Secure Hash Algorithm (SHA-256) to compute the cryptographic checksums to validate and verify that data has not been altered.  Other technologies, such as databases, can be used to store values of generated results.  Double-checking the value a patient has of their data with the stored results of what was generated by an EMR can help reduce the uncertainty of accepting outside data.

This brings us to the most important part.  We are opening up our APIs and networks to people other than trusted parties that have Business Associate Agreements or other legal paperwork that lay out the rules of engagement.  We are allowing people to connect using their applications and download their data.  We have to be very careful about how we manage this.  We are going to go through some examples here.

First, do not rely upon an API gateway or “appliance” to handle all of your API security.  Most are not going to work that well, and they can be bypassed easily.  One of my friends, Alissa Valentina Knight, a very gifted hacker, is often hired for API penetration test engagements in the financial sector.  On the tests she conducts, these products fail more than they succeed.  Despite the promises of the vendors, they will not normally meet customer needs as a primary line of defense.  I expect numerous emails from vendors for writing this claiming otherwise and asking for 30 minutes of my time to prove it.   Reliance upon a product to do your security for you or your vendor of choice is going to leave you in an actionable position.  We owe our patients better than that.

When your organization or, more likely, one working on your behalf, is developing or licensing APIs, you need to make sure you have a robust DevSecOps program that encompasses continual testing, static and dynamic code analysis, and fuzzing.  Fuzzing is when you throw input at a program or API designed to break it.  Due to the numerous developers who will be developing applications designed to use these APIs to interface with your systems to download patient data, there will be cases where unexpected inputs will cause issues.  A robust DevSecOps program at your organization, or more likely, your vendor, will help address this.  No gateway or product will address these issues on their own.

You also need to make sure you keep systems current and patched.  It only took one unpatched component in a web server implementation to give the hackers that caused the massive Equifax data breach what they needed.  With previous data interchange implementations, you could hide your systems behind a VPN or firewall and the world would not see you were vulnerable.  Now, everyone can see.  This means you have to be vigilant about patching and updating, much more so than in the past.  The previous attitudes are not going to work if you want to continue to build trust with your customers.  You need to evolve and make sure your organization is structured to provide a higher level of support.

In addition, you should restrict access from the FHIR gateways used to provide patients access to their data to only the minimum necessary ports and protocols needed to accomplish the task.  Put this in your DMZ network.  Do not give them full network access.  You want to make sure you are using minimum necessary communication to reduce the risk to your internal network and the rest of your patient data.  A data breach here can add significant risks.

This CURES Act Final Rule represents a significant change from the days of HL7.  It has the promise of enabling patients to more securely retrieve and use their own medical records.  This can fulfill the original intent and promise of HIPAA.  However, for organizations to do so and not put patients at further risk, we need to evolve.  Leveraging standard authentication methods such as OAuth2, using good DevSecOps processes focused on code analysis and fuzzing, keeping systems current, and restricting network access can help.  Not relying on the magic boxes that get pushed in this space as a primary security system will help develop good processes and methods, so you don’t rely upon tools or magic boxes you know nothing about.  This will help you to avoid being the next data breach victim used as an example to others.  We can do a better job securing FHIR, and hopefully this gives you the information you need to start transforming for the benefit of many.

About the author

Mitch Parker, CISO

Mitchell Parker, MBA, CISSP, is the CISO, at IU Health. Mitch has eleven years’ experience in this role, having established effective organization-wide programs at multiple organizations. He is responsible for providing policy and governance oversight and research, third-party vendor guidance, proactive vulnerability research and threat modeling services, payment card and financial systems security, and security research to IU Health and IU School of Medicine. In this role, Mitch collaborates across the organization and with multiple third parties to improve the people, processes, and technologies used to facilitate security and privacy for the benefit of IU Health’s patients and team members.

   

Categories