Moving From ChuckWebster Dot Com to Wareflo Dot Com

I’ve moved my blog from to (@wareFLO being my Twitter handle). I took the opportunity to reorganize the over 650 posts I’ve made since 2009 (including 400 plus draft posts I’ve apparently not completed!). This blog will stick around for awhile, mostly so folks landing here can then go to

Hope you have a wonderful 2017!

@wareFLO On Periscope!


Posted in social-media | Leave a comment

My Foreword and Chapter in Business Process Management in Healthcare, Second Edition

(Excuse my mug! It’s my current @wareFLO Twitter avatar.)


I am delighted to write the foreword to BPM in Healthcare. Forewords traditionally deal with genesis and scope. I’ll tell you why I, an emissary from the medical informatics and health IT community, traveled to another land, that of Business Process Management (BPM). I hope to convince you that the sky is the limit when it comes to the potential scope of BPM in healthcare. And, finally, I assure you this is the right book to start you on your own exciting path to healthcare workflow technology self-discovery.

I first wrote about “Business Process Management” (BPM) in a 2004 health IT conference proceedings paper entitled EHR Workflow Management Systems: Essentials, History, Healthcare. But I’d been writing about workflow systems in healthcare since 1995. From the Journal of Subacute Care:


In 2004 I applied the Workflow Management Coalition’s ( Workflow Reference Model terminology to an Electronic Health Record (EHR) ambulatory patient encounter. (The Workflow Reference Model itself dates from 1994.)


I attended my first BPM conference in 2010 (BPM in Government, which had a healthcare track). At that and many subsequent BPM (and Case Management) conferences I met many of the BPM experts and workflow professionals who co-authored many of the Future Strategies’ publications currently sitting on my own bookshelf. In particular, I’d like to thank Keith Swenson, (My Sandbox, Your Sandbox, in this volume) for answering my incessant questions and welcoming health IT colleagues to BPM venues over the years. Eventually I even became a judge in the annual BPM and Case Management excellence awards.

That’s where BPM in Healthcare comes from in my personal journey. But where is BPM in Healthcare going? The biggest big picture within which to appraise the potential for BPM to transform healthcare is The Fourth Industrial Revolution2. The Fourth Industrial Revolution (also known as Industry 4.0) is not about any individual technology, such as steam power, electrification, or computing (the first three industrial revolutions). The Fourth Industrial Revolution is not even about the Internet of Things (IoT), 3D printing, self-driving cars, artificial intelligence, or big data. It is about the interaction among all these technologies. In other words, The Fourth Industrial Revolution is not about innovative technologies, but innovative systems of technologies. It is about multiple, different, complementary, interlocking, and rapidly evolving technology sub-systems becoming part of an even larger, and way more complex, super-system, a system of systems. Wearing my systems engineering hat, I will argue that the Fourth Industrial Revolution is therefore about processes and workflows.

How do systems engineers manage system complexity? With models. Systems engineers gather data and optimize these models. These optimized models then drive system behavior. Then more data is used to optimize, and so on. In the old days, systems engineers sometimes gathered data with stopwatches and clipboards. I did exactly this, when I built simulation models of patient flow. Today, the Internet of Things and Machine Learning are reducing time scales to collect and process data down to mere seconds. And today, process-aware systems, such as BPM suites, orchestrate and choreograph system processes and workflows, potentially in seconds.

What are “process-aware” systems? These are information systems that explicitly represent, in database format, models of processes and workflows. The models are continually informed by data. The models are continually consulted when deciding what to do, say, or steer next. While process-aware systems “introspect,” they are not “aware” in a conscious sense, but rather in the sense that they can reason with these models; in real-time, in response to their environment and to exhibit intelligent behaviors that would not otherwise be possible.

Currently the industry most adept at representing work, workflow, and process explicitly, in a database, and using this data to drive, monitor, and improve process and workflow is called the Business Process Management industry. Why is BPM so relevant to creating and managing effective, efficient, flexible, and satisfying systems or systems? Because, as Wil van der Aalst, a leading BPM researcher writes, “WFM/BPM systems are often the ’spider in the web’ connecting different technologies” (and therefore different technology systems).

BPM, while not a direct descendent of early artificial intelligence research, inherits important similar characteristics. First, both distinguish between domain knowledge that is acted upon and various kinds of engines that act on, and are driven by, changing domain knowledge. Workflow engines are like expert systems specializing in workflow (warning, a very loose analogy!). Just as expert systems have reasoning engines, workflow systems have workflow engines.

Second, artificial intelligence (AI) and machine learning (ML) are critically about knowledge representation. Early AI used logic; current ML uses neural network connection strengths.

Finally, many AI systems, especially in the areas of natural language processing and computational linguistics, communicate with human users. When I say “communicate” I don’t just mean data goes in and comes out. I mean they communicate in a psychological and cognitive sense. Just as humans use language to achieve goals, so do some AI systems. Communication between humans and workflow systems is rudimentary, but real. Workflow systems represent the same kinds of things human leverage during communication: goals, intentions, plans, workflows, tasks and actions. These representations are, essentially, the user interface in many workflow systems.

To sum up, The Fourth Industrial Revolution is not about any one product, technology, or even system. It is about innovation in how multiple systems of technology come together. Process-aware technology, such as business process management, will play a key role in gluing together these systems, so they can be fast, accurate, and flexible, at scale.

You could go off and read a bunch of books about BPM. There are many excellent tomes. Then figure out how BPM and healthcare fit together. Or just keep reading this Second Edition of BPM in Healthcare.

If you are a healthcare or health IT professional interesting in healthcare workflow and BPM/workflow technology, you could start here:


Aalst, W. Business Process Management: A Comprehensive Survey, ISRN Software Engineering, Volume 2013 (2013), Article ID 507984, 37 pages.

Webster, C. Prepare for a Computer-Based Patient Record That Makes a Difference, Journal of Subacute Care, Vol. 1(3), 12-15, 1995. (

Webster, C. EHR Workflow Management Systems: Essentials, History, Healthcare, TEPR Conference, May 19, 2004, Fort Lauderdale. (

Terminology and Glossary. Winchester (UK): Workflow Management Coalition; 1994 Feb. Document No. WFMC-TC- 1011. BPM in Healthcare (2012) Future Strategies Inc., Lighthouse Point, FL.

Case Management in Industry 4.0: ACM and IoT – see chapter by Nathaniel Palmer” “

Free! My Book Chapter:

Marketing Intelligent BPM to Healthcare Intelligently!

@wareFLO On Periscope!


Posted in healthplan-bpm | 1 Comment

Price, Cost, Quality, & Value Transparency Require Workflow & Process Transparency

[This post is prompted by the upcoming #HITsm tweet chat on health care transparency hosted by @shimcode. The first three tweet chat questions, about healthcare price, cost, quality, and value transparency are particularly relevant to a slide presentation on which I have been working. So I thought I'd take this opportunity to post my current (draft) slides. I'm not trying to crowdsource the authorship of these slides, but I'd be delighted to receive comments or suggestions!]


I tweet a lot about the important difference between price transparency and cost transparency. (I was a premed-accounting major…) A couple years ago lots of folks talked of cost transparency, when, in my opinion, they really meant price transparency. I kept corrected people. I eventually gave up. Though I should note that most of the time I see price transparency correctly used now. But it got me thinking about the relation among price, cost, quality, and value on one hand, and my favorite subjects, workflow and process.


Usually one starts with an outline. However, in this case, there is diagram, which I explain, in detail, later, which shows how everything fits together: price, cost, quality, value, workflow, and process.


Here is some background. What do people usually mean by workflow and process? Systems thinking is all the rage in healthcare. What is the relation among systems, workflows, and processes, at least to this systems engineer…?


Productivity 101. Economists usually speak of labor productivity, but it is a more general notion that that. It is simply outputs divided by inputs. To double productivity means to double the output due to the same level of input, or to maintain the same level of output while cutting input in half,… and so on. I’m sure you get the basic idea. It is similar, by analogy, to amplification in electronic circuitry. Your radio takes a very week radio signal and turns it into a very loud audio signal. Highly productive systems, organizations, economies, workers, can do a lot with only a little.


The above and below slides seem redundant to each other. Need to consolidate.



This is perhaps the meatiest slide of the slide deck, and therefor requiring the most explanation.

The basic point of this slide was simply to translate a general systems engineering idea into a healthcare systems engineering idea. Price and cost are inputs to a “service line”, a bundle of workflows and processes necessary to provide a specific healthcare product or service. Think, the price, versus the cost, of a hospital procedure, such as an appendectomy. The price is set by market and/or regulatory forces. The cost is the expense to the hospital. This expense depends on the costs to the hospital of labor, consumables, durables, rent, etc. These costs also depend on prices in markets, but from the point of view to THIS organizations, they are costs. (Just as the prices the hospital charges are costs to patient and/or payers.) I know it is confusing. They are the same. And they are NOT the same. From the point of view of the healthcare organizations, the difference between price and cost is retained by the organization as profit (in the for-profit instance) or surplus (in the non-profit instance).

Firms use internal cost information to set prices. In general, they charge what a market will bear, unless constrained by regulations. However, if they cannot charge at least as much as their known true costs, in the long run, they will go out of business, leave the market, drop that service line, or figure out how to perform the workflows more inexpensively.

Quality is the degree to which a workflow and/or process fits the purpose of the workflow, that is, satisfy the goals of the workflow. Quality exists irrespective of price. However, value is a relationship between quality and price. In principle, if you know price and you know quality, then you know value, so transparency with respect the price and quality should be sufficient for transparency with respect to value. (I’m sure it’s more complicated… but I’ve got to make some simplifying assumptions somewhere, otherwise this whole hot mess is simply too complicated to think about at all!)


Sooo…. what’s missing from discussion of healthcare price, cost, quality, and value transparency? Workflow transparency, also known as process transparency.


Umm, already covered this. Reorder or consolidate.


Reorder or consolidate.


Reorder or consolidate.


Reorder or consolidate.


If you are providing me a product or services, why should I care how you do it? As long as the price and quality are right, I should like to view you as a “black box”, right? The problem is that healthcare workflows are so complicated, and they meander over and through so many healthcare, and health IT, systems, it’s getting harder and hard to figure out where to draw the boundaries between black boxes.

In fact, a big, big trend in business today is to take your back-office and enterprise workflows and processes and make them into front-office self-serve workflows and processes. Millennials don’t want to deal with you face-to-face, by phone, or through email. Just give them an app, so they can check the status of something, cancel something, or to modify some workflow or process, in real-time, to their satisfaction and convenience.

The only technology that can manage these, previously blackbox-enclosed, workflows is workflow technology. It models the workflows (sequences of smaller black boxes, called activities or tasks). It executes the workflows. It makes the workflows available, at scale, to folks outside the black box. They can make blackboxes transparent, at least regarding workflow, but that is actually a really big deal.


I need to work on this slide some more. The basic thing I’m trying to convey is that the route to making a service line, and entire bundle of workflows and processes, transparent in operation, is to break up the blackbox into smaller, interacting black boxes. In workflow management and business process management parlance, these are activities, tasks, steps, etc. They have inputs and outputs to each other. They cause things to happen to a patient, and they receive actions from a patient. They drive costs and provide information for the firm. What keeps all the ducks in a row? Workflow engines, which are single most defining architectural feature of workflow management and business process management systems.


Above is a typical list of features and advantages of process transparency. In a 2015 five-part series published in Healthcare IT News I wrote at length about task and workflow interoperability. I was writing about healthcare B2B task and workflow interoperability, not C2B (customer to business) or B2C (business to customer) interoperability/visibility/transparency. However the general principles hold for all three combinations. (Though one does wonder, what might C2C interoperability/visibility/transparency mean for healthcare…. for perhaps patient family members and bird-of-a-feather disease-centered support communities and support groups.)

This is what wrote about task visibility (transparency)…


This is what I wrote about workflow visibility (transparency)…



OK! We covered price, cost, quality, and value transparency, and then workflow or process transparency. What is the relation between the former and the later? In the long run, not only can we not optimize the former without the latter, in many cases, we cannot even measure important aspects of the former without the latter. A majority of healthcare costs come from expensive human labor. The only practical, scalable way to measure this costs is through some form of activity-based cost accounting. These activities are the same activities that workflow management systems and business process management systems model, execute, measure, and monitor.


In my 2015 series I noted two categories of people and organizations laying foundations and pursuing workflow interoperability in healthcare: health IT companies and organizations, and companies from the workflow management/business process management industry. Since then two more groups joined the fray. On one hand we have the citizen developers and citizen integrators, who are creating new health IT systems and workflows. On the other hand, we have standards organizations, such as HL7 and OMG (Object Management Group), both of which are beginning to address standards and technology necessary for task and workflow interoperability. (By the way, I just came back from a workshop on this subject, the Healthcare Business Process Management Notation Workshop, in San Diego.)


Yes, it will certainly be interesting see how all these task/workflow/process transparency/interoperability stakeholders get along with each other!


To summarize my argument, why price, cost, quality, and value transparency require workflow and process transparency….

Prices and costs are different concepts. Therefore price transparency and cost transparency are different concepts. Prices, and therefore price transparency, are influenced by markets and regulations. Costs are determined by resource expenses (people, consumables, rents) and technology (methods for transforming resource inputs into outputs). Competition pushes prices toward costs (which is why cost transparency is necessary for long run price transparency). Quality is how well workflows and processes fulfill their needed intended purposes. If we know price and quality, then we know value. And some form of workflow technology is necessary to monitors all the activities that make up the workflow and processes that transform inputs into outputs.


@wareFLO On Periscope!


Posted in social-media | Leave a comment

Business Process Model and Notation BPMN Healthcare Examples and Papers

I’m attending the Object Management Group Healthcare Business Process Modeling Workshop (press release, registration) at the beautiful Loews Coronado Bay Resort, near San Diego today.

This post consolidates a large number of papers and examples of using Business Process Model and Notation (BPMN) in healthcare that I reviewed during preparation for the workshop. I’ve been advocating workflow technology in healthcare for over two decades (My Foreword and Chapter in Business Process Management in Healthcare, Second Edition). In fact, I may have been the first to discuss, at length, Business Process Management (BPM) based health IT systems, including Electronic Health Records (2004, EHR Workflow Management Systems: Essentials, History, Healthcare). BPMN is not the only workflow notation relevant to process-aware health IT systems. Nor do all workflow management systems rely on a formal notation at all. However, as awareness, understanding, and use of BPMN spreads in healthcare, workflow management system and business process management technology will also surely spread, which is a good thing.

Here is some information about the Healthcare Business Process Modeling Workshop.

“Experts from the medical field and business modeling will discuss how OMG’s business process modeling standard can streamline the portability of clinical processes and workflows that govern how protocols are followed and care is delivered in healthcare organizations. For example, the agenda includes:

  • The Usage of BPMN™ for Obamacare
  • Using BPMN to Operationalize Clinical Knowledge
  • Integrating Clinical Information Modeling with BPMN
  • Modeling the Cognitive Side of Care Processes. Case Study: The Treatment of Atrial Fibrillation
  • Modeling Cancer Treatment Processes in BPMN and HL7 FHIR®”

“Within the health segment today, provider organizations each have their clinical processes and workflows that govern how protocols are followed and care is delivered. One of the operational challenges in becoming a “learning” organization lies in the ability to adapt and evolve those processes to embrace emerging best clinical practice, and to perform continuous improvement based upon care delivery and care outcomes within your own institution. Further, the professional societies and colleges continue to evolve and mature their guidelines, and staying current with those means incorporating that medical knowledge into your care pathways.

In a landscape where clinical knowledge and medical workflows are often either embedded in electronic health record (EHR) systems, or manually configured at an institution or site level, accommodating these changes can be timely, difficult, or near impossible to realize. Moreover, these rules are often expressed in “geek speak” and not in a language that can be owned and managed by the clinical community.

Business Process Modeling Notation (BPMN) is a non-healthcare-specific representation of business processes and workflows that has both broad adoption and a robust set of support tools. BPMN has enabled other vertical sectors to model these needs en route to creating reusable knowledge artifacts that could be shared and in fact interoperate across systems and organizations. Recent work in the industry have uncovered gaps in how BPMN should integrate with the healthcare workforce to support truly portable, patient centered processes. To put it in a different light, BPMN standards have helped define the baseline for What should get accomplished in any given health care process. The implementation of BPMN in healthcare is increasingly challenged by Who should be responsible for any given task.

This workshop is geared toward exploring the specific and unique needs of the clinical health landscape, investigating BPMN and the extended set of BPMN enhancement standards to determine the viability, coverage, and gaps when considering this approach for solving the healthcare challenges described above. Of particular interest is an exploration on how best to integrate BPMN with the healthcare workforce.”

Enjoy my research review preparing for the Healthcare BPMN Workshop! (By the way, there are lots of cool looking healthcare BPMN diagram examples!)

Not healthcare specific, but useful background…

Healthcare but not BPMN…

@wareFLO On Periscope!


Posted in social-media | Leave a comment

From Powerless To Powerful In Healthcare Through Workflow

[This post was inspired by the Healthcare Leadership (#HCLDR) tweetchat topic Powerful or Powerless in Healthcare.]

Set aside, for the moment, the issue of poverty and economics, when it comes to power in today’s society (where, simply put, often money is power, not knowledge). I will argue that the key concept to understanding what it means to feel powerful versus powerless is workflow: a series of tasks/actions/activities/experiences, consuming resources, achieving goals.

Consider engaging in a series of activities, say starting your car and driving to work. If at any point — trying open the door, trying to start your car, trying to put it in gear, trying to push the accelerator, trying to turn the wheel, trying to push the brake, and so on — what you do fails to achieve the result you desire, how to you feel? Powerless.

On the other hand, imagine you are captain of a starship. Your systems and people are incredible. Their processes and workflows are automatic, transparent, flexible, and always improving…. Every command you utter triggers incredibly sophisticated workflows that always achieve exactly what you wish. When you say, “Make it so!”, how do you feel? Powerful.

Powerfulness and powerlessness, in this workflow sense, are closely tied to a related psychological concept, “flow”, described in Flow: The Psychology of Optimal Experience, by Mihály Csíkszentmihályi, (whose graduate student I used to hang out with during medical school at the University of Chicago, by the way!).

From Wikipedia:

“In positive psychology, flow, also known as the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does. Named by Mihály Csíkszentmihályi, the concept has been widely referenced across a variety of fields (and has an especially big recognition in occupational therapy), though the concept has existed for thousands of years under other guises, notably in some Eastern religions.[1] Achieving flow is often colloquially referred to as being in the zone.” (Flow Psychology)


  • immersed
  • energized
  • involved
  • enjoyment

Another adjective that applies when you are in “in the zone” is that you feel “powerful”.

What is the connection between workflow (and workflow technology), in the prosaic sense usually invoked in healthcare and health IT, and feeling powerfully immersed, energized, involved, and full of enjoyment? Workflow is the concept that allows us to understand and design a series of experiences, experiences leading to feelings of powerfulness, instead of powerlessness.

What about that other sense of power (access to economic recourses), that I previously wrote about in Social Determinants of Health: Eat Your Beans? Or Speak Truth to Power?. This is the economic context of my definition of workflow: a series of steps/actions/activities/experiences, consuming resources, achieving goals.

The single most frequent and important reason that workflow fails is that at some step or other a necessary resource is unavailable. If you are poor, or otherwise lack access to necessary resources, your workflows suck and you feel powerless. On the other hand, if, at every step of workflow, all the necessary inputs are present, either due to your bank account or external agency, your workflows don’t suck. And you feel powerful.

How does all of this relate to empowering patients and providers?

Focus on their workflows. Focus on what they are trying to achieve. What steps will achieve it. And what resources each step requires to be a success.

@wareFLO On Periscope!


Posted in social-media | Leave a comment

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

“Begin with the End in Mind” — Stephen Covey

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

[This blog post is in preparation for the Exploring APIs in Healthcare Tweetchat 11/11/16 1PM EST. Also checkout my blog post about a previous related tweetchat How Easy Is It To Integrate Availity APIs Into Your Payer-Provider Workflow? Very! By the way, immediately before is a #HITsm tweetchat about Change Management in Health IT moderated by @fqure. A good article at the intersection of these two tweetchats is Change Management Workflow for API Consumers.]

In reverse order, here are the tweetchat topics and my answers. By starting with the future, toward which healthcare APIs are evolving, we can reason backward in a “Begin with the End in Mind” sense, about possible paths to get there.

(What’s an API? See below.)

T6: What is the next horizon for APIs in healthcare? #AskAvaility

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!


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.


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.

T5: How are APIs being used to improve patient outcomes? #AskAvaility

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.

T4: What are the concerns you have about partnering with an API vendor/endpoint? #AskAvaility

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 @KinLane (my favorite API tweeter and blogger).

T2: 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? #AskAvaility

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!)

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

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 @wareFLO 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.


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.


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


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


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!

…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!

@wareFLO On Periscope!


Posted in social-media | Leave a comment