Logo
  • Our Approach
  • Providers
    • Release of Information
  • Payers
    • Chart Retrieval
  • Partners
Request a Demo
Logo Request a Demo
  • Our Approach
  • Providers
    • Release of Information
  • Payers
    • Chart Retrieval
  • Partners
  • Developer Portal
  • Resources
  • Careers
  • Contact

APIs: Why they Matter and Why Moxe’s is Different

Moxe Health: 06.03.2022 4:00 PM
APIHITinteroperabilityPrivacy

Talk of Application Programming Interfaces—APIs for short—is everywhere in the tech and health tech space. Use of APIs has surged in the past decade, and many of the most popular apps—apps that you probably have on your phone—rely on many APIs to actually run.

While APIs have become an integral part of how we do business, socialize, and gather information in the digital age, many of us don’t understand how they work and why they matter.

It’s my hope that this blog will shed some light on the importance of APIs and what makes Moxe’s API different.

The basics of APIs

Essentially, an API is a tool that allows applications/programs to talk to each other, behind the scenes, without a person involved. At a prior company I worked for, we had a running joke about how API actually stood for “A/another person involved.” Unfortunately, manual interference in something that could be entirely digital happens frequently in healthcare. Why invest all the time, effort, and money into EHRs and other technologies if we don’t take full advantage of them?

But, back on track: APIs have strict specifications that drive how the two or more applications using them share information and communicate with each other. APIs allow developers to make updates, changes, and enhancements without disrupting the ability of applications to talk to each other.

When you open an app on your phone, for example, APIs retrieve the information you see in that app. You don’t see or interact with the APIs, but the app you’re using leverages the APIs to deliver its functionality to you. So, you can think of an API like an invisible intermediary who works hard behind the scenes to facilitate communication as you swipe right, or left , in your favorite dating app.

In short, APIs act as a communication bridge between two or more applications, allowing them to communicate and work together in a structured, consistent manner.

Why APIs matter in healthcare

Well-designed APIs are an integral part of optimizing how, when, and what data is shared in healthcare so that patients receive the best care possible. Well-designed APIs also enhance patient access to their own health information.

At Moxe, we know that smart data sharing is essential to informing clinicians, payers, and patients so that patients get the right care at the right time. We also know that smarter data sharing leads to more affordable healthcare.

APIs have started to give patients access to more of their health information—information they have a right to possess and understand. The underlying thesis is that patient access to medical information can benefit both doctors and patients, as it gives them a better opportunity to communicate and helps patients better understand—and manage—their health conditions.

These APIs require patients to consent to an application retrieving their information. When patients consent to an application retrieving their information, they could also give that application rights to use or sell their data, which is not only unnecessary, but also potentially dangerous. The importance of data security and safeguarding patient privacy during clinical data exchange is a topic for another blog post, but it’s important to be aware that there are risks involved when patients consent to an application retrieving their health data.

All APIs are not created equally

When talking about APIs in healthcare, FHIR (Fast Healthcare Interoperability Resources) are all the rage. Not all FHIR APIs, however, are the same. In fact, there are now three versions of FHIR out there in the wild that are used by various apps/programs.

Healthcare APIs have been largely built around how the data they retrieve can be used in patient care. Within FHIR, for example, there are APIs for getting diagnoses, allergies, and medications. There isn’t a FHIR standard, however, for getting all data around a specific use case or data need—for example, retrieving a small piece of the patient’s chart to review the anesthesia record from a recent surgery.

APIs can be powerful and solve for very important use cases, but it’s important to fully understand how those APIs do things such as authenticate, secure data as it flies across the internet, process and store data long-term, and when it’s okay for those APIs to actually grab data. That last one is pretty important.

Why Moxe’s API is Different

Moxe’s API is different from typical healthcare APIs. It is built with the intention of enabling data sharing between providers and payers for a wide range of payment and operations use cases.

If you’re a health plan and send a request with a use case and target and let it go, Moxe’s API takes that request and essentially packages together a number of integration tools such as FHIR, HL7v2, and X12, (and others!) to deliver:

  1. Only the right data (we see you, HIPAA!)

  2. In the right format (one that is actually usable)

  3. In the right timeframe (so that is meaningful and actionable).

Moxe’s API creates a consistent user experience based on the specific business case for which the data is being transmitted.

Over the next few years, I expect more companies to take this bundling approach, which will accelerate how fast we can solve the key problems that weigh down our healthcare system. We don’t need more tools; we need real solutions to real business problems. If you get pulled into conversations on APIs, my advice is to be careful and ensure you involve your security and privacy teams. And, make sure the API doesn’t stand for “A Person Involved.”

To see how Moxe’s APIs work in the real world, check out a recent case study.{{cta(‘bae43854-80ce-43f9-839b-fec4958a3a7c’,’justifycenter’)}}

About the author:

Mike Arce is Moxe’s Chief Administrative Officer, bringing extensive healthcare IT experience, a strong technical background, health system expertise, and a desire to deliver products that simplify healthcare and drive better outcomes for all healthcare stakeholders.

Logo

Keep up with the latest in interoperability.

  • Our Approach
  • Providers
  • Payers
  • Partners
  • Contact
  • Resources
  • Careers
  • Developer Portal

608.669.9176
info@MoxeHealth.com

228 North Henry St., Ste. #300
Madison, WI 53703

10 Post Office Sq., Ste. 501
Boston, MA 02109

© 2025 Moxe Health

Terms of Use Privacy policy Technology Governing Agreement
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage {vendor_count} vendors Read more about these purposes
View preferences
{title} {title} {title}