From APIs to Microservices: Workflow Orchestration and Choreography Across Healthcare Organizations

[This post is part of a series I am writing as a HIMSS17 Social Media Ambassador (four years in a row!) in the run up to HIMSS17, in Orlando, February 19-23. Stop by and meet me at the first ever HIMSS Makerspace, booth 7785 in the Innovation Zone!]

“Begin with the End in Mind” — Stephen Covey

“APIs have existed for over 50 years” — Chris Busse ( on Twitter)

(What’s an API? See below.)

What is the next horizon for APIs in healthcare?

The next horizon in APIs in healthcare are “microservices.” You can think of microservices as the logical continued evolution from software libraries, service-oriented architectures, and APIs (Application Programming Interfaces). APIs have been around for many years. Most EHRs and health IT systems already use APIs in some fashion. Ten years ago as an EHR programmer I “consumed” web APIs, submitting lists of drugs and getting back interactions. I’ve used non-Web APIs since at least the eighties, seventies if you count FORTRAN libraries. Microservices also remind me of RPCs and RMIs (Remote Procedures and Method Invocation) I used in the early nineties. That style of programming faded (tied too tightly to specific platforms) with the advent of the Internet (more interoperable), but now seems (to me) be coming back as microservices, which feel like interoperable remote procedure calls and Java method invocations to me. BTW, I’d love to hear from someone more knowledgable about the similarities and differences among REST, RPCs, RMIs, APIs, and microservices to help sharpen or dissuade my intuition!

apps-to-microservices

On the left, in the above diagram, we have “monolithic applications,” applications made from modules that cannot exist independently from the application. The classic, torn-from-the-headline, example of a monolithic application in healthcare is the electronic health record (EHR). Healthcare is adding APIs to access data inside EHRs. FHIR (Fast Healthcare Interoperability Resources) is best known, but many other non-FHIR APIs and related technologies (such as API creation and management software) are springing into existence, relative to both EHR and non-EHR health IT systems.

On the right are process-aware microservices. Two key process-aware concepts are orchestration (central “conductor”) and choreography (distributed, peer-to-peer. There is an excellent discussion of microservice orchestration versus choreography on Stack Overflow. Also see my post FHIR, Process-Aware Orchestration & Choreography, and Task & Workflow Interoperability). EHRs, health IT systems, and API consuming apps are still relatively “workflow-oblivious.” Fortunately, the API path toward microservices also moves toward “process-awareness.”

All those microservices? Where will they be? Everywhere. Anywhere. It won’t matter. From a task workflow interoperability perspective, process-awareness is, essentially, being virtualized. This fundamental difference from older styles of programming that fail to abstract sufficiently away from health organizational organizational boundaries will be essential for achieving what I call healthcare pragmatic interoperability. Take a look at this series of diagrams from the Jolie (“The first language for Microservices”) website.

jolie-dist

How will we get from our current monolithic health information (solar) systems, surrounded by planetary apps, to to a virtual swarm of virtual microservices? The four activities we will see, between now and then, are…

  • Connecting
  • Coordinating
  • Refactoring
  • Replacing

We need to connect and coordinate an extraordinary variety of apps. And we need to (partially) disconnect and coordinate modules, corresponding to healthcare clinical and management tasks and goals within today’s monolithic applications, especially electronic health records! These monolithic applications will (eventually) be refactored into more independent modules, or be replaced with more modular systems. As disparate apps become connected and coordinated modules, and as monoliths divide into less connected modules, the distinction between modular apps and application modules will gradually disappear.

Lets flash forward to a future in which APIs evolve into microservices. The same forces that drove creating libraries and APIs will also drive creation of micro service architecture.

Does “modular services, each supporting a business goal” sound familiar? It is a step in a business, or often in healthcare, a clinical workflow. We may call them steps, activities, goals, or even experiences. They can even be entire workflows, since one workflow may be merely a step in another workflow. Workflows will be made up of microservices. Some microservices will will drive, and be driven by, user behavior and experience. Some microservices will do stuff behind the scenes, automatically. Some microservices will orchestrate other microservices. Other microservices will interact like jazz musicians or dancers, each following its own set of rules, but working dynamically together to achieve common goals.

“The key system characteristics for microservices are:

  • Flexibility. A system is able to keep up with the ever-changing business environment and is able to support all modifications that is necessary for an organisation to stay competitive on the market
  • Modularity. A system is composed of isolated components where each component contributes to the overall system behaviour rather than having a single component that offers full functionality
  • Evolution. A system should stay maintainable while constantly evolving and adding new features” (Microservices: yesterday, today, and tomorrow)

From libraries and APIs through microservices, software architecture massively influences a wide variety of classic software issues: availability, reliability, maintainability, performance, security, and testability. Every industry — education, telecommunications, finance, healthcare, and so on — is unique in its own way. But at a 30,000 foot level, the evolutionary stages of how we create useful software are the same. Healthcare is just a bit behind some of these other industries. And healthcare APIs are an important step toward catching up with our outside world.

By the way, what’s an “API” and “library”? Here you go. I did’t want to start with these embedded tweets, as that might have interfered with the initial readability of this post. However, if you’ve got this far… 🙂

Let’s continue, in reverse order, through the “Exploring APIs in Healthcare” tweetchat questions.

How are APIs being used to improve patient outcomes?

Technically, since APIs have been around for decades, leveraged by virtually every EHR and health IT system, everything good that health IT has achieved, to improve patient outcomes, has leveraged APIs.

More topical, new FHIR-based apps communicating with EHRs, both mobile and plugged into EHR workflows, are being announced almost weekly. However, I am most interested in non-FHIR-based apps. Why? Take a look at this tweet, from the recent Medical Innovation Summit in Cleveland (my trip report). I am reporting the answer from a panel of FHIR thought leaders in response to the question, what if FHIR doesn’t happen to do what you need it to do?

While I am a fan of FHIR, I am even more a fan of its bringing remote-call API technology into healthcare. Don’t wait for FHIR to deliver bi-directional connectivity and coordination for the data and workflows concerning you. The best of both, of FHIR and non-FHIR, APIs and API technology will lead our way toward sophisticated, orchestrated and choreographed, microservice architectures.

What are the concerns you have about partnering with an API vendor/endpoint?

I know there are many potential concerns regarding APIs, from security to latency to API vendor stability. However, as a programmer, my main concern is API usability. How easy is an API to use? The harder it is to use, the more work it is for me. Remember Dr. Dobbs? It was the original programmer’s programming magazine. In 2004 it published an article titled Measuring API Usability. It wasn’t about RESTful APIs, about which there is so much interest in health IT, but it is still remarkably relevant.

My favorite API usability dimensions are domain correspondence (if you understand the domain, say, clinical documentation, how much will that help you understand the API?), progressive evaluation (how much code do you have to write before you can execute and see if you are on the right track?), and work-step unit (how much work does each API call accomplish). Of the three, domain correspondence is most important to me. It’s a lot like usability in user interfaces, where user knowledge of their domain is enough to guide their interactions with a user interface. If you know anything about workflow technology, in which engines execute models of domain workflow, you can see why these are my favorite dimensions of API usability.

T3: What does a good healthcare API Partner Program include? #AskAvaility

How easy the API is to use? For an example see my previous post, How Easy Is It To Integrate Availity APIs Into Your Payer-Provider Workflow? Very!

Make the programmer in me want to use your API. (In this vein, checkout Why no one wants to use your API).

  • Is it easy to get started?
  • Give me great error messages!
  • Make it easy for me to ask your developers questions.
  • I want an SDK (Software Developers Kit: especially working, well-documented examples, in all my favorite languages, from which I can steal code snippets)
  • Explain what each API does, using examples, preferably working (see above)
  • Invite me into an active community of developers using your API
  • Show me pictures of cute raccoons (I had one as a pet when I was a kid)

For more guidance, see this article, A Quick Look At The Leading API Partner Programs, by (my favorite API tweeter and blogger).

What functionality/capabilities would you like to see in API’s that you’re not seeing? If you haven’t used API’s why not?

The functionalities I am not yet seeing in health IT are workflow APIs. Essentially, we need easy-to-spin-up workflow services, in the cloud, which can be used to coordinate mobile apps and application modules, to combine them into automatic, transparent, flexible, and systematically improvable workflows, within and across healthcare organizational boundaries. Future versions of FHIR may provide API hooks to drive and respond to such cloud-based process-aware workflow engines (see my Health IT Workflow Integration: Whither FHIR? (Fast Healthcare Interoperability Resources). Many modern BPM suites (Business Process Management) already offer APIs into their workflow design and engine guts. This is what I wrote in, Healthcare IT News, in 2015.

“Converse to healthcare interface engines, BPM suites are adding adaptors and plugins and means to manage data flows. Abilities to consume a variety of web services (such as FHIR-based APIs) have been standard functionality for years. A particularly relevant manifestation is data virtualization. Instead of defining workflows directly against a heterogeneous mixture of data systems, the data in harmonized and made visible to the workflows being designed and executed. In turn, some of these systems are exposing not just their internal task, task list, and workflow state, but also this harmonized data. So you can see that healthcare interface engines and business process management suites are, in a sense, heading toward some of the same territory.

Particularly important to task and workflow interoperability is ability of workflow platforms to expose task, task list, workflow state, and related to information, to other applications via APIs (Application Programming Interfaces). If you use a third-party BPM platform (to tie together internal data sources and workflows, as many enterprises are doing), be sure to investigate whether it has both an outward-bound API for exposing data and workflows, as well as an inward-bound API for pushing data and triggering workflows. Workflow management and business process management systems will be key technologies for achieving task and workflow interoperability.

“WFM/BPM systems are often the ’spider in the web’ connecting different technologies. For example, the BPM system invokes applications to execute particular tasks, stores process-related information in a database, and integrates different legacy and web-based systems.” (Business Process Management: A Comprehensive Survey)

The key to success will be integrating data and workflow, through use of both more-or-less traditional healthcare data integration technologies, but also newer workflow management and integration technologies. You need to think about how best to create and evolve a fast, flexible, and transparent backbone of data and workflow services, on which to hang and manage current and future systems.”

Here are a bunch of related tweets. They illustrate lots of connections among workflow concepts and API concepts.

(But don’t forget to get hang in there for, or at least skip to, #AskAvaility topic T1. In addition, my postscript to this already lengthy post, about Jolie (Java Orchestration Language Interpreter Engine), the “first language for microservices”, is not to be missed!)

What are the primary challenges and issues in using API’s within the healthcare industry?

Wow! Am I finally at topic T1! And I am running out of both steam and time. So maybe this is where I need to pivot back to the #AskAvaility tweetchat, where you will surely hear about, and, I hope, suggest API challenges and issues in healthcare. However, I will give you some interesting and relevant links for homework.

Conclusion: Back to the Future!

API-ization of health IT will lead to the Workflow-ization of health IT

P.S. Here are some details about the Jolie microservices language.

I’d love to compare notes with other programmers in the health IT space. Feel free to tweet me at or contact me through this blog.

I’ve been writing microservices in Jolie, “The first language for Microservices.” (Also see Chor, the choreography programming language). Jolie stands for Java Orchestration Language Interpreter Engine and is written in Java. It’s easy to install if you have the most recent Java interpreter running on your Windows, Mac OSX, or Linux computer. (And installing Java is even easier.) I also recommend Atom a free and open source code editor. It highlights Jolie syntax and allows you to conveniently execute Jolie programs. Jolie has lots of documentation and examples. Jolie also has lots of academic papers about it, explaining microservice concepts and how Jolie implements them. Let me know if you delve into Jolie. It feels a lot like Java or C, so if you’ve programmed in them, you’d probably pick it up quickly.

I referred back to a cross-organizational workflow I diagramed in my 2009 Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable EHR Workflow (based on my 2005 HIMSS presentation EHR Workflow Management Systems in Ambulatory Care).

Here is the client code calling microservices. It illustrates three of the four most fundamental workflow patterns. Sequence, parallel split, and join.

jolie-pediatrician

Here is the command line output. Text with the plus sign (“+”) is executed “remotely,” which is to say it could just have well executed anywhere else on the Internet.

jolie-pediatrician-console

The above code is not a realistic implementation of the cross-organizational workflow I wrote about in 2005. However, it does illustrate how easy it is to implement concurrency in Jolie, a fundamental function in any workflow platform. Here are some extracts about Jolie from numerous academic papers.

JOLIE: a Java Orchestration Language Interpreter Engine

“Abstract

Service oriented computing is an emerging paradigm for programming distributed applications based on services. Services are simple software elements that supply their functionalities by exhibiting their interfaces and that can be invoked by exploiting simple communication primitives. The emerging mechanism exploited in service oriented computing for composing services –in order to provide more complex functionalities– is by means of orchestrators. An orchestrator is able to invoke and coordinate other services by exploiting typical workflow patterns such as parallel composition, sequencing and choices. Examples of orchestration languages are XLANG [5] and WS-BPEL [7]. In this paper we present JOLIE, an interpreter and engine for orchestration programs. The main novelties of JOLIE are that it provides an easy to use development environment (because it supports a more programmer friendly C/Java-like syntax instead of an XML-based syntax) and it is based on a solid mathematical underlying model (developed in previous works of the authors [2,3,4]).”

Process-aware web programming with Jolie

“Abstract

We extend the Jolie programming language to capture the native modelling of process- aware web information systems, i.e., web information systems based upon the execu- tion of business processes. Our main contribution is to offer a unifying approach for the programming of distributed architectures on the web, which can capture web servers, stateful process execution, and the composition of services via mediation. We discuss applications of this approach through a series of examples that cover, e.g., static content serving, multiparty sessions, and the evolution of web systems. Finally, we present a performance evaluation that includes a comparison of Jolie-based web systems to other frameworks and a measurement of its scalability.”

An easy way to build microRESTservices with Jolie

“Personally I am not a big supporter of REST services, but I think that a technology which aims at being a reference in the area of microservices like Jolie must have some tools for supporting REST services programming. Why? Because REST services are widely adopted and we cannot ignore such a big evidence.

Ideally, Jolie as a language is already well equipped for supporting API programming also using http, but REST approach is so deep coupled with the usage of the HTTP protocol that it introduces some strong limitations in the service programming paradigm. Which ones? The most evident one is that a REST service only exploits four basic operations: GET, POST, PUT and DELETE. The consequence of such a strong limitation on the possible actions is that the resulting programming style must provide expressiveness on data. This is why the idea of resources has been introduced in REST! Since we cannot programming actions we can only program resources.

Ok, let’s go with REST services!

…But,
…here we have a language, Jolie, that is more expressive than REST because the programmer is free to develop all the operations she wants. From a theoretical point of view, in Jolie she can program infinite actions instead of only four!”

Relative to Chor, a choreographic programming language that generates Jolie code, the PhD describing it won the 2014 best dissertation award from European Association for Programming Languages and Systems.

Chor: choreography programming language

I’ve not installed Chor (see below)…

“Chor is still a prototype, and lacks some features that may be useful for integrating its generated code with existing programs. For example, Chor is still limited to simple data structures for messages, such as strings and integers, and does not come with an integrated debugger. We are continuously working for improving Chor with common features needed in production environments, so stay tuned!”

I will!


On Periscope!

Leave a Reply