A call to action and best practices for API governance, access, and conformance with evolving standards.
The Need for Data Exchange & Constant Tension
Healthcare, like other regulated industries, depends on strict data governance due to the sensitive nature of the core focus of the work – our health. Healthcare organizations see, retain, and leverage both our incredibly personal health data and our financial data related to credit, bills, payments, and coverage eligibility.
However, no single healthcare organization holds all of the data necessary to treat all patients, and interoperability and data exchange are foundational to providing effective care to each patient.
Healthcare data exchange is constantly under tension. Commercial-driven and care-driven leaders are constantly pushing for more data sharing, but data sharing policies and terms of use pull back to ensure healthcare actors abide by “minimum necessary” standards. Amid this ongoing state of tension, the industry must establish and enforce robust data exchange governance and conformance practices to safeguard our most sensitive information while unlocking the full value of accessible data.
In the sections that follow, we explore why conformance matters now more than ever, how the transition to FHIR APIs impacts governance, and the practical steps organizations can take from API visibility to flexible gateway enforcement to progress with confidence in this evolving landscape.
Why Conformance and Governance
The Need for Conformance
Our healthcare system requires accessible and usable health data to be shared across entities. Healthcare is a network of networks, and patients are not often exclusively getting care from one specific business entity. Their coverage, geographic location, and schedule largely determine how, when, and where they access care. People often move between locations, so their health data must be accessible and shared across organizations and regions. This helps avoid duplicate treatments, medication conflicts, allergic reactions, and ensures a more complete view of a patient’s health. This also extends to the billing and administrative side of healthcare, where payers (insurance companies) need to share eligibility, coverage, payment, billing, and adjudication data with providers and patients. Payers also need to track in-network and out-of-network coverage and spend, accumulators, and other measurements of utilization.
Healthcare requires many parties interacting with sensitive data in both synchronous and asynchronous ways. Without standards of exchange, this would be incredibly difficult. Healthcare organizations have leveraged integration standards for decades, primarily HL7 and x12 for clinical and financial data via EDI transactions. These standards, still providing data exchange today, however, are loose standards, where each point-to-point integration retains idiosyncratic details of the sender and receiver. For example, while HL7 integrations between two health systems might seem standardized, each system’s unique implementation choices often lead to significant, or sometimes subtle, differences in how the interfaces work.
The API Transition and Shift to FHIR
APIs provide a different approach to data exchange in healthcare, but can fall victim to the same issues with many point-to-point integrations: requiring custom development and maintenance. Switching costs are high when developers commit their architecture to a single partner’s API format, so there is pressure to shift API integrations to a conforming standard.
While much of healthcare depends on legacy EDI exchange formats, they are no longer in vogue as the primary method for new integrations. APIs and API-oriented-architectures are now deployed across the healthcare continuum. APIs offer a modern developer experience, and organizations are routed to APIs by market (financial, competitive), technical (asynchronous, specificity, granular governance), and business needs (eventing and data latency, marketplaces, building networks). The expansion of API usage has fostered the need for a standard.
FHIR is the de facto standard for API-based healthcare clinical data exchange. Compliance measures impacting provider organizations (the Cures Act) and payer organizations (CMS-9115, CMS-0057) are requiring data exchange via FHIR APIs.
What this does mean: FHIR is a safe place to start for new entrants. Some organizations can now start as a FHIR-first organization, leveraging FHIR as their core data schema and database structure. There are FHIR APIs utilized across the healthcare continuum. While FHIR cannot accommodate all use-cases, it is growing in popularity. Most organizations are at least FHIR-capable or have a FHIR-facade architecture (legacy, proprietary stack that can send/receive FHIR).
What this does not mean: while FHIR is the standard, that does not mean that there is complete adoption. The FHIR data standard, to date, cannot accommodate the full complexity of healthcare data (in terms of the raw number of unique data elements). Until the FHIR schema has all elements, there will remain a need for multiple formats in parallel.
Conforming to FHIR as the Standard: Not Now, But Hopefully Soon
As API usage moves forward, organizations will continue evaluating their data and integration needs and determining which should remain in legacy formats versus in FHIR. Over time, FHIR adoption will simplify data exchange in healthcare. Once FHIR can accommodate all clinical and financial data, it should be enforced as a rigid standard (requiring organizations to adapt to the standard instead of organizations creating their own implementations of FHIR). We will hopefully see this progress as we shift from FHIR R4 to R5 and R6…
Getting to a conforming standard is helpful for many reasons: reduced barriers to entry, simpler exchange, less complicated integration, network effects as each traditional organization gets on board, and as new types of parties connect new types of data via the shared format. A standard also helps ensure governance due to the unified language and syntax of the standard.
Remember that the data exchanged are highly sensitive, and sharing it carries significant risks to organizations: financial, reputational, and related to patient safety, among others. As healthcare increases its ability to share data, updates to governance must follow.
Enforcing Access Governance
Traditionally, interfaces in healthcare (whether HL7 or x12) have been deployed using VPN tunnels and sFTP connections. These methods are functional but relatively brittle in terms of their ability to handle complex governance requirements. When describing an HL7 connection to someone new to healthcare, it is common to mention a constantly flowing pipe of water. The pipe connects the two entities, and the messages flow constantly, filing to a database in the downstream system via interface logic. These connections are system-to-system, and there is not typically granular access enforced within the integration. Instead, controls are usually enforced in the receiving system.
In terms of conformance to standards, as mentioned above, HL7 is a loose standard, with each point-to-point connection potentially having a unique configuration. Middleware and integration engines help reduce the reinvention of the wheel, but each connection remains potentially unique. At this stage, it would be incredibly difficult (if even possible) to define and enforce HL7 standards across the ecosystem.
The shift to APIs provides the ability to enforce governance for a single call. A single message, like a single drop of water flowing through the HL7 pipe, can have permissions and rules both defined and enforced. For APIs, this is typically implemented as a two-legged exchange where each party confirms the other is authorized and authenticated to send/receive data. Two-legged exchange can be configured for an endpoint (a singular API), but can still be abused, as there is no traceability to the actor (application or human) invoking the call. Two-legged permissioning is effectively a blanket hall pass to access data using an API, without specifying who uses the data in which circumstances. That additional governance lives in legal contracts, BAAs, and usage terms. It gets a little prickly, and everyone has seen articles about parties intentionally (or unintentionally) using data against their intended terms.
There is also three-legged authentication, enabling role-based-access controls, with the ability (and requirement in some cases) to enforce granular permissions for specific users to specific types of data. With three-legged authentication, a third element – a user – enters the discussion. The user has certain attributes (claims) that describe who the user is, their role at a company, their name, their email, etc. The user can also have granular permissions (scopes) attributed. Here, organizations can define which specific users can access which specific API endpoints in which specific situations. This is getting closer to the necessary governance, but the affected systems need to be able to accommodate this logic in their security and permissions configurations.
But wait, what about enforcing governance of standards? Let’s cover that now.
How do Organizations Enforce Standards?
As industry-wide compliance measures and market drivers push for a single version of FHIR, there is a clear need at the organization level for describeable, reportable, and manageable governance, but current implementations are often lacking in at least one area. This piece focuses on APIs as they are a common choice for new integrations. First, let’s squash one major assumption that is concerningly rampant in healthcare about APIs: many organizations do not have an accurate directory of their published endpoints. They assume they do, but they are often mistaken. Let’s start there:
1 – Ensuring visibility of your entire API directory
Whether due to system upgrades, new versions, mergers and acquisitions, or legacy infrastructure, many healthcare organizations do not have an accurate API directory. This is problematic as there may be APIs in production without the latest and greatest security measures that are being accessed unwatched.
An API gateway is a useful tool, but it only shows what is routed through it. API gateways cannot be the root source of truth for your full set of APIs.
Organizations must invest in a method of continuous API discovery that accommodates both east-west and north-south APIs to describe their full set of endpoints.
| Shoutout: Akamai API Security | API Security gives you full visibility into your entire API estate through continuous discovery and real-time analysis. Discover: Generate a comprehensive API inventory, including how many — and what type of — APIs you have. Test: Add security to your CI/CD pipeline, without sacrificing speed, to secure APIs before putting them into production. Detect: Identify API vulnerabilities and attacks with automated, machine-learning-fueled detection. Respond: Create advanced workflows to remediate API issues by integrating with your WAFs, SIEMs, and ITSM tools. |
| Our Thoughts: | It all has to start with visibility – we’ve met too many organizations that think their API gateway is the source of truth, but they are actually missing legacy APIs (from acquisitions, old versions) still in production and often missing their on-network (E/W) APIs. The ability to have automated, continuous API discovery is foundational – you cannot manage what you cannot measure. |
2 – Accommodating and implementing three-legged permissions
Once an organization has a comprehensive grasp of their published endpoints (of all formats) and shores up potential exposure points, it is time to focus on upleveling granular permissioning. Three-legged permissions should be a focus and a method to implement role-based access controls.
However, to implement three-legged permissions, the systems interacting must accommodate that granular level of permissions. If the system in question (an EHR, a patient portal, a telehealth platform) cannot provision security access granularly enough, organizations cannot ensure the specific access controls they need.
This may require product and development work to improve user management and security provisioning, but it is a worthwhile investment.
3 – Visibility to assess and confirm governance
Next, once granular permissions are in place, it is time to implement governance policies (technically and operationally). In addition to role-based access controls, organizations should determine what they are governing and how the policies apply to different data formats and types of exchange. Should rules be the same for HL7 and APIs? The same for legacy and FHIR APIs?
Once optimal governance is described, organizations must be able to measure, monitor, and enforce that governance. This typically involves adding steps to the software development life cycle and pre-publication review. With APIs specifically, there are common issues that breach data or break policies, such as including sensitive data in headers or not encrypting certain identifiers. But it doesn’t end with an endpoint promoted to production, organizations should also be watching and measuring actual transactions in production to ensure policies are met.
Evaluating and monitoring all APIs in production is a big ask, and healthcare organizations should aim for systematic processes to evaluate adherence to policies. What makes this trickier is that not all APIs are FHIR (yet) or any singular standard. Healthcare organizations need systematic processes to evaluate API governance, with consideration for the standard of API.
To evaluate your APIs for conformance to standards, first consider an analysis tool that reviews your entire API directory, looking for standard conformance, policy adherence, and security issues. Are the FHIR APIs aligned with policy? Are there parameters that need tuning? Have we mitigated potential SQL-injection exposures, sensitive data in headers, etc.?
Once in production, assuming your API gateway now has the full set of endpoints, you should then constantly evaluate and monitor your APIs. Look for problematic patterns, issues with certain endpoints or types of endpoints, and other indicators of abuse or poor configuration. Are our FHIR endpoints performing acceptably? Are users actually hitting the latest versions, or are “deprecated” endpoints still in production?
| Shoutout: API Context | APIContext is an advanced synthetic API testing platform for monitoring API performance, SLOs, and conformance for your critical APIs. Specific to this piece, APIContext performs conformance monitoring—including FHIR—by acting as an end user through synthetic monitoring. The advantages of APIContext’s approach is that they can get continuous feedback on API conformance, and also use test data that is not actual patient data. That means that when they find issues, no patient data is exposed. |
| Our Thoughts: | “Shift left’ can turn into quite the catchall with some types of testing, monitoring, and evaluation being difficult to handle at scale (and enforce across products, teams, and microservices). APIContext’s approach is compelling because it combines and automates two key areas of necessary testing: performance and conformance. They also straddle the deployment line, providing useful feedback for both developers and devops. |
4 – Flexible gateways to enforce governance
Finally, organizations may land in a place where they have more complicated needs than current tools can accommodate. Many organizations exchanging data with APIs have different customer or partner types and sizes. They may work with hundreds of small partners and a few larger partners. While traditional API gateways can accommodate three-legged access, there are not often too many more configuration options available. Business needs can quickly go beyond rate limits and provisioning access to specific APIs. Instead of publishing different versions of APIs for different users, how else could you address this?
There are entirely configurable, gitOps native API gateways that break our assumptions about how the tool should work. Instead of relying on a brittle, inflexible gateway, what if you could create custom policies by endpoint by user within the gateway and enforce them systematically?
| Shoutout: Zuplo | Zuplo is the most programmable API gateway that has unlimited extensibility and allows you to build exactly what you need. Zuplo is a gitops native, fully configurable, and programmable API gateway that allows custom policy creation and enforcement. |
| Our Thoughts: | API Gateways are such an important element of managing and governing your APIs, but they have historically been inflexible. With each organization, endpoint, and use case potentially unique, it just makes sense to leverage a programmable API gateway. Additionally, creating your own policies is exciting and ripe with possibilities. |
Progressing with confidence, conformance, and governance
As the industry progresses beyond solving the data access problem and focusing on data conformance and governance, we will hopefully see a comprehensive health data schema in FHIR R5 or R6 (this is a very hopeful take). However, in the interim at the organizational level, it is reassuring to know that options exist today for measuring and enforcing governance with API access and standards.
For organizations worried about API governance, standards conformance, or other related issues, please reach out to our team at Untangle Health™. We’ve worked across complex vendor ecosystems and infrastructure challenges to help healthcare organizations ensure secure, compliant, and scalable exchange. We’d love to hear from you, and we are always trying to Untangle Healthcare by ensuring the secure exchange of our most sensitive information. Just to be clear, this isn’t a paid promotion. Through our work, we’ve become experts in navigating and combining various vendors within enterprise tech stacks and health data infrastructure. We’re simply highlighting the combinations that solve real, pressing problems. This one felt like a natural place to start.
