Month: December 2015

Tis the season to predict! Instead of me starting from scratch, I thought I’d explore how workflow tech trends will facilitate and enable health IT trends others predict. I looked at a bunch of 2016 health IT lists of predictions (for example, see @shimcode‘s list) and picked one of the best. Each of the following is adapted or inspired by one of John Halamka’s predictions in My 2016 Predictions For HIT.

1. Population Health Management On Workflow Tech

The population health management solutions that succeed in 2016 will be those that rely on some form of workflow/process/orchestration engine down deep inside. For discussion and examples, see my previous blog posts…

2. Security Threats Require Process-Aware Solutions

Those healthcare organizations that invest in workflow technology, such as business process management, will begin to understand and leverage the numerous ways in which workflow-centric solutions are more secure than data-centric solutions. For a discussion why, see Part 9 of my Health IT Workflow Integration: Whither FHIR?

3. EHR Workflow To Be Redefined

I’d like to predict that EHR workflows will become dramatically more usable, transparent, flexible, and systematically improvable, but progress here will be glacial. No, EHR workflow will be redefined by removing responsibility for workflow management from EHRs, and beginning to manage it with a process-aware, external, interacting and interfaced, layer of workflow-centric cloud-based mobile workflow apps. Of course I’ve written about this! See Part 5 of my 7000-word, 5-series Task & Workflow Interoperability from Healthcare IT News (August 3-7, 2015).

4. Groupware Over Email

Just a few years ago, “Clinical Groupware” was for a short time an extremely popular phrase (See my, Clinical Groupware: A Definition). Unfortunately, the systems described were not particularly good examples of groupware. This overhyped phrase was quickly derided and disposed. Meanwhile lightweight cloud-based groupware for managing small groups took off outside of healthcare. Groupware will indeed re-emerge in healthcare. It won’t be called clinical groupware, but that is exactly what it will be. The difference, this time around, will be that the groupware will be organized around longitudinal shared care plans. You can think of these as similar to work plans, workflow definitions and process models in the workflow management and business process management industries. Except, for the most part, human users will be the workflow engines executing these plans. Groupware organized around workflow plans are part of an ongoing evolution from traditional data-centric EHR and health IT applications, toward more workflow-centric and process-aware systems relying on workflow engines and process orchestration.

5. Market Dynamics Supercede Meaningful Use

“I don’t think a law has become so disliked since prohibition” (re Meaningful Use, Editor’s Corner, FierceEMR, 12/16/15)

Meaningful Use is a spent force, literally. The money has been spent. The carrot has been eaten. All that’s left is the stick. And that stick will be steadily whittled down. While this happens, the market forces that MU displaced for half a decade will return.

In particular, a wide variety of workflow technologies that have been diffusing into healthcare and health IT will regain traction that had been previously lost. The pent-up demand for simple-to-use clinical software, with great workflow, is tremendous. And I’ve lost count of the startups and next-state companies out their aiming to satisfy that demand.

6. Workflow-Centric Apps On Legacy Data-Centric Applications

Whatever else Meaningful Use has accomplished, it has created a multi-billion dollar industry for user interface and data interface workarounds. From speech recognition to mobile apps to EHR-lites, and from EHR database reverse engineering services to industry-wide API-ization efforts, 2016 will host a variety of compensatory technologies. For example, FHIR folks are already talking about my suggestion to incorporate task life cycle status. In particular, we will see many care management workflow tools and platforms, essentially relegating EHRs to plumbing.

7. Commoditized Workflow Infrastructure

Yes, we will see commoditized cloud infrastructures, such as Google and Amazon (both of which host workflow engines in the cloud, by the way). More important, in the long run, we will see new lightweight task and workflow engines in the cloud. Think — IFTTT, Zapier, FlowXO, and Azuqua — only between legacy EHRs and health IT systems (plus new BPM style app development platforms). These process-aware information systems are the key to patients eventually controlling the healthcare workflows intended to serve them (“owning” data is insuffient, and based on a flawed analogy to legal property rights anyway).

8. EHR Featuritis Is Treated

A critical mass of health IT thought leaders is finally coming around to view that less can be more, from a usability, productivity, and ROI perspective. More important, it is the users of these systems who are coming to despise the “feature-itis” afflicting so many EHRs today.

We will see if this particular technical debt (and conceptual debt) can be retired, or whether we will continue to be stuck with too many features and too little benefit. (I know, this isn’t technically a prediction: so, at the very least, EHR “featuritis” will become a thing.)

9. CMIOs As Orchestrators, Not Techies

CIOs will more-and more-orchestrate stakeholders and less-and less dispense technology. At the same time, CMIOs (of which I was one for a decade) will more-and-more focus on workflow and focus less-and-less on technology. Ironically, the reason that CMIOs won’t have to obsess as much about technology is that technology is getting both more powerful and easier to use. In particular, a small but influential group of healthcare organizations will (continue to) invest in a variety of workflow and process orchestration (and choreography) technologies, that will make it possible to focus more on workflow and process, and less on IT. Examples already include Ottawa Hospital and Geisinger.

10. Iron Triangle Continues to Rule Health IT

One thing never changes, though. The Iron Triangle of software development will continue to sit on the Iron Throne. Attempting to bring to market too many features to soon will result in unstable and unusable software. The only way to escape the Iron Triangle is to change the way we create software. However, this will happen so slowly, that, taken in the aggregate and on the average, 2016 will seem a lot like 2015. Nonetheless, some healthcare organizations and startups will continue to pivot from traditional health IT software development techniques toward toward faster-to-market, with more-features-to-sell, workflow-centric low-code application development.

Regardless…

Regardless of whether any or all of my predictions come true during 2016, I can make one prediction with great certainty and enthusiasm:

The healthcare and health IT social media community will be happy warriors in the thick of the fray!

Stephen Fry, an English comedian, actor, writer, presenter, and activist, tweeted about ‘workflow’ to his almost 12 million followers. The hundreds of replies are surprisingly funny and insightful (and sometimes even both at the same time!). Here is Fry’s original tweet followed by some of my favorite replies. (PS TX to @profBPM for RTing this.)

I look at some software and feel so inadequate. I don’t think I’ve ever had a “workflow” and to my shame I don’t really know what one is…

This week’s #HITsm tweetchat (with @amalec) is about FHIR (Fast Healthcare Interoperability Resources) & APIs (Application Programming Interfaces), prompting this blog post. (I often write pre-tweetchat blog posts about subjects in which I am especially interested.) Obviously, FHIR can facilitate health IT workflow by making patient data more accessible. But this blog post is about more than that. It is about representing, creating, transmitting, and leveraging patient task and workflow data through use of workflow technologies such as workflow management systems, business process management, workflow engines, and task management systems. All of these are coming together to create a new layer of task- and workflow-centric care management software leveraging a wide variety of EHR and health IT data sources and sinks.

August 3-7, 2015, in a five-part, 7000-word series (1, 2, 3, 4, 5) that appeared in Healthcare IT News, I outlined what I believe is the first comprehensive framework for Task and Workflow Interoperability in Healthcare (consolidated here). In that series I made a number of suggestions and predictions, some relating to FHIR and task and workflow interoperability. At least one suggestion, representing clinical task status, has indeed been taken up in FHIR online discussions. I’m also interested in seeing what role FHIR will play regarding workflow interoperability. (BTW, if you are interested in the science behind Task and Workflow Interoperability, check out my 2014 post on Pragmatic Interoperability. It had great reviews, which I appended to the beginning of the post.)

Before and after my Task and Workflow Interoperability series, I’ve badgered FHIR folks with questions about workflow. In May I asked the following questions.

So of course I’m not going to miss an opportunity to continue stirring this pot. There are many reasons for, and avenues to, use of more workflow technology in healthcare — usability, productivity, safety — to which we can add interoperability. For example, see my ten questions about FHIR, workflow, and workflow technology (BPM and related). For each of this week’s FHIR/API questions, I’ve adapted my answer to the context I described above. In many cases, I answer a question with a question, though I’m sure you’ll be able detect some of my opinion shining through. 🙂

Topic 1: Are you currently using #FHIR &/or #SMARTonFHIR in production? If so, how? If not, when? #HITsm

My concerns about #FHIR in practical use regard whether plug-in apps retard or facilitate EHR and health IT workflow. Workflows are essentially hardcoded (“hardwired”) into EHRs. Technically, being able access a SMART/FHIR app within EHR workflow, for example, is less arduous than having to switch to a separate standalone app. But it’s still a far cry from the flexible, automatic, transparent, and systematically workflows EHR users need.

So, how will FHIR participate in, and perhaps support, the kinds of orchestrated and choreographed workflows that modern workflow technology brings to the health IT interoperability table? For more on workflow orchestration and choreography, see my Dec 3, 2015, webinar, Wellness Through Workflow.

That said, if we begin to encode task and workflow status into FHIR perhaps we can begin to see a path for diffusion of “process-aware” technology into our current, mostly workflow-obvious systems. I suspect this is an extremely open question. On one hand, if FHIR encodes this information, some systems under development (especially workflow-centric care management systems implemented on top of current data-centric EHR systems) will likely leverage these task and workflow interoperability resources. On the other hand, I’d not like to see FHIR participate in essentially another layer of hardcoded workflow. (See Topic 3, below, regarding this possibility.)

Topic 2: When do you expect #FHIR-based #API ecosystem to be relevant for app developers? Why? #HITsm

When it comes to FHIR I’m on the outside looking in (though I’ve used web services for a variety of purposes). This is why I tend to answer questions about FHIR with related questions about workflow and workflow technology. However, I will point out that task and workflow interoperability need not wait for FHIR. At a strategic level, task and workflow interoperability is *not* about data standards for representing task and workflow status. It is about what academics call “process-aware” information system architectures. Common nomenclature for PAISs includes workflow systems, workflow management system, and business process management. (Though, it must be pointed out, process-awareness is not limited only to these classic application types. Any information system relying on some sort of model of work or workflow, to reason about what needs to happen next to help users do their jobs, are examples of process-aware workflow technology.)

In fact, when I’ve brought up the issue of workflow interoperability with experts and thought leaders in the BPM and workflow tech industry, their reaction has been quite interesting. Yes, they admit they could use more useful task, workflow, and process model-related data standards. However, in almost the same breath they say that BPM and related tech is already intrinsically and architecturally about knitting together workflows among disparate systems and technology. Most modern BPM systems already expose task and workflow design and status through APIs. This is why I argue not to wait for FHIR to “solve” task and workflow interoperability. BPM has already been characterized by a top BPM expert as the “spider in the web” in that it already is used to knit together workflows from disparate systems based on disparate technologies. While FHIR, in healthcare, may come to play an important supporting role here, it’s a mistake to wait for FHIR-capable (heaven forbid Meaningful Use FHIR certified) systems before tackling task and workflow interoperability.

This is, in fact, already happening anyway. Since I published that the Task and Workflow Interoperability series, I’ve been contacted by many individuals and representatives who are doing just this, creating task and workflow interoperable care management systems, without FHIR. (That said, they are tracking FHIR, and will/would/might likely adopt. The point I’m making is that the secret sauce is more in their process-aware architectures, than in a future task and workflow interoperability data standard.)

Topic 4: What novel things can you do with #FHIR & #API in #healthcare that you couldn’t do before? Why? #HITsm

I am optimistic about implications of FHIR for task and workflow interoperability. However I urge a nuanced reading of the task and workflow lack of interoperability situation in which healthcare still finds itself. Simply creating data standards representing task and workflow status will be insufficient to achieving widespread task and workflow interoperability. When it comes to task and workflow interoperability, the fundamental issues are architectural, not representational. Nonetheless, if we increasingly represent more sophisticated concepts of task and workflow in data standards (and not just within FHIR) this is part of a progressive, advancing front of process-aware workflow technology into our healthcare IT industry landscape.

We will, I hope, see two converging trends. On one hand, FHIR-capable health IT systems, including EHRs, will evolve into more process-aware workflow platforms. On the other hand, already sophisticated workflow platforms, especially from the business process management space, will add FHIR to their considerable portfolio of data adaptors (already including a wide variety of web service technologies).

Keith Boone just fleshed out some ideas from Part 2 of my 5-part August 3-8 Healthcare IT News series on Task and Workflow Interoperability (1, 2, 3, 4, 5, and concatenated into single post) in terms of FHIR (Fast Healthcare Interoperability Resources). Which is great, since I’ve been repeatedly bothering smart health IT tweeps with questions I had during a May webinar about FHIR.

Back in May, this year, I suggested FHIR tackle workflow and even suggested the FHIR-W extension, though only half seriously. The important thing is what it does, not what it’s called. In this blog post I take a look at FHIR and workflow. By way of disclaimer, I’ve used, programmed, and extended lots of workflow systems. I’ve generated and consumed a variety of HL7 messages and web services as a programmer. I also have degrees in Industrial Engineering, Artificial Intelligence, and Accountancy, so I used to dealing with workflows, knowledge representations, and cost. But I am not a FHIR expert. So, a large part of this blog post consists of ten questions directed toward the FHIR community. I give what *I* think is the answer (mostly quotes from my August 3-8 series on task and workflow interoperability), from my workflow technology professional perspective. But I’m interested in the perspectives of the FHIR community.

I’l go through my questions one-by-one, plus my own thoughtsabout how *I’d* answer them. This is a wonderful opportunity open a dialogue about the relationship between health IT and health IT standards and workflow technology, such as Business Process Management (BPM). I’ll end with a bunch of embedded tweets about #FHIR and health IT workflow. I hope to start a conversation!

KB: “The fundamental unit of work is a task. This is reflected in many different models of workflow in the various standards that I discussed yesterday. Tasks have a fundamental state diagram that is well described in OASIS Human Task.”

CW: “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.”

CW: “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. [CW, from draft: Search Google Images for a wide variety of task life cycle diagrams for more examples. ] 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.”

KB: “Now, if you want to put these two together, you can manage just about any workflow someone wants to throw at you. Do medication orders for certain substances need to be reviewed before being filled? That’s a task that is part of the medication ordering workflow. Does a positive result need to be confirmed by the lab supervisor? That’s a task that is part of the laboratory testing workflow. These tasks can be associated with their subjects through the subject reference, without ever interfering with the interpretation of the subject resource. If you want to dig into the workflow associated with an order, you could query for workflow.subject = resource, or task.subject = resource, and find the workflows still open, or the tasks as yet uncompleted.”

[CW: BTW, many modern BPM systems already expose both their process models and enacting workflows as object models through APIs. The FHIR folks ought to take a look at a bunch of these, and then perhaps abstract out the best common representational characteristics. See Topic 7 in my ten-part outline below.]

CW: “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.”

CW: “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.”

CW: 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.”

The rest of this blog post outlines the rest of my Task and Workflow Interoperability observations, concepts, and proposals (mostly via quotes), followed by my tweets about FHIR, workflow, and BPM as early as last year.

The following quote is intended to set the stage. What is a workflow system? Why are they so useful?

CW: “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).”

Here’s the rub. EHRs and health IT increasingly represent tasks (they didn’t used to) but these tasks are not yet part of formally represented, executable and human consultable and designable workflows. So, when FHIR moves beyond tasks, to workflows, collections of tasks plus relationships among tasks and properties of those relationships, what, exactly, is there for FHIR to represent? So much implicit workflow is hardcoded, and, it seems to me, unavailable for dynamic representation, that I trying hard to see FHIR getting much farther than task status representation, without one or both to two things happening.

The health IT software stops hardcoding workflows, through use of softcoded workflow and process models and/or

A layer or process-aware software outside of the workflow-oblivious HIT/EHR software assumes this responsibility (role for FHIR?).

CW: “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 also push data to IT systems, and 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.”

3. Do we need to wait for FHIR to tackle workflow before we tackle workflow?

CW: “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.”

4. What’s the difference between task interoperability and workflow interoperability?

CW: “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 upcoming specialist/subspecialist workflow diagram, it’s ten years old!). 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.)”

5. Workflow interoperability involves more than current and past workflows, it involves future workflows.

CW: “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.”

6. What is the potential relationship from FHIR to less-code, low-code, and no-code application development?

CW: “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.”

7. Are there any existing workflow-oriented APIs that FHIR designers should take a look at?

CW:”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.”

8. How might FHIR be used to implement the workflow pattern I outlined ten years ago?

(By the way, the As and the Bs in the diagram and the paragraph do not refer to the same things. Above they refer to steps in workflow. Below they refer to two communicating workflow systems.)

CW: “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)'”

9. Can Workflow Interoperability Actually Be More Secure Than Workflow-Oblivious Data Interoperability

CW: “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.”

10. What is the best way to keep the conversation going among health IT standards communities focused on workflow and the larger workflow tech community?

I’m glad to see health IT beginning to look outside health IT for workflow standards and workflow technology. For many years I’ve been a judge for both of the annual workflow tech awards (BPM and related Case Management). I’d love to see more award applications from health IT (perhaps relying on FHIR!). I’ll point out something, however. I’ve also drilled down on workflow standards work in the workflow industry, and it’s not necessarily as far advanced as health IT standards folks might hope it to be. In fact, when I’ve brought up the issue of workflow interoperability with experts and thought leaders in the BPM and workflow tech industry, their reaction has been quite interesting. Yes, they admit they could use more useful BPM standards. However, in almost the same breath they say that BPM and related tech is already intrinsically and architectural about knitting together workflows among disparate systems and technology.

So, my final question is this. FHIR has obvious utility relative to data interoperability. However, is “workflow” a different animal? Perhaps one less susceptible to data-style workflow standards? My suspicion, probably already long ago telegraphed in this blog post, is that the problem FHIR-based workflow initiatives will face it that it’s going to be difficult to create workflow interoperability among fundamentally workflow-oblivious health IT platforms. That said, my hope is that together with other areas in which workflow tech is diffusing into health IT, FHIR will play its part to move health IT from the to frequently opaque, inflexible, ineffective, and inefficient health IT workflows prevalent today toward more progressive, process-aware information systems that are the opposite.

I imagine that one potential response to many of the above questions is simply, Not FHIR’s responsibility. Which is fine. I’m just trying figure out (and promote) an emerging and evolving process-aware architecture pattern in health IT. On the other hand, others may see FHIR is a key form of workflow representation to make process-aware healthcare information systems possible. And that’s fine to, actually, especially fine! There are certain sub verticals within healthcare with more advanced workflow thinking and technology than others (radiology, speech recognition & language processing, structured messaging, real-time location services are a few areas that come to mind, vendors from the BPM industry itself). It’s great to add another workflow technology “hotspot” to health IT!

The following are just a few of my tweets on these and related topics (mostly the ones with interesting diagrams).