-
1. Will FHIR Hardcode Workflows? (Not Tasks, Workflows!)
-
2. Can FHIR Encourage More Process-Aware Health Info Systems?
-
3. Do We Need To Wait For FHIR To “Solve” Healthcare Workflow?
-
4. Difference Between Task & Workflow Interoperability? Implications For FHIR?
-
5. What About Design-Time Workflow Interoperability?
-
6. How Can FHIR Speed Health IT Application Development?
-
7. Are There Any Existing Workflow API Models FHIR Should Look At?
-
8. How Might FHIR Represent & Support This Specialist/Subspecialist Workflow?
-
9. Can FHIR (or Otherwise) Workflow Interoperability Be More Secure Than Workflow-Oblivious Data Interoperability
-
10. How Do We Keep Conversation Going Between FHIR & Workflow Tech Communities?
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 , 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 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).”
1. Can FHIR represent healthcare workflow without hardcoding healthcare workflow?
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?).
2. Can health IT workflow standards encourage adoption of process-aware BPM-like workflow platforms?
From Part 4 of my Task and Workflow Interoperability series…
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?
10-year-old diagram from my 2005 HIMSS05 presentation…
The “Invoke,” “Monitor,” “Control,” and “Get Result” cross-organizational workflow pattern…
(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).
