Building a foundation for application integrations

In today’s world of healthcare regulatory changes, the idea of healthcare organizations using one application to rule them all is a thing of the past. Today, healthcare organizations are constantly striving to increase their bottom line by reducing their costs and creating more predictive behavior in their business through big data analytics, artificial intelligence (AI), automated workflow processes, and specialized cloud-based applications. These moves can be a daunting task considering most companies have been using the same healthcare platforms (adjudication, underwriting, claims processing) for years. Moving away from these long running applications is a daunting task that could bankrupt even the largest of companies. However, not moving to take advantage of new technologies can be just as detrimental to your business.


Don’t fret. There is a winning scenario for healthcare organizations that choose the right technology partners. The ease of integration has dramatically improved over the years even with the oldest of proprietary systems. The level of sophistication now being provided via rich APIs can make even the most daunting integrations seem like child’s play. There are some points you should consider when choosing your technology partner to examine how powerful their APIs are for your future business.


Eat your own dog food
Every good application will provide at least a minimal set of APIs. The great applications will not only expose those APIs for you to consume in other Line of Business applications (LOBs), but they will also use and call those exact same APIs from within their own User Interface (UI). I call this “Eating Your Own Dog Food”. This is a very important architectural design that should matter to any software buyer. Using the same API set they are exposing to their customers causes software developers to think about what the customer may ask for. It also guarantees frequent software updates to the API set and guarantees the user that the API won’t be going away anytime soon. If you are considering a software vendor that is not “eating their own dog food” you should consider finding a different product.


Write once use forever
Some vendors will tell you they solve the integration checkbox by providing web services. For the purposes of this article you can use web services and APIs interchangeably. The one thing you want to dig into is what protocol is the web service based upon? The more mature systems are going to base their APIs on RESTful Web Services and or APIs. RESTful uses the HTTP protocol and is very simple and light weight. By being RESTful based you can write simple functions that can be used over and over across multiple integrations. This type of interaction allows systems to be more loosely coupled and less brittle to the sands of time.


You should not have to be a programmer to try it out
There are a lot of tools out there today to provide even the most novice programmers with the ability to “try” the APIs out. Any software company should be able to show you their APIs in real time and demonstrate for you how they work. At Ringmaster Technologies we have documented and standardized all of our APIs using a tool called Swagger. This integration into our application allows for a graphical user interface with the APIs. It also provides documentation to the integrator on what the sample request and response messages are. This level of documentation and sophistication drastically reduces the time it takes to complete an integration with other systems. Here are a couple of screen shots showing the simplicity of the design.

Here is a listing of all the different requests you can make about an organization within our system.

Here is a simple request form in a graphical user interface you can use to “try” the API to see the sample requests and responses.

At RMT integrations and ease of access with other applications are a pillar of our software architecture. We not only publish APIs for our customers to use, we also eat our own dog food and use those exact same APIs within our own User Interface. Solutions that lack APIs will create data silos across your applications and an inability to integrate with your existing solutions.