Achieving Task and Workflow Interoperability in Healthcare: All Together Now!

My August, 3-8, 2015, 7000-word, five-part series on Task and Workflow Interoperability in Healthcare IT News (1, 2, 3, 4, 5) caused a lot of folks to contact me, about how their projects and products help work toward this goal. Thank you all! I’ve seen an interesting mix of effects since, from tweaked healthcare workflow IT marketing campaigns to reconceptualization of product categories (“Hey! We’re a workflow interop product!”) to FHIR proposals to represent task status. I’ve assembled the original five segments into a single blog post below, because each section builds on previous sections (especially workflow interoperability on task interoperability). I’m also adding an outline of links to related material, which I’ll occasionally update. BTW, if you’re interested in the relevance of workflow tech to issues beyond “mere” interoperability, check out my other five-part opus: BPM-based Population Health Management & Care Coordination: Workflow, Usability, Safety & Interoperability Perspectives.


From the original August 3-8, 2015 Achieving Task and Workflow Interoperability five-part series, combined into a single post….

Interoperability just might be the thorniest problem in healthcare today. And while much of the conversation treats it as if interoperability is one issue, in reality there are different types. In a five-part series, here’s my take on getting where we need to go.

Part 1: Achieving Task and Workflow Interoperability in Healthcare

I’m reminded of the famous first line in Charles Dickens’ A Tale of Two Cities, “It was the best of times, it was the worst of times.” Over the past decade we have spent billions to digitize healthcare, especially at the point-of-care in hospitals and medical clinics. So now we have unprecedented stores of patient data.

Nonetheless, in health IT imagination, healthcare interoperability is deep in Gartner’s Trough of Disillusionment. We need interoperability to leverage these unprecedented resources. What will it take to climb from the Trough of Disillusionment onto the Slope of Enlightenment and then Plateau of Productivity? I will argue task interoperability and workflow interoperability – and both require workflow technology to be done right.

There’s a level of interoperability above data interoperability. This is the workflow interoperability layer. Right now, if all of the data interoperability software works, we get to send some data from one system to another. But the mere ability to send data is not the same as being about to look into the workflows of another organization, and use that knowledge to better coordinate our internal workflow with their internal workflow. Only when we can do this, will we see dramatic improvement in the speed and quality of coordination of everyone and everything needed, so a patient can move seamlessly from home to medical office to hospital to rehabilitation and home again. This missing link is exactly what workflow interoperability provides. We are finally beginning to see the knitting together of separate specialists and organizations, each responsible for different aspects of patient care at different times and places during a patient’s journey.

Ten years ago, at the HIMSS’05 conference in Dallas, I predicted the following:

“EHR workflow management systems will need to coordinate execution of workflow processes among separate but interacting EHR workflow management systems. For example, when a primary care EHR workflow management system (System A) forwards a document (such as a Continuity of Care Record) to a referral specialist, who is also using an EHR workflow management system (System B), System A should expect a referral report back from System B. When it arrives, it needs to be placed in the relevant section in the correct patient chart and the appropriate person needs to be notified (perhaps via an item in a To-Do list). If the expected document does not materialize within a designated interval, System A needs to notify System B that such a document is expected and that the document should be delivered or an explanation provided as to its non-delivery. System B may react automatically or eventually escalate to a human handler. If System B does not respond, System A needs to escalate to a human handler. Interactions among systems, a hierarchy of automated and human handlers, and escalation and expiration schedules will be necessary to achieve seamless coordination among EHR workflow management systems.” (p. 14, EHR Workflow Management Systems in Ambulatory Care, HIMSS’05, February 14, 2005, Dallas)

Ten years ago there was very little task management in EHRs. The situation today is somewhat improved. However, most task management is based on what I call “frozen workflow.” Ideally, users should not only get task management, they should get customizable task management, the workflows for which they can arbitrarily change, and not be hostage to some Java or C# programmer. Furthermore, healthcare IT users need distributed task management, in which workflows span boundaries between healthcare organizations. Healthcare workflows? Cross-organization workflows? Created and edited by non-programmer EHR users? In this, to date, today’s EHR industry has not made much of a dent, if any at all.

The following is my diagram of the “Invoke,” “Monitor,” “Control,” and “Get Result” workflow pattern between a primary care medical practice EHR and a referred to sub-specialist EHR. Note that while “A” and “B” in the above quote refer to EHR systems, “A” and “B” the diagram below refer to tasks within EHR systems.


Figure from Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable EHR Workflow, Healthcare Business Process Management Blog, November, 2009

The key concept I am promoting here is not just tasks being pushed back and forth between healthcare organizations. The key concept is tasks being pushed back and forth according to workflow definitions and business rules under control of non-programmer clinical and administrative users who best know their workflows and rules (plus a dollop of governance to avoid workflows “gone wild”).

More recently, I’ve written about the importance of “pragmatic interoperability” in addition to syntactic and semantic interoperability. Syntactic interoperability is the ability of one EHR to parse (in the high school English class sentence diagram sense) the structure of a clinical message received from another EHR or health IT system (if you are a programmer think: counting HL7’s “|”s and “^”s, AKA “pipes” and “hats”). Semantic interoperability is the ability for that message to mean the same thing to the target EHR as it does to the source EHR or health IT system (think controlled vocabularies such as RxNorm, LOINC, and SNOMED).

Plug-and-play syntactic and semantic interoperability is currently the holy grail of EHR interoperability. We hear less about the next level up: pragmatic interoperability (AKA workflow interoperability).

“Pragmatic interoperability (PI) is the compatibility between the intended versus the actual effect of message exchange.” (Towards Pragmatic Interoperability in the New Enterprise — A Survey of Approaches)

Issues of pragmatic interoperability manifest themselves as issues about coordination among EHR workflows. The most mature technology for implementing pragmatic interoperability is workflow technology.

Sophisticated workflow technology (see my five-part tutorial) is coming to healthcare and health IT. Every year, for the past five years, I search every HIMSS conference exhibitor website for workflow and workflow technology-related words and phrases. The percentage of HIMSS exhibitor websites mentioning, even emphasizing, workflow and workflow technology has doubled every year since 2011, from less than two percent to over a third of HIMSS exhibitor websites. Sophisticated workflow technology is diffusing into healthcare and health IT at a rapid rate. However, in absolute terms, healthcare is a large industry. Many workflow-oblivious legacy EHRs and health IT systems are in place. They won’t be ripped-and-replaced in the foreseeable future. How can we optimally workaround and compensate for these vestiges of health IT past?

The key is workflow interoperability. And a key milestone on the way to workflow interoperability is task interoperability. I’ll delve into that in Part 2 of this series.

Part 2: A look at what healthcare task interoperability means

To truly grasp what the industry is up against, we must understand where we’re trying to go. And task interoperability is a key piece of the puzzle. I describe task interoperability in the second part of my five-part series on task and workflow interoperability.

Workflows are made up of sequences of tasks, consuming resources, and achieving goals. So it makes sense that workflow interoperability requires task interoperability. It’s classic systems engineering. Solve the subproblems (tasks), and then solve the relations among the subproblems (workflow), to solve the problem. I’m reminded of the old saying; how do you eat an elephant? One mouthful at a time!

A task is a “logical unit of work that is carried out as a single whole by one resource” (Aalst & Hee). In a medical practice, tasks include escorting a patient to their exam room, asking about current medications, conducting a physical exam, collecting a specimen to be sent to a clinical laboratory, sending the specimen to the clinical laboratory, reviewing results from the clinical laboratory, contacting the clinical laboratory because you’ve not yet received the results, and so on … if you are a hospitalist, I’m sure you can easily list a hundred typical hospital tasks.

Task interoperability is visibility, to humans and machines, of tasks and their status, context, and properties from one healthcare organization into another. Status includes such task states as Ready, Assigned, Expired, Forwarded, Finished and so on. Properties are aspects of tasks that don’t change during task and workflow execution. Examples include who or what is qualified to perform a task or prior estimates of cost-per-minute of accomplishing a task. Context includes aspects of tasks that do change, according to, well, workflow context. Examples include who owns a task, who was a task forwarded from and to, in what workflow is a task being accomplished, or from what workflow definition was a task activated.

What does it mean for a task in one healthcare organization to be “visible” in another healthcare organization? That depends on who, or what, is looking. Just as how many data and file formats can be designed to be both machine and human readable, task formats (essentially data about tasks) can be both machine and human readable. A task is visible to a human if they can find, retrieve, read, and make sense of the task description. A task is visible to a machine if the machine can find, retrieve, read, and do something useful with that task description, from displaying it to humans to archiving some information to triggering other tasks.

Task interoperability is impossible unless tasks are represented in the first place. So we have to figure out how to represent tasks, and then find, view, and process these task representations.

Years ago, I took a course in knowledge representation (KR) as part of my MS in Intelligent Systems (Artificial Intelligence). There are many kinds of representations. In this case, a representation is a set of statements about a task. These statements can be added or deleted. KR folks (and computer programmers in general) often speak of properties and values. An apple has a Color property. For a specific apple, the value of the Color property might be Red (or Yellow, or whatever). We pick a specific apple out of a universe of possible apples by assigning a unique identifier, such as “2f39fnv9483h” (I just typed that a random. If I were to refer to a different Apple, I’d need to make sure I don’t accidently use the same identifier, but that is very easy in a computer).

The same goes for healthcare tasks. For a given patient of mine, from behind hospital walls, I’d like to retrieve a list of IDs. (I am of course speaking in the voice of a physician-programmer. Physician-non-programmers just want a list of human-readable descriptions, plus ability to do something useful with them, which is where machine-readable comes in.) Each ID is uniquely associated with a specific enacted task. In the workflow technology world, “enacted” workflow means “executed” workflow. It is analogous to the difference between an unexecuted computer program versus the thread of execution of that program while being executed. Workflow definitions are like the former. Enacted workflows and tasks are like the later.

Once I have a list of task IDs, for each ID, I’d like to access whatever context and property values are relevant to my current goals. For example, I’d like to see a list of sensible (to me) names of clinical tasks. These names could simply be strings stored in each clinical task’s Name or Description property. Another task aspect I’d be interested in, at least for some tasks, would be Status. Show me all the completed tasks for my patient. Then for some of those completed tasks, show me patient data relevant to the tasks, such as data generated during accomplishment of the task. An example might be a clinical lab result or radiological image interpretation. Remember, I am just using these workflows as illustrations. I am not called for particular workflows to become standard workflows. What I am calling for is your ability to create and modify whatever workflow you need to do your job most effectively, efficiently, flexibly and enjoyably.

The layer of task representation is essentially part of a navigational user interface. Instead of a clinician interacting directly with the underlying data, clinical task status, context, and properties are used to find, filter, and interpret data. Assume I work for a health insurance company. I might be interested in tasks that are ready, but not yet assigned, to make sure they are covered before they assigned. Assume I am a hospital management engineer. I’d be interested in time-stamps, for purposes of spotting bottlenecks and rework. Data associated with tasks is a goldmine, not just for users within a healthcare organization, but users in other healthcare organizations too.

Health IT is on the cusp of beginning to implement task interoperability. Startups are beginning to monitor and route care transition events. These are tasks at the boundaries of health organizations, such as hospital admission and discharge. However, there are many other tasks behind the walls of hospitals and other healthcare organizations. Folks say to me, what do I care about what goes inside someone else’s healthcare workflow black box? To which I reply, you should. Providers need to better understand health plan payer internal workflows. Health insurers need to better understand provider workflows. And both need to better understand patient workflows, AKA life-flows. In fact, across many industries a trend is to make enterprise tasks, workflows, and processes more transparent, to make them visible to external customers and partners, using social, mobile, and cloud technologies, and then to systematically improve customer experience with analytics.

The trend toward explicitly representing, manipulating, and sharing clinical tasks, and using these representations to automatically trigger valuable human and machine workflows is beginning to take off inside healthcare organizations. These lightweight, mobile and (secure) social-like apps get data from older systems, including EHRs, and get data from human users, because these users get value back from entering and sharing clinical task data. Given that changes in admission and discharge task statuses are beginning to be shared, we are just a step or two away from sharing other tasks deeper within healthcare organizations.

An obvious place to represent healthcare tasks is in some future version of FHIR (Fast Healthcare Interoperability Resources). However, for purpose of this happy path into a future of workflow interoperability, I’ll abstract away from specific transport and data standards. The technology is already here, (a variety of web service technologies and data formats) to create task interoperability. In other words, don’t wait for a standard. As a practical matter, I’d rather deal with a half a dozen well-designed and well-documented healthcare task APIs (Application Programming Interfaces) than wait for some future health IT task standard promising nirvana. If your APIs generate value, someone will come along and aggregate them anyway. That said, keep an eye on any nascent healthcare task interoperability standard. The discussions and communities of practice can be excellent educational and networking resources.

This five-part series could have been titled “Getting To Task Interoperability And Then From There To Workflow Interoperability: Healthcare Workflow Silos Unite!” but that would have simply too unwieldy. We just covered, “Getting To Task Interoperability.” Now we need to cover, “Getting To Workflow Interoperability.”

In the next installment, I’ll dive deep into workflow interoperability.

Part 3: Laying down a definition of workflow interoperability

Building on data and task interoperability, healthcare will finally be able to get to workflow interoperability. In the third part of my five-part series, here’s a look at what that means.

You can think of a workflow system (an informal phrase I use that includes Business Process Management, or BPM) as a collection of tasks and these tasks having states: pending, started, postponed, reassigned, escalated, cancelled, completed, etc. When a task is completed, other tasks may be automatically started, assigned to users, or roles (collections of user, anyone which can complete the task). Moment-by-moment all tasks and all task states can be displayed. If you’ve never used a workflow system, you have no idea how valuable such a display is to preventing even the possibility of someone dropping the ball, so to speak, with the result of a languishing task (and an increasingly pissed-off customer).

Workflow interoperability is visibility, to humans and machines, of task relationships, plus context and properties, across healthcare organization boundaries. Just as healthcare task interoperability is not possible without representing tasks, healthcare workflow interoperability is not possible without representing workflow (relationships among tasks).

Consider, for example, my earlier diagram of several tasks being delegated from a primary care clinic to a subspecialist. The relationships are the lines between the lettered tasks. I uncluttered the workflow diagram a bit. First of all, I’m using letters instead of clinical task descriptions. A and F could be “Refer to specialist” and “Receive results from specialist.” You’ll also sometimes see arrows instead of just lines. In this case all the arrows would have been downward, so I eliminated them. The workflow diagram illustrates the four most basic workflow primitive patterns: sequence (F to G), parallel split (A to B and D) or choice (A to B or D), and join or merge (C and E to F). Terminology varies. But you get the idea. These are the DNA bits out of which more complex workflows are constructed.

Recall, in Part 2, when I distinguished between task properties and task context? Similarly, some relationships among tasks don’t change, but some do change. The relationships among tasks that don’t change, except when users intentionally change them, are part of workflow definitions. The relationships among tasks that change? They occur when workflow definitions are executed, and come into contact with the real world. Users cancel tasks. They add tasks. These tasks have temporary relationships with other tasks in the currently “enacted” workflow.

Workflow diagrams are used informally throughout healthcare, though they are often called flowcharts. The difference, between these diagrams on napkins or in Visio and a workflow diagram in the workflow technology world, is that a workflow diagram is actually an executable program controlling automated workflow behavior. Of course, you need a more information, such as which users or roles can accomplish which tasks, and what workflow screen or form is to be pushed onto their worklist (often called a To-Do List). Also, there are business rules, to determine, for example, when to escalate and to who, and, when you come to a split, which path to take, for example, A, B, C, F, G versus A, D, E, F, G. Furthermore, some case management systems represent work in other ways besides workflow diagrams. But to keep it simple, in this necessarily tutorial series, I’ll stick with the simple workflow diagram I introduced in Part 1 of this series.

Workflow engines executing workflow definitions powerfully influence health information system usability. They not only intelligently forward tasks to the right person (and follow up to make sure tasks are completed), but also automatically navigate among screens for a single user. The effect is a bit like most software installation wizards: Next, Next, Next…, OK, OK, OK…. Of course, users are free to jump off automated workflow happy paths at any point. A “happy path” is what’s supposed to happen, barring the unexpected, when you use a software application. Uncompleted tasks hang around, visible to someone on a To-Do list, or eventually escalated according to previously user-designed business rules.

Suppose you are a precocious user. Let’s say you want to add a screen or screenless step (such as check for and download a lab result). Instead of calling your EHR vendor to request the change in workflow, you just pop open that visual workflow editor and drag-and-drop new step H into the workflow diagram. Then you double-click and edit a business rule. Pop back into the application; you just changed the workflow of your EHR to a workflow you prefer. In fact, one of my popular posts is my Litmus Test for Detecting Frozen EHR Workflow. Ask the sales gal or guy to show you the workflow you just observed in a workflow editor, delete a step, and then observe the demo of the edited workflow again. If that task step is now missing from the workflow, then there must be a workflow engine executing (“enacting”) the workflow you just ask to be edited.

Workflow interoperability? Some tasks in a single workflow diagram might be in one healthcare organization and some might be in another healthcare organization (D+ and E+ in the previous workflow diagram). This is exactly the picture I painted ten years ago. Instead of my getting an alert when my patient discharged, how about my getting an alert when the X-ray is read? Or when an important result from clinical pathology comes back. (If I chose to get the alert… I’m free to edit the workflow definition on my side of the organizational divide.) Just as in a medical practice, where it is more efficient to begin to assemble a vaccination tray when the vaccination is ordered, not when told to do so after the physician leaves the exam room, there are workflows external to an organization we’d like to kickoff when a task changes status within an organizational workflow. Someday non-programmer super users and clinical and business analysts will design these cross-organizational healthcare workflows by dragging, dropping, and configuring graphical icons in visual workflow editors. (Though, one should note, workflow editors don’t always look like flowcharts. Sometimes they look and work more like user-configurable templates or checklists.)

In fact, how about me being able to not just see into a workflow’s past, but also into its future. For me to see not just started or completed healthcare tasks, but future intended tasks as well, I need not just healthcare task interoperability but healthcare workflow interoperability as well. I need to pull over the entire workflow definition, so I can look along the workflow happy path to see which other tasks are likely to be started and accomplished. In other words, we need healthcare workflow interoperability not just to automatically kick off tasks in other organizations, we need the representations (that word again) of workflow to allow us to follow along and understand the intentions and goals of our partner healthcare organizations.

I often claim, as important as open source and open data are, open workflow is even more important. Open workflows are “figuroutable” and “buildonable” in ways that open source and open data are not. Non-programmers can read and modify workflow definitions, to design changes in workflow, in ways that they cannot accomplish pouring through traditional open source code. Being able to look into another healthcare organization’s workflows, and then use those workflows to drive workflows in your healthcare organization, releases all kinds of creative possibilities and problem solving.

Similarly, data is static and tactical. Workflow is dynamic and strategic. Let me see the data pipelines giving rise to data. Let me tap into those pipelines wherever I wish. Maybe you’re doing something with the data in the last step I don’t understand, or, if I did understand, might wish to do differently. Give me access to the workflow generating the data, and I’ll create my own hybrid pipeline, better serving my idiosyncratic needs and purposes. By the way, open workflow is relevant to the patient data ownership debate. Patients won’t truly “own” their data until they (or agents acting on their behalf) control the workflows generating their data.

That’s what workflow interoperability in healthcare means – my next two parts in this series will explain how to make it happen.

Part 4: Bridging the gap between data and workflow

The health IT industry has a second chance at building process-aware health information systems, if we proceed carefully and in the right manner. In this, the fourth part of my five-part series, are my suggestions on making workflow interoperability happen.

The health IT market is in a transition period, from extremely data-centric systems toward more customizable workflow-centric systems. By “data-centric” I mean essentially structured databases plus graphical user interfaces. Users still have to figure out what to do next, hunt around to find the relevant data, and then further navigate around in order to enter data and orders. By “workflow-centric” I mean systems proactively pulling and pushing data and tasks to users, according to customizable templates and workflow models. This is a nascent trend. But it is growing quickly.

Investors view this trend as a way to unlock the value of the tremendous amount of data contained within tens of billions of dollars of recently installed hospital and ambulatory clinical information systems. This trend favors modular solutions, since the workflow technology can be used to “glue” modular functionality together. It’s been referred to as a “spider in the web” for its ability to connect disparate systems and technologies together (more below). However, large enterprise hospital vendors have considerable leverage; they have more money and more data. They are opening “app stores” to provide access to their data, but on their own terms, as they seek to control health IT market evolution. There’s even a workflow interoperability angle here. Workflow technology will be ideal for gluing together the apps in this app stores, into useful and customizable sequences of task-accomplishing apps.

A technology currently touted as a means to integrate systems together is FHIR, for Fast Healthcare Interoperability Resources. In a couple years we’ll see standalone apps accessing data in from these data-centric systems. Some of these apps will be embedded into EHR user interfaces (such as for calculating pediatric doses or specialize drug interactions). FHIR will also be used by more workflow-centric care management systems, which you can think of as a layer on top of individual data-centric systems. These workflow-centric systems will increasingly coordinate care across providers, track patient events, and management handoffs. However, until FHIR can represent task and workflow state, workflow platforms will have to compensate and provide these missing pieces of the workflow interoperability puzzle.

To the degree we surround healthcare organizations with process-aware health information systems, process-aware technologies will inevitably seep across and into these healthcare organizations. If we use workflow technology to effect workflow interoperability among healthcare organizations, they will begin to leverage task and workflow representations within their borders with workflow technology. I’m reminded of a recent conversation with a hospital IT executive. He needed a Business Process Management engine to maximally leverage interoperability with his local Health Information Exchange, because it had a BPM engine.

I started this five-part series by quoting myself, from ten years ago. I described a conversation between two EHR workflow management systems, one for primary care, and the other for a subspecialty. Much has changed in ten years, but EHRs still won’t be conversing with each other any time soon. They’re essentially databases with user interfaces. They can’t converse because they don’t represent and execute the workflows necessary to converse. Some layer of process-aware technology must speak for them.

Let’s take a look at one of my favorite descriptions of interoperability.

“An organization with a high level of interoperability is characterized as being able to work with other organizations in a unified or enterprise way to maximize the benefits of collaboration across organizations and across multiple … investments or projects … networks” (Existing Interoperability Maturity Models, Center for Technology in Government)

This definition of mature interoperability is about workflow, process, orchestration, and collaboration. It’s about workflow interoperability in the sense as I describe in Part 3 of this series. These are exactly the concepts missing from today’s data-centric discussions of healthcare interoperability.

What are the technologies that will get us to unified maximum enterprise collaboration across healthcare organizations?

Bridging the gap between data and workflow has been health IT’s greatest challenge to date, though I don’t think this is widely appreciated yet. Over the next five years we will see an evolution of internal healthcare organization IT systems toward support of essentially two parallel, complementary, interacting platforms, one for data and the other for workflows. Data integration platforms will face legacy and new data sinks and sources. Workflow integration platforms will face users, including patients, to provide seamless workflow user experience.

Healthcare interface engines were early adopters of process-aware technology, which they use to implement data flows. Visual editors of data workflows make programmer’s lives easier. Increasingly, we’ll see these vendors also begin to add user-facing applications and intelligent task management.

The more unusual advice I will give is to adopt workflow application development platforms. Traditionally this space has been called Business Process Management (BPM) and, earlier, workflow management systems. This technology is just starting to diffuse into the health IT industry, but at an increasingly accelerating rate. This is the technology to allow your limited development staff to not only more quickly spin up desktop and mobile apps, connected to your data systems and platform, but also provide an integrated task management experience for your users.

A welcomed byproduct of adopting BPM technology, besides laying a foundation for workflow interoperability, is that it is a “low-code” approach to application development. Healthcare has long been stuck between a rock and a hard place, when it comes to products and services based on information technology. Either you buy prepackaged software from someone who promises to solve your problems, or you hire programmers to create new applications from scratch. In the former instance, you’re stuck with whatever rate of innovation and compatibility your vendor allows you. In the later case, you create exactly what you need, but only at great expense. And then, when requirements change, it costs an arm and a leg, to modify, if it can even be substantially modified at all.

“Low-code” application development is a very different story. It’s not buying someone else’s preexisting software and it’s not writing software yourself using a third generation language such as Java, C#, etc. (both of which I love, don’t get me wrong). It’s creating exactly the custom workflow-smart/work-smart workflow application you need, without having to literally “write” computer code, so you can create and change quickly. As I already pointed out, healthcare interface engines were early adopter of process-aware technology. Interface engines and workflow engines have a lot in common, except one faces data sources and sinks, while the other faces users and applications.

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.

In my next and last part of my five-part series on task and workflow interoperability, I’ll tie up some loose ends and make some predictions.

Part 5: Achieving workflow interoperability among healthcare organizations

Now that we have laid the groundwork in parts 1 through 4, let’s look ahead, about five years into the future. How will a new generation of workflow platforms pull all the pieces together, to get to true healthcare workflow interoperability?

We will see a plethora of clinically- and patient-oriented workflow platforms. Many have already obtained considerable investment and beginning to expand their market footprints. It’s early days yet. But, within five years we’ll see as much, or more, about facilitating workflow at the point-of-care and point-of-health as the emphasis on population health and patient engagement at the recent HIMSS conference in Chicago. In fact, population health and patient engagement are playing critical roles in driving adoption of process-aware workflow technologies in healthcare. If you drill down through the layers of technology necessary to do both, efficiently, effectively, and flexibly at scale, you’ll invariably find some form of workflow orchestration engine. In some cases these will be based on third-party business process management suites. In some cases the workflow engines will be proprietary. It’s often hard to tell which is which, since many vendors do not wish to reveal they are relying on an embedded third-party product.

Regardless of whether you use a full-fledged pure-play BPM platform or a homegrown health IT workflow platform, look for the workflow engine under the hood. It will buy you speed (throughput, patient volume), transparency (ability to track all tasks at all times, letting none fall between the cracks), and flexibility to systematically improve intra- and inter-organizational workflows.

When you strip away all the fancy words and acronyms, we are talking about To-Do lists. Putting To-Do items on To-Do lists and letting staff know about them is what workflow systems do very well. They were the reason workflow management systems were invented several decades ago. They’ve had several decades to improve. To-Do lists help human figure out what to do next, and tell automated systems what to do next, within organizations and, increasingly, across organizational boundaries.

Workflow management systems (now business process management and adaptive case management systems), have literally been around for over two decades. Workflow technology evolved quickly since I wrote that earlier passage (in Part 1 of this series) reflecting back to ten years ago. Within the BPM industry, there are healthy debates about automating structured and routine workflows versus unstructured and ad-hoc workflows (using ACM, for adaptive case management, also called dynamic case management). Workflow analytics, especially process mining, came from BPM research, but can be used to substantially improve workflows of even systems without classic workflow engines. BPM thought leaders talk about “empathic workflow” in which backend enterprise processes and customer journey maps are reimagined and then quickly implemented and systematically improved. I know both BPM and ACM pretty well, for a health IT guy. I’ve been a judge for both the BPM and ACM annual awards for years. I encourage EHR and health IT vendors to apply for one or both of those top awards in the workflow technology industry today.

A wide variety of entrepreneurs and intrapreneurial healthcare organizations are putting down a new layer of workflow technology on top of an existing layer of data technology. The difference between data technology and workflow technology is key. Most current healthcare data that health IT manages is about patients, not about processes and workflows. Makes sense, for individual patients, healthcare staff and patients need to keep track of symptoms, diagnoses, prescriptions, and so on. This data is about patients.

We need more than data about patients. Real value resides in information about workflows creating patient data. We need data about workflows involved in using patient data, in real-time, to trigger workflows influencing patient and provider behaviors. Then we need data about those workflows. To systematically improve effectiveness, efficiency, and user and patient experience, we need to, and will, collect data not just about patients, but also about workflows serving patients and providers. Much of this will be delivered via modern mobile, cloud, and analytics platforms. Under the hoods of many of these systems? Workflow engines.

A word is due here about security. I am sure that when I speak of “visibility” of tasks and workflows across organizational boundaries, red flags must go up in some minds. What with all the recent high-profile breaches of sensitive patient data, how can we possibly contemplate making internal healthcare information even more visible to outside organizations? Process-aware workflow technology, within and across healthcare organizations, can be substantially more secure than what we currently have in place. First, modern BPM application platforms have an extra layer of security (against which workflow app developers develop) implemented by professionals who understand security well. Second, knowing an event takes place, or typically takes place, is not the same as knowing the patient data resulting from the event. We get notifications all the time that something interesting just happened. We then have to authenticate ourselves to get the details. Third, need-to-know access control to patient data is can be more finely grained. It can be granted at the beginning of a specific step in a workflow, than then revoked when the step is completed. Fourth, workflow platforms log much more comprehensive and detailed data about who looked at what, when, and in what context. Finally, knowledge of the workflow of how another organization handles data you send to them is important to you in making critical judgments about whether you can trust that organization.

Terminology (not just technology) is in flux. These new systems could be called Care Management Systems. Other names include Care Coordination Platforms or Healthcare or Care Process Management systems. This is a layer on top of EHRs and other health IT systems explicitly intended to coordinate care across providers, track patient events, and manage task handoffs among providers. It is a classic scenario for workflow technology, already being used to coordinate lots of things we consumers take for granted these days, from Amazon to Google Now to systems we don’t even know the names for, but just invisibly work. In fact, I don’t see these workflow systems as separate from or leveraging healthcare interoperability. They will be workflow interoperability.

Workflow interoperability is coming to healthcare and health IT whether we like it or not (and there will be some legacy laggards who won’t). Other industries are a half-generation ahead of health IT in adopting workflow management systems, business process management and adaptive case management systems. It is a natural and desirable progression of software application architectures: taking data out of applications into databases, user interfaces out of applications into operating systems, and, now, taking workflow out of applications into process-aware workflow orchestration systems. Health IT will not be an exception to this general pattern. However, as a community, of workflowistas, health IT and BPM professionals, we can accelerate the change needed to get to task interoperability and workflow interoperability. The key will be entrepreneurs (and intrapreneurs) seeing and grasping the opportunity. There’s a lot of money to be made (or saved) in displacing (or compensating for) workflow-oblivious legacy health IT infrastructure.

By the way, there is no small role for health IT social media to palaver, kibitz, and egg on these healthcare workflow entrepreneurs and intrapreneurs.

Wearables, Workflow, and Activity Trackers: You Can’t Measure What You Don’t Manage

This is just a short blog post to get ready for this week’s Healthcare Leadership Blog tweetchat, at 8:30PM EST, most every Tuesday.

You Can’t Measure What You Don’t Manage: Why I Advocate Wearable Workflow!

Amusing, at least to me, is that many proverbs are not only reversible, they are sometimes more true, profound, or funny. Here’s a fun list. Here are three of my favorites:

  • A company is known by the people it keeps
  • He who laughs longest laughs last
  • Time wounds all heels

I routinely reverse sayings just to see what results. My absolute favorite is “You can’t measure what you don’t manage,” (and similar, after “You can’t manage what you don’t measure.”) because it aligns with my concept, “Wearable Workflow”.

The basic idea of wearable workflow is that we have to understand how wearable tech fits into our professional and personal workflows, sometimes called lifeflows. However, I go beyond this and argue we need to use some form or workflow technology to manage interactions among wearables, people, tasks, goals, environments, and so on.

Systems engineering (my MS) often involves collecting data about system behavior. This data is then used to improve behavior. Ideally, the very processes and workflows of a system are designed to emit exactly the right data that is needed in order to improve performance. This is what I mean by you can’t measure what you don’t manage. We will have to design the wearable workflow so as to collect the data we need to improve them.

I actually give a keynote on this topic at the Healthcare Systems Process Improvement Conference (Orlando in February!). You can watch the keynote on Youtube. I also turned that talk into a book chapter, which you can download here.

Earn health insurance discounts WITHOUT exercise with UNFIT BITS!

I spent Saturday at the Open Hardware Summit in Philadelphia. (I’ll connect this back to wearable workflow in a moment.) It was really cool for many reasons and deserves a dedicated blog post. However I’d like to highlight one presentation about activity trackers. It was a polished and energetic parody of many a startup pitch I’ve seen. However, instead of pitching a new activity tracker, they pitched a variety of products to evade activity tracking, but still get those health insurance discounts. Below a young lady twirls a Jawbone on an electric drill. Other methods involved metronomes and attaching activity trackers to automobile tires!

For a minute or two, when it started, I was a bit confused and shocked. This was stylish and hip backlash to corporate wellness programs and technologies. What fascinated me was, this is how rebellions begin. Often the first sign that a dictator will be toppled is laughter at that dictator’s expense.

Activity trackers, as a thing, are over, at least in the eye of these edgy trend-setters. Now, whether it’s relevant to over 50s Fitbit wearing Boomers, I don’t know. However, it is consistent with what I wrote before about wearable workflow.

Activity tracking, and other health wearable technology, needs to become an invisible part of our ecosystem of at-our-service personal and professional workflows. It needs to be disguised as something else. If “disguised” sounds distasteful and unethical, then it needs to become something else entirely.

Which brings me the following illustration.

Twitter’s Video Live-Streaming Service Periscope Helped Me Lose 15 Pounds!

A couple of weeks ago I was asked, as part of a tweetchat, for my top three health apps were.

I listed Twitter, Periscope, and my Pebble watch (running Jawbone UP24 app).

Here was my rationale. Twitter is basically my number one app for everything, including health information. Of course, the info is typically at the end of links tweeted out by curators I follow, but it is still the Twitter app that makes this possible.

Skipping to number three, I’ve tried a number of trackers, and Pebble is the one that finally stuck, but only when Fitbit’s competitor Jawbone made their activity tracking service available as a Pebble app. Even more notably, I’ve given my wife lots of neat gadgets and technologies over the years, and hardly any of it every makes the grade. Most ends up gathering dust. However, in this case I got her the nicer looking steel version of Pebble. I created a custom watch face incorporating her company’s logo. And I installed the Jawbone UP24 app. She loves the look, the customization, and that she only has to charge the Pebble once a week. One more convenience is that we don’t bother syncing to the cloud. With a shake of the wrist it shows on a bar graph how far she (and I, on my Pebble) walked on each of the past seven days. We constantly compare. So, no synching to the cloud. Hardly any charging. And, as far as she is concerned, it’s not even actually an activity tracker. It’s a cool looking watch with her companies logo on it. Other employees are so envious they’ve bought the same watch and asked me to similarly customize!


But what about Periscope? Certainly it can be used as a way to inform and motivate; I’ve seen several ‘scoopers share their diet and weight success stories and best practices. But that’s not what lost my 15 pounds. What lost my weight was getting out and about, often before sunrise, to share the sights and sounds of where I live, Washington, DC. I even registered a new domain, for Washington, DC, periscopes. I archive my best scopes (where “best” often correlates amount of interaction with viewers).

But this is what I was talking about earlier. Periscope isn’t a traditional activity tracker. Far from it. Though I can imagine interesting future activity tracking mashups, particularly when a Periscope API materializes (an API allows third party programmers to develop third party apps). For example, that amusingly cynical presentation about UNFIT BITs at the Open Hardware Summit? It will be hard to cheat, and it will be perhaps less tempting to cheat, if we are actually Periscoping our walking about. I’m already seeing lots of exercise fanatics ‘scoping their routines. That’s cool, but what I’m taking about is not scoping about exercise, but rather incidentally generating exercise as a by product of an enjoyable social activity woven into our wearable workflow, so to speak.

What Would Mr. RIMP Do?

I’d like to add one more section to this post, about my pet project, Mr. RIMP. RIMP stands for Robot-In-My-Pocket. “He” is a customizable, 3D-printed, interactive, wearable robot. He has a Twitter account (@MrRIMP), a web address (, and even a business card. You can see a demo of me interacting with Mr. RIMP in the following tweeted video.

Mr. RIMP potentially has similar indirect effects on my physical activity as Periscope. I’ve walked around all day at numerous Makerfaires. The following is from the most recent here in Washington, DC. You can see how folks are drawn to and interact with Mr. RIMP. (Fast forward to about half way through to see the kids, several of who genuinely seem astonished.)

The current version of Mr. RIMP (version 3) has two sensors and three effectors. He can sense objects right in front of him and he can sense someone touching his toes, finger, and “hair.” Mr. RIMP can act on his environment through his heartbeat. I’m intended to eventually vary the color and rate to represent emotional state. An 8×8 grid flashes a dynamic colorful bar graph in response to ambient sounds, to show is he is “listening.” And he says things. I like snakes! RIMP stands for Robot-In-My-Pocket! And he even recites poetry from the famous American poet, Robot Frost.

At this point I’m trying to be imaginative about version 4. I like the idea of adding an 3-axis accelerator. Then certain motions could cause him to exclaim “Let’s dance” and then sing. Also, accelerator data could be collected, a la Fitbit, Jawbone, etc. Obviously I’d like Mr. RIMP to be (even more) cute, polished, and intelligently interactive. I just thought I’d introduce him into the #HCLDR tweetchat community. I’ve got to “socialize” him sometime! 🙂


I’m just saying what I usually say, albeit customized to wearable activity tracking. Healthcare needs better workflow data, and the best way to get this data is through use of wearable technology. There’s beginning to be some interesting work in this area though!

Activity tracking needs to be an invisible, but ethical, part of an ecosystem of personal and professional workflows. The route to get there will be a combination of using workflow tech to generate data about workflows and life-flows. And then the key to leveraging these data and insights will be what I call “Wearable Workflow.”

Big Workflow Is Familiar, Fit, Foundational, Unfailing, Flexible, and Far-Wide-and-Near

If you’ve heard of “Big Data” (who in health IT hasn’t?) then you may have also heard of the volume, velocity, variety, veracity, value mnemonic. I’m here to offer a similar mnemonic for “Big Workflow.”


Big Workflow Is

  • Familiar,
  • Fit,
  • Foundational,
  • Unfailing,
  • Flexible, and
  • Far-Wide-and-Near!

Let’s go through each of these qualities of Big Workflow.

Big Workflow Is Far-Wide-and-Near!

Let’s tackle Far-Wide-and-Near workflow first, because it’s the “Big” in Big Workflow. Events on the far side of Pluto can trigger events near, on, or even inside you, though I have trouble thinking of a use case for Pluto-to-implantable workflow. However, if you’re a NASA engineer, I can easily imaging a Pluto-to-wearable workflow. That’s the far and near. What about wide? Well, we humans care about a wide spectrum of different kinds of events, but they all potential contend with each other for our limited attention.

Big Workflow Is Familiar!

It’s easier to learn something new, if it resembles something old with which you are already familiar. Cognitive psychologists call this a “transfer” effect. Knowledge and competence in one domain is transferred to another domain, thereby reducing the time to master the second domain. The opposite is the “interference” effect. What you already know interferes with what you are trying to learn. The classic example of this in health IT is the degree with which EHR workflow resembles, or not, clinical workflow.

Big Workflow Is Fit!

Big workflow fits the job you are trying to accomplish. Do the workflows of the systems we attempt to master and manipulate fit the natural tasks and workflows of the jobs and goals we are attempting to accomplish? Fit and familiar are not the same though. We may attempt to master a completely new domain, one with which we are completely unfamiliar, yet the software application may naturally fit, or fail to naturally fit, the intrinisic tasks, goals, and workflows of that domain.

Big Workflow Is Foundational!

Big workflow is a foundation you can just count on being there. It allows to you build something else, on top. Software platforms are foundations on which we build applications. Applications that provide to use all the information we need, at each step of a workflow, are supportive, in this foundational sense.

Big Workflow Unfailing!

Big workflow is consistent. It never, ever, fails to be all of the other things in this list of Big Workflow ‘F’s. Big workflow is ALWAYS familar, it fits, is foundational, flexible, and far-near-and-wide. No, of course all workflows cannot ALWAYS be all these things. To be all of these things is an ideal, one which can never be completely achieve, yet it is ALWAYS to be striven for. It is the guiding star, from non-ideal workflows to ideal big workflows. Which brings us to…

Big Workflow Is Flexible!

How do we get to Big Workflow? Well, the workflow technology that makes workflow possible has to be flexible. If it is flexible, then we can change it. We can systematically improve even crappy workflow, to make it less crappy, then pretty good, and then, finally, eventually, as good as we can make it, given the time, money, attention, and resources available. Frankly, health IT has barely started along the path to Big Workflow, because the software technologies health IT relies are have relatively frozen workflows. Unless we adopt true workflow technology, one based on models of work and workflow, that are executable or at least mechanically consultable, health IT workflows won’t be sufficiently flexible to improve in the first place.

Healthcare Business Process Management

Now that we have so many databases full of clinical data everywhere, especially in EHRs (Electronic Health Records), we need to move from thinking about data to thinking about the workflows necessary to put all that data to work. We need to move from a Big Data mentality to a Big Workflow mentality.

We are seeing a wide variety of terminology applied to this space, from Care Coordination and Care Management Systems to Healthcare and Care Process Management. What all of these systems have in common is they are specifically designed and directed toward improved clinical task and workflow management. Many of these systems are leveraging Business Process Management (BPM) application platforms to build their software.

Let’s move from a data mentality to a workflow mentality. In doing so, we still create and use data, it’s just that we create and use data to accomplish valuable tasks, workflows, and goals. Big Workflow includes Big Data. But it’s bigger, like that wave of Big Workflow about to swamp that wave of Big Data. 🙂


Periscope, Social Video-Streaming, and Health IT Social Media Tweetchats: Disruptive, Additive, Or Complementary?

I love Twitter, now. It took me a couple years before I truly became addicted (different post!). I immediately glommed onto Periscope, though. I’ve written several posts about Periscope in healthcare, health IT, and health IT social media. First I noticed how it could crowdsource actual real-world problems, when it helped me install new hubcaps on my car. I mused about patients and physicians finding support and expertise on live-streaming social video services, while acknowledging privacy issues. Then I saw how @Jimmie_Vanagon actually interviewed one of his patients about EHR workflow! I’ve been on Blab a couple times with @techguy, which is great for just-in-time conversation before a virtual audience. Then, most recently, I saw something that sounds simple, but how it sounds does not do it justice, you’ve got to hear AND see it.

Kathy Nieder, MD (@docnieder), family medicine in Louisville, Kentucky, read and commented on tweets during last night’s #HCLDR tweet chat (HealthCare Leadership, Tuesday’s, 8:30 PM EST). The subject was the importance of listening in healthcare. Now, when the subject is healthcare IT and workflow tech, I’m in there, tweeting like crazy. But sometimes I just want to sit back and, well, listen! So Jimmie and I sort of leaned on Kathy to skim #HCLDR tweets, find the gems, and add context and commentary, all the while cheerfully greeting and conversing with 115 live viewers. Basically, instead of scrolling like crazy through 100s (1000s?) of tweets, and creating typos like an I don’t know what, I relied on someone who listens in healthcare for a living. I hope you’ll listen to at least just a bit of Doc Nieder’s live-streamed video meta-commentary about Twitter commentary about listening in medicine.


If you do, I believe you’ll see great potential for future similar uses of Periscope, Meercat, Blab, and other real-time interactive social live-streaming video services in health IT social media.

Now, whether or not Periscope and similar are “disruptive” or complementary or just additive, I don’t know. But I eagerly look forward to finding out!

Thank you Kathy! BTW, Jimmie, your daughter’s basketball games? (J. participated in K.’s scope while watching his daughter sink hoops!) They’ll only keep you out of the #Periscope tweetchat hot seat for so long… where are you? I’m gonna check the game schedule.

P.S. And wareFLO on Periscope.

Related posts:

My Periscope Tours Of Washington, DC, at

My day job is health IT, but I happen to live in one of the most photogenic, and videogenic, cities in the entire world, Washington, DC. Recently I’ve been ‘scoping (as in Periscope, Twitter’s live-streaming app) DC sunrises and sunsets, plus cool monuments (Washington) and memorials (Jefferson) in between. Some of the best I upload to YouTube and archive here. I created the domain, forwarded it here, and added it to my Periscope profile. I hope you’ll follow me on Periscope at wareFLO and Twitter at @wareFLO. Enjoy!

Here’s a link to all my Katched scopes:

Exterior Jefferson Memorial on YouTube (but with comments and hearts!):

Interior Jefferson Memorial on Katch:

Sunrise over behind Washington Monument, over Reflecting Pool, from Lincoln Memorial steps (hadn’t figured out how to capture comments & hearts, wasn’t using catch, but had almost 1.5K live viewers!)

Sunset behind the Washington Monument from the National Mall, occasionally swiveling to see the Capitol building.

National Health IT Week Is Happening! October 5-9: How High Will Twitter Traffic Go?

National Health IT Week is this week, October 5-9. Lots is happening right here, in Washington, DC, where I live! But, as is the case in general, it increasingly doesn’t matter where things are, because everything is connected in a virtual sort of way.

Take a look at the following graphics (from Symplur). In the first I compare day-by-day Twitter traffic on the #NHITweek hashtag for 2012, 2013, and 2014. In the second I compare impressions, tweets, tweets per this and that, also for 2012, 2013, and 2014. I wonder how high 2015 will go?

Wow! Look what’s happening to impressions. Interesting to note that while tweets and participants approximately doubled from 2013 to 2014, impressions increased by almost a factor of eight.

There are lots of interesting events planned for both here in DC and also online. I’m looking forward to the gusher of informative, sometimes moving and sometimes entertaining tweets on the #NHITweek hashtag. As usual, I’ll be working the National Health IT workflow angle!

If you’re in town, tweet me!

Single Most Important Missing Non-Clinical Data is Time-Stamped Healthcare Workflow & Life-flow Data

I’m participating in today’s #HITsm tweetchat on the topic of Beyond Patient-Generated Health Data – What Non-Clinical Data Matters in Health?

The title of this post pretty much sums up my position. The single most important (currently) missing non-clinical data is time-stamped (semantically interpretable) healthcare workflow data (including patient life-flow data). I’ve written about process-mining of both time-stamped data from both EHRs (link) and the combined interactions of wearables and the Internet of Things (link).

Most data that health IT folks focus on is outcome and efficacy-related. Which is all well and good. But until we between to get a handle on healthcare workflows, that is, instrumenting them and systematically improvement them, healthcare will continue to experience what I call The Workflow Problem.

Here are the tweet chat questions (SDOH stands for Social Determinants of Health):

Topic 1: #SDOH cropping up everywhere as “critical” to understanding #publichealth. What data points do you think most relevant to you?

We, healthcare, health IT, and public health professionals need more data about citizenry “life-flows,” which are basically personal (and professional!) “workflows of life.” I’ve written about the important relationship between healthcare workflows and life-flows here and here (based on a previous #HITsm tweetchat I hosted).

Topic 2: Are there non-clinical data points you would NOT want your#healthcare provider to consider in evaluating your #health? And why?

I would want two things.

  1. All of my healthcare workflow and personal life-flow data is in principle available, de-identified, for research purposes. However, I could specifically opt out of certain workflows/life-flows. Why? None of your business.
  2. All of my identifiable healthcare workflow and personal life-flow data is in principle available to my physician, but he or she must specifically ask for access and I must specifically opt-in to allowing access.

Why? I am comfortable with this balance of contributing to healthcare in general and contributing specifically to my own healthcare. Others may wish to emphasize more or less workflow/life-flow transparency.

Topic 3: What do you think might be concerns about using alternative #data to assess #health risk? #Privacy? #DataQuality? How to address?

My main concern, given that my previous opt-out/opt-in data access strategy is implemented, is data quality. That is why I use phrase “semantically interpretable” workflow data. I’ll refer you to my 2012 discussion of EHR Event Log Maturity.


The general idea, which is that we need to be able to correctly interpret time-stamped events, also applies to time-stamped data from wearables and the Internet-of-Things (and I’ve seen similar discussions in that realm).

Topic 4: Assuming #interoperability solved, how could alternative #data sources be incorporated into #healthcare #workflow, made useful?

Ha! “Assuming interoperability solved…” then how to incorporate into healthcare workflow, in my mind puts the cart before the horse. Solving healthcare’s workflow interoperability problem is an essential prerequisite to solving healthcare’s interoperability problems. See my recent 7,000 word, 5-part, Healthcare IT News series on this subject.