Postman and OpenAPI: Helping US States Navigate the Healthcare API Interoperability Rules

Kin Lane

June 4, 2021

Establishing the first federally regulated API precedent in the United States, the Center for Medicaid and Medicare Services (CMS) has two new rules requiring states to operate a compliant Fast Healthcare Interoperability Resource (FHIR) API when doing business with the federal government around Medicare and Medicaid.

With Medicare and Medicaid together representing 37% of the total national healthcare expenditure, there is a massive opportunity for publishing healthcare APIs. However, this also presents a challenge for healthcare providers who may not fully grasp why APIs matter in the first place, let alone how to effectively meet the needs of developers who will be putting APIs to work in healthcare applications.

As states in the US move to comply with the two recent CMS rules—the Interoperability and Patient Access Final Rule and the Interoperability and Prior Authorization Proposed Rule—the Postman Open Technologies team has been talking with the Colorado Digital Service and other stakeholders about the challenges healthcare providers are facing when it comes to delivering API infrastructure that complies with federal healthcare regulations.

As we listened to Colorado Digital Services and the other stakeholders during the rollout of the healthcare API in Colorado, we heard echoes of other conversations we’ve had with enterprise organizations regarding how APIs impact their own business sector. For an enterprise organization in 2021, there isn’t much question about whether or not you should be doing APIs; the concern is always around how you can do them more effectively. But in healthcare, the stakes are much higher because you have to be compliant with strict government rules—not to mention that the health of real-world patients is on the line with each API call being made. Most enterprise organizations are seeking to optimize how they design, deliver, and operate APIs, but the healthcare providers who are expected to deliver APIs across all 50 states also possess very little experience delivering modern web API experiences or providing what third-party developers need to be successful when it comes to delivering web and mobile applications. This is where Postman can help.

While we at Postman aren’t experts in healthcare, we are experts in APIs and in making sure developers have what they need when it comes to publishing and consuming APIs. So now we’d like to help Colorado and all other states achieve compliance with the CMS rules. With over 17 million developers using Postman, it’s likely that developers within healthcare companies are already putting our API platform to work—now we want to help better frame the conversation for healthcare providers who are looking to not just meet, but exceed the expectations of the CMS regulations.

Why OpenAPI is essential for supporting developers building FHIR-compliant APIs

Postman empathizes with the challenges that healthcare providers face when it comes to meeting the needs of third-party healthcare developers and integrators. We have spent years working to understand and deliver the documentation, debugging, troubleshooting, and other tooling developers need to be successful each day. Our advice for healthcare providers who are delivering FHIR-compliant APIs, and who are looking to meet the needs of developers, is to just focus on delivering the most performant, reliable, compliant FHIR API you can, and then lean on the OpenAPI (formerly known as Swagger) definition for the FHIR standard to meet the needs of third-party developers. OpenAPI is an open source specification for describing the surface area of any API across any business sector, and the Health Level 7 Fast Healthcare Interoperability Resources (HL7 FHIR) working group has also adopted the specification to describe any FHIR-compliant API.

This machine-readable API definition is essential for healthcare providers when it comes to supporting the needs of developers because it has become the baseline that developers expect for powering not just documentation, but also nearly every other stop along the API lifecycle. We advise healthcare providers to stick to delivering the best possible healthcare they can while delivering the API, and let the FHIR OpenAPI help do the rest. Here’s how it helps:

• Documentation: OpenAPI is the foundation for how up-to-date and interactive API documentation is provided for developers today.
• Examples: OpenAPI allows for examples of each API request and response, helping developers understand what is possible.
• Mock Servers: OpenAPI allows for sandboxes and mocked representations of a FHIR API to be generated and used for development.
• Code Generation: OpenAPI provides the details needed to generate client code in every programming language developers use.
• Testing: OpenAPI provides the scaffolding in which contract, integration, and other types of testing can be run and automated.
• Security: OpenAPI provides the landscape map needed to scan, test, and certify the security of our healthcare API infrastructure.
• Compliance: OpenAPI is how you certify that an API is indeed FHIR-compliant and is meeting the requirements of the CMS rules.
• Monitoring: OpenAPI is used to generate and manage scheduled monitoring of our API infrastructure from many different regions.
• Collaboration: OpenAPI allows for communication, sharing, and collaboration around the details of what each API does for developers.
• Education: OpenAPI is used to deliver training and workspaces that help ensure developers possess the education required for success.

OpenAPI isn’t just central to how Postman meets the needs of its 17 million developers, it’s how leading API providers like Salesforce, Microsoft, Twitter, Twilio, Stripe, and others are supporting their developer ecosystems. It is how industry standards like PSD2 for banking, OpenTravel for airlines and hotels, CIECA for automobiles, as well as FHIR for healthcare are being defined and put to work standardizing APIs within their respective industries.

Healthcare providers looking to be compliant with CMS rules regarding healthcare APIs should not have to understand all of the technical details of the OpenAPI specification, but they should be aware of the specification and the role it plays when it comes to meeting the needs of third-party developers and system integrators, then build on the hard work of the HL7 FHIR working group in their use of the API specification.

Helping healthcare providers achieve compliance with the CMS interoperability rules

At Postman, we see APIs as a journey. We work with enterprise organizations who are just starting that journey and those who are leading the API conversation in almost every business sector. OpenAPI is essential to those who are just getting started—like many in the healthcare industry—as it helps provide a common vocabulary for describing what an API does and helps address the biggest pain point for developers by providing up to date documentation. OpenAPI is also essential for those who are further along in their journey, as it helps reduce friction for API consumers when it comes to onboarding while increasing the reliability and velocity of development by testing, performance, security, and ultimately certifying and governing compliance.

To better understand how OpenAPI applies to the healthcare FHIR API conversation, we recommend taking a look at our FHIR API specification public workspace in Postman, where you can fork, mock, document, and interact with the healthcare API standard in a safe public space—no personal healthcare information (PHI) involved.

Then, to see the impact Postman and the FHIR specification are making across the industry, explore the Postman Public API Network for other healthcare, FHIR, and related API implementations that show how developers are putting Postman and OpenAPI to work. They are making healthcare systems more interoperable and ensuring that the applications patients depend on to navigate their healthcare experience have the necessary access to patient information. We are starting to experience the future of healthcare API discovery, and how OpenAPI can make healthcare APIs more visible and useful for developers and non-developers—all so that we can move closer to achieving the intent behind the CMS healthcare API rules out of Washington D.C.