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

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

Medical Innovation & Healthcare IT Challenges: A Trip Report (Over 200 Viewers of Cybersecurity Hub Periscope!)

[I wrote this trip report while thinking about today's #HITsm tweetchat, Top 10 Challenges for Healthcare Executives. In my opinion, the top challenge for healthcare executives is managing innovation. In fact, all five #HITsm topics easily pivot to innovation in healthcare. At the end of this post I've (only slightly) rewritten them to emphasize the importance of innovation.]

Imagine combining the 40 best annual HIMSS conference presentations and the 2000 most interesting attendees and speakers. Mix in lots of cool science and conversation about innovation. Then add same night opening games for 2016 NBA Champion Cavaliers (before which they received championship rings) and baseball’s World Series (Indians versus Cubs). Then add robust social media (#MIS2016 on Twitter, over 73 million impressions). You might, might begin to approach the vibe at last week’s 2016 Medical Innovation Summit in Cleveland.

When I was CMIO for an EHR vendor, every time I came back from a conference I’d email around a detailed “trip report”: with whom I spoke, industry trends, specific market intelligent, impressions of demos of competing products, that sort of thing. This trip report is more about local color and vibe. First are ten tweeted photos and a bit of commentary. But there are some “deep thoughts,” to which you are welcome to skip! (Compromise? Slowly scroll though the photos and videos while admiring them?)

In no particular order, here are my top ten highlights.

1. Touring the HIMSS Cybersecurity Hub with question-answering viewers on Periscope.

180+ viewers! (and still rising)

2. “Chuck, I hope this book inspires your love of workflow!” Martin Harris, MD, CIO, Cleveland, Clinic, author, IT’s About Patient Care, McGraw-Hill, 2017.

3. #GoTribe!

4. More than 73 million Twitter impressions on the conference hashtag #MIS2016

5. My annual selfie with John Sharpe

6. Facing fear using virtual reality in the operating room

(I wasn’t even wearing the VR googles and my forehead began sweating during VR simulation of a cardiac arrest!)

7. Experiencing at first hand the raw force of Jonathan Bush…

8. Meeting my hero, nurse maker (maker nurse?) Anna K Young. Here is a link to her TedMed video and Wired article.

9. “Innovation of systems & processes are as important as innovations in pure tech” Cleveland Clinic, Chief Clinical Transformation Officer, Dr Michael Modic

This was a common refrain, as in innovating workflow around medical devices is as important as medical device innovation.

10. Beautiful fall colors on the way to the Medical Innovation Summit from my home in Columbus, Ohio.

Courtesy of Google Glass (which, by the way, will be back, better than ever, however an NDA prevents me from divulging more…)

OK, a series of tweeted images hardly constitute systematic and incisive analysis of the 2016 Medical Innovation Summit. So I will close with these thoughts.

As I mentioned at the beginning of this post, in the old days my trip reports were detailed and blow-by-blow. Truth-be-told, I not sure how many of my colleagues actually read my entire lengthy emails. So I’ll close with more of rumination on innovation in medical technology and health IT.

The name of the conference was Medical Innovation Summit. A synonym of “innovative” is “creative”. I studied computational models of creativity during my graduate degree in artificial intelligence. Every student of creative starts with Wallas’s four stages of creative thought:

  1. preparation,
  2. incubation,
  3. illumination, and
  4. verification.

The Wallas model has been endlessly elaborated, into five, six and more stages. But I like original model the most. During preparation we immerse ourselves in a topic. We learn everything we can. We turn over every rock, figuratively. Eventually, we run out of rocks to turn over, and then we enter a frustrating phase during which we think nothing is happening. Every creative artist, novelist, and scientist has experienced this funk. However, incubation cannot be rushed. Under the surface, subconsciously connections are being made. Finally, often suddenly, a lightbulb goes on over our head. What actually turns it on can seem like a random environmental cue. This is illumination. But having a bright idea is insufficient. It has be vetted and turned into something useful and sustainable. An actual piece of art or fiction. A successful experiment and then, perhaps, eventually, a disruptive industry technology.

I thought of the Wallas model of creativity during the MIS2016 session, The State of Healthcare Innovation. Someone, perhaps from the audience via the MIS2016 mobile app, asked “Why can we get money out of ATM globally but not share med info?”

Panelists went down the line, addressing this question. Then Carla Smith (EVP, HIMSS) pointed out that the first ATM was installed at the beginning of the seventies. And that it has taken almost a half a century to get to the network of ATMs we take for granted today.

Let’s apply the Wallas model of creativity to an entire industry, AKA innovation in health IT.

I think some current frustration with the state of health IT (you know, with interoperability, usability, safety, patient engagement, and so on) is because we are collectively in the important but frustrating preparation/incubation phase. While progress may seem slow, under the surface, under our collective radar, so to speak, important connections and synapses are forming. At venues such as the Medical Innovation Summit and the HIMSS annual conference, and in between, in startups and hubs and pilots, we see illumination. Bright ideas click “ON” (like those figurative cartoon lightbulbs over our heads), but then must be vetted and designed and deployed.

Umm, I think that’s about as far as I will drive that particular analogy, between a four-stage model of human creativity and health IT innovation… But I would like to point the widely displayed logo slash symbol at the Medical Innovation Summit: a lightbulb!

See you today’s #HITsm tweetchat! (every Friday, noon, EST)

HITsm Topics (emphasizing innovation)

Topic 1: What do you think are the main issues and concerns facing healthcare organizations? #HITsm

#1 Innovation

Topic 2: What are some ways to identify and prioritize challenges and issues specific to (innovation in) your healthcare organization? #HITsm

Topic 3: How can you establish an environment that communicates the importance of change innovation and welcomes opinions and new ideas? #HITsm

Topic 4: What are some ways to inform & engage others – in your firm & broadly across industry – in large transformational (AKA innovative) initiatives? #HITsm

Topic 5: Why do you think healthcare innovation lags that of other industries? And what can be done to ameliorate that? #HITsm (this topic didn’t even need to be rewritten!)

@wareFLO On Periscope!


Posted in social-media | Leave a comment

Actuarial Science, Accountable Care Organizations, and Workflow

Today’s Actuarial Challenge tweetchat is a welcome opportunity to ponder the future of actuarial science, health IT, and accountable care organizations, in a single blog post.

For background, see:

How will Accountable Care Organization (ACO) IT look in 10 years? How will Actuarial Science fit into that infrastructure? How can workflow technology get us there?

I am not an actuary, but I did get Accountancy and Industrial Engineering degrees (on the way to med school!). In doing so I studied fundamental Actuarial Science concepts: economic risk, random variables, time value of money, and modeling and optimizing stochastic processes (stock and trade for actuaries). Eventually I designed and deployed health IT software. But I’ve kept an interest in financial security systems. From Wikipedia:

“A financial security system finances unknown future obligations. Such a system involves an arrangement between a provider, who agrees to pay the future obligations, often in return for payments from a person or institution who wish to avoid undesirable economic consequences of uncertain future obligations.[1] Financial security systems include insurance products as well as retirement plans and warranties.[2]“

Here are my ten-year “What Will ACO IT” Look Like” predictions:

1. ACO enterprise SW will be ‘process-aware’ (workflow engines executing declarative process models). It will be essential for turning actuarial insight into automated ACO workflows, in almost real-time.

2. Stochastic simulation will literally be built into ACO enterprise software. Simulation is already built into many Business Process Management (BPM) workflow platforms. Actuarial simulation and workflow simulation will increasingly complement and even merge.

3. Virtual ACO enterprises will be built across workflow interoperable healthcare subsystem organizations. For extended discussion of task, workflow, and pragmatic interoperability, see my five-part series

4. ACOs will know exactly how much each service line (chronic Dx, procedure, etc) costs. Comprehensive ACO workflow IT platforms will seamlessly drive sophisticated event-driven activity-based cost management systems. Other industries know exactly what their smartphones and vehicles cost. Healthcare needs to do so too.

5. Virtual ACO enterprises will systematically optimize ROI on collections of targeted workflows. If each of predictions 1-4 become true (workflow tech infrastructure, embedded stochastic simulation, pragmatic workflow interoperability, and virtual ACOs), ACO will become truly intelligent learning healthcare systems.

Relative to intelligent learning systems, I should mention another of my degrees, an MS in Artificial Intelligence. Artificial intelligence, machine learning, workflow technology, business process management, and data pipeline management systems are increasingly leveraging each other’s strengths, and in some cases, even merging. While process-aware workflow technologies will increasingly form virtual ACO IT infrastructure, these workflows will be highly “tunable.” The additional data made possibly by workflow technology about what happened when will increasingly feed into stochastic models, which, in turn, will be essential for systematic improvement of workflows both driven by, and generating the data. This is the “intelligent learning” to which I am specifically referring.

I also have a whole bunch of questions! For example, what, exactly, does “stability” mean? (Probability that premiums will be sufficient to claims cash flows?) What is the current state-of-the-art for actuarial simulation? Are “state models” (as in, Markov models of disease progression) routinely used in ACO actuarial calculations? And so on.

For now, I’ll just close with some thoughts on the intersection among actuarial science, accountable care, and my favorite topics: healthcare workflow and workflow technology!

What is the connection between workflow, workflow technology, actuarial science, and accountable care?

I’ve taken entire courses in workflow. I’ve looked at hundreds of definition of workflow. The following is what I eventually “settled” upon.

“Workflow⁰ is a series¹ of steps², consuming resources³, achieving goals⁴.”

⁰ process
¹ thru graph connecting process states (not necessarily deterministic)
² steps/tasks/activities/experiences/events/etc
³ costs
⁴ benefits

Workflow technology is any technology that represents workflow as a model, explicitly (declaratively) or implicitly (neural network weights), and operates on the model/representation to automatically execute workflows or automatically support human execution of workflows. Academic workflow researchers call these “process-aware information systems.” The best know PAIS are BPM systems. However process-aware workflow tech is rapidly appearing in IT systems, such as Customer Relationship Management systems (CRM) and data and language “pipeline” platforms not typically referred to as BPM systems.

If one modifies my definition of workflow, though within my subscripted limits, to…

Process is a series of events, consuming expected resources, achieving expected benefits

…you arrive at a stochastic process closely resembling actuarial science’s generalized individual model (page 35 in Fundamental Concepts of Actuarial Science).

During my student days, we spent a lot of time estimating parameters and distributions, and then predicting behaviors of these stochastic processes. Sometimes we did so analytically with complicated equations (Markov Models). Sometimes we fell back on computer simulation (Monte Carlo).

A quick review of actuarial science literature indicate many of these same techniques are used today. I found questions about them on actuarial science exams and interesting papers by actuarial science researchers. I’ve appended links to some examples at the end of this post.

By the way, I believe my five predictions are incredibly relevant to a very topical topic: MACRA’s “virtual groups.” So I’ll close with this quote (stretches in italic due to me).

Virtual Groups

“…the MACRA Proposed Rule will likely put pressure on solo practices and small group practices, while favoring large groups.

Fortunately, the MACRA legislation offers a possible “salvation” for solo practitioners in that the rule allows for the formation of “virtual” groups. This would presumably enable smaller practices to band together (virtually) and to function as a larger group, spreading risk and potentially taking advantage of APMs and other benefits the MACRA legislation offers larger practice groups.

Unfortunately, CMS has decided that virtual groups, while mandated by law, were too complicated to set up. Consequently, it is proposing to delay the implementation of virtual groups until 2018.

What is especially ironic about this is that CMS states that virtual groups will be delayed due to the difficulty of establishing an efficient and effective “technical infrastructure” by the beginning of the 2017 performance period. Yet (of course) providers and software vendors are granted no such relief, even though they too will have “technical infrastructure” needs that will have to be enabled in their EHRs in that same restrictive timeframe.

The net result is that without the relief of virtual groups, the majority of small and solo practitioners may be even more unlikely to meet the MIPS standards during 2017, and are more unlikely to avoid penalties being assessed in 2019.”

What’s my point? Well, my predictions are ten years out, and therefore not likely to benefit small medical practices next year. However, I do think the concepts I invoke — virtual ACOs, pragmatic workflow interoperability, true costs, intelligent learning systems — are highly relevant in the long run. Therefore, even when fighting short-term fires, we need to keep our eye on long term goals, and paths to those goals.

Relevant to the #ActuarialChallenge, virtual intelligent learning ACOs will require actuarial science knowledge and experience to be successful. But, I also firmly believe, actuaries must leverage workflow technology to achieve the kind automatic, transparent, flexible, and systematically improvable workflow necessary to merge actuarial science secret sauce directly into ACO IT infrastructure.

@wareFLO On Periscope!


P.S. Here are some links and resources I consulted while writing this blog post.

Fundamental Concepts of Actuarial Science (fantastic introduction to AS if you hate math)

Introduction to Actuarial Science (edX course: videos, but also PDFs, ends with Monte Carlo simulation of life insurance)

Health Insurance: Basic Actuarial Models (Amazon, heavier going, but Fundamentals monograph and Intro edX course are good prereqs)

Society of Actuaries 2014 Exam MLC Models for Life Contingencies (includes questions about multiple state models)

Actuarial Calculations Using a Markov Model

Critical Review of Stochastic Simulation Literature and Applications for Health Actuaries

Stochastic Process (Wikipedia)

Constructing Probabilistic Process Models based on Hidden Markov Models for Resource Allocation (process mining to estimate state model transition probabilities)

Mathematical modelling of social phenomena

An actuarial multi-state modeling of long term care insurance

Estimation of disease-specific costs in a dataset of health insurance claims and its validation using simulation data

How Predictive Modeling Is Helping Employers Gain Control of Health Care Costs

Stochastic Modeling in Health Insurance

The ACO Conundrum: Safety-Net Hospitals in the Era of Accountable Care(Lean Six Sigma to ID and eliminate inefficient processes)

CMS ices reinsurers out of an ACO program

“The group practices were unable to track and manage the fluctuations in risk, and many went out of business. In recent years, organizations have tried to develop better cost tracking systems”

Multiple State Models

Actuarial Uses of Health Service Locators

Estimation of disease-specific costs in a dataset of health insurance claims and its validation using simulation data


Transforms the Insurance Industry with Cloud Modeling Platform

Posted in social-media | Leave a comment

2016 National Health IT Week Blab, I Mean Firetalk, Was Fun! 23 Participants, 50 Comments (w/@MichaelGaspar)

For the second year in a row I hosted a group social video chat. Last year it was Blab (Replay Mid National Health IT Week Blab: Many Thanks to Participants!), this year Firetalk. We had 23 participants, from all of the world, including New Zealand and India. For a bit more information about how well Firetalk replaces Blab, Firetalk Group Social Video Chat as a Replacement for Blab in the Health IT Social Media Community.

If you join Firetalk, please create a channel and publicize it (on Twitter, obviously) so we can all subscribe to each other! I’m at

@wareFLO On Periscope!


Posted in social-media | Leave a comment