Introduction

Healthtech has been struggling with integrations for years. Some have found a solution to transfer data between systems with RPA (Robotic Process Automation). However, is RPA always the best choice? Or should you rather go with API?

In this blog post, we'll discuss the advantages and disadvantages of RPA and API integrations in healthtech.

RPA: A Closer Look

As someone who had previous experience building RPA from scratch, I can clearly see some benefits of that approach.
RPA can be a good choice in the following scenarios:

• when there is no native automation or API available at all

• when the API is limited and does not fully support your specific use-case

However, there are also reasons why you might not want to use RPA:

• RPA is relatively slow. It relies on clicks, form inputs, page navigations, which are typically slower than having everything sent in one API request

• RPA is error-prone. When looking for elements to click on, or enter data to, it uses internal identifiers of those elements (e.g. HTML ID or class), meaning it can easily break if developers update UI of the target system

• RPA can be costly. It's a separate field of tech, and typically, you need dedicated developers as opposed to integrations.

  (Quick check on LinkedIn gives 85000 professionals having “RPA” in their profiles vs almost 2 million of those having “API”. Take that scarcity into account!)

As a side note, it's worth saying that web-based and web-oriented RPA products are faster and more stable than traditional ones. However, they still come with the same limitations above.

API: A Better Solution?

When possible, it's better to use API over RPA, as more reliable and faster option for integrations. Here are some key points to consider:

• Faster and more efficient: as opposed to RPA, where you’d have to simulate multiple data fields filled out and buttons clicked, in API you can handle pretty much everything in a single request.

• More reliable: API integrations are reliable as they are based on the endpoints and data models vs interface elements in RPA. Breaking changes to data model are typically expected to happen less frequently, than to the UI. Besides, API integrations also commonly adopt versioning, to help you keep your integrations operating.

• Standardized data: API integrations enable standardizations. For example, FHIR API integrations in healthtech will yield the (almost) same results for different EHRs. UIs, however, may differ significantly - doctors using Cerner will see different interfaces to those doctors using Epic see. Your RPA solutions would have to accommodate for that as well.

• Easier to maintain: deriving from the points above, API integrations are easier to maintain, reducing the workload put on your development team. They are typically better documented, with clear instructions on usage, where you don’t have to figure out, which fields and buttons to click on and in which order, when to wait for a loading screen, etc.

• Cost-effective: with less maintenance and more resources available, APIs are also generally more cost-effective, than RPA. You don't need a dedicated team of developers to maintain the system, as API integration is considered to be a common knowledge among majority of professionals.

Conclusion

I would say, if you have options to chose from, your automation priority should be as following:

native automation → API → RPA → manual work

Both RPA and API integrations have their advantages and disadvantages. As a short recap:

• RPA is an excellent choice when no other option is available or API is limited, but can be slow, error-prone, and most likely is expensive

• API integrations are faster, more reliable, easier to maintain, and more cost-effective, when available

• In healthtech, it's essential to prioritize native automation and API integrations over RPA, so you save time, money, and headaches in the long run.

If you're looking for an API integration solution in healthtech - check what we do at Leyr, give it a try in our free public Sandbox or reach out to discuss more!