Workflows are made up of sequences of tasks, consuming resources, and achieving goals. So it makes sense that workflow interoperability requires task interoperability. It's classic systems engineering. Solve the subproblems (tasks), and then solve the relations among the subproblems (workflow), to solve the problem. I'm reminded of the old saying; how do you eat an elephant? One mouthful at a time!
A task is a "logical unit of work that is carried out as a single whole by one resource" (Aalst & Hee). In a medical practice, tasks include escorting a patient to their exam room, asking about current medications, conducting a physical exam, collecting a specimen to be sent to a clinical laboratory, sending the specimen to the clinical laboratory, reviewing results from the clinical laboratory, contacting the clinical laboratory because you've not yet received the results, and so on ... if you are a hospitalist, I'm sure you can easily list a hundred typical hospital tasks.
Task interoperability is visibility, to humans and machines, of tasks and their status, context, and properties from one healthcare organization into another. Status includes such task states as Ready, Assigned, Expired, Forwarded, Finished and so on. Properties are aspects of tasks that don't change during task and workflow execution. Examples include who or what is qualified to perform a task or prior estimates of cost-per-minute of accomplishing a task. Context includes aspects of tasks that do change, according to, well, workflow context. Examples include who owns a task, who was a task forwarded from and to, in what workflow is a task being accomplished, or from what workflow definition was a task activated.
[Part 1: Achieving task and workflow interoperability in healthcare.]
What does it mean for a task in one healthcare organization to be "visible" in another healthcare organization? That depends on who, or what, is looking. Just as how many data and file formats can be designed to be both machine and human readable, task formats (essentially data about tasks) can be both machine and human readable. A task is visible to a human if they can find, retrieve, read, and make sense of the task description. A task is visible to a machine if the machine can find, retrieve, read, and do something useful with that task description, from displaying it to humans to archiving some information to triggering other tasks.
Task interoperability is impossible unless tasks are represented in the first place. So we have to figure out how to represent tasks, and then find, view, and process these task representations.
Years ago, I took a course in knowledge representation (KR) as part of my MS in Intelligent Systems (Artificial Intelligence). There are many kinds of representations. In this case, a representation is a set of statements about a task. These statements can be added or deleted. KR folks (and computer programmers in general) often speak of properties and values. An apple has a Color property. For a specific apple, the value of the Color property might be Red (or Yellow, or whatever). We pick a specific apple out of a universe of possible apples by assigning a unique identifier, such as "2f39fnv9483h" (I just typed that a random. If I were to refer to a different Apple, I'd need to make sure I don't accidently use the same identifier, but that is very easy in a computer).
The same goes for healthcare tasks. For a given patient of mine, from behind hospital walls, I'd like to retrieve a list of IDs. (I am of course speaking in the voice of a physician-programmer. Physician-non-programmers just want a list of human-readable descriptions, plus ability to do something useful with them, which is where machine-readable comes in.) Each ID is uniquely associated with a specific enacted task. In the workflow technology world, "enacted" workflow means "executed" workflow. It is analogous to the difference between an unexecuted computer program versus the thread of execution of that program while being executed. Workflow definitions are like the former. Enacted workflows and tasks are like the later.
Once I have a list of task IDs, for each ID, I'd like to access whatever context and property values are relevant to my current goals. For example, I'd like to see a list of sensible (to me) names of clinical tasks. These names could simply be strings stored in each clinical task's Name or Description property. Another task aspect I'd be interested in, at least for some tasks, would be Status. Show me all the completed tasks for my patient. Then for some of those completed tasks, show me patient data relevant to the tasks, such as data generated during accomplishment of the task. An example might be a clinical lab result or radiological image interpretation. Remember, I am just using these workflows as illustrations. I am not called for particular workflows to become standard workflows. What I am calling for is your ability to create and modify whatever workflow you need to do your job most effectively, efficiently, flexibly and enjoyably.
The layer of task representation is essentially part of a navigational user interface. Instead of a clinician interacting directly with the underlying data, clinical task status, context, and properties are used to find, filter, and interpret data. Assume I work for a health insurance company. I might be interested in tasks that are ready, but not yet assigned, to make sure they are covered before they assigned. Assume I am a hospital management engineer. I'd be interested in time-stamps, for purposes of spotting bottlenecks and rework. Data associated with tasks is a goldmine, not just for users within a healthcare organization, but users in other healthcare organizations too.
Health IT is on the cusp of beginning to implement task interoperability. Startups are beginning to monitor and route care transition events. These are tasks at the boundaries of health organizations, such as hospital admission and discharge. However, there are many other tasks behind the walls of hospitals and other healthcare organizations. Folks say to me, what do I care about what goes inside someone else's healthcare workflow black box? To which I reply, you should. Providers need to better understand health plan payer internal workflows. Health insurers need to better understand provider workflows. And both need to better understand patient workflows, AKA life-flows. In fact, across many industries a trend is to make enterprise tasks, workflows, and processes more transparent, to make them visible to external customers and partners, using social, mobile, and cloud technologies, and then to systematically improve customer experience with analytics.
The trend toward explicitly representing, manipulating, and sharing clinical tasks, and using these representations to automatically trigger valuable human and machine workflows is beginning to take off inside healthcare organizations. These lightweight, mobile and (secure) social-like apps get data from older systems, including EHRs, and get data from human users, because these users get value back from entering and sharing clinical task data. Given that changes in admission and discharge task statuses are beginning to be shared, we are just a step or two away from sharing other tasks deeper within healthcare organizations.
An obvious place to represent healthcare tasks is in some future version of FHIR (Fast Healthcare Interoperability Resources). However, for purpose of this happy path into a future of workflow interoperability, I'll abstract away from specific transport and data standards. The technology is already here, (a variety of web service technologies and data formats) to create task interoperability. In other words, don't wait for a standard. As a practical matter, I'd rather deal with a half a dozen well-designed and well-documented healthcare task APIs (Application Programming Interfaces) than wait for some future health IT task standard promising nirvana. If your APIs generate value, someone will come along and aggregate them anyway. That said, keep an eye on any nascent healthcare task interoperability standard. The discussions and communities of practice can be excellent educational and networking resources.
This five-part series could have been titled "Getting To Task Interoperability And Then From There To Workflow Interoperability: Healthcare Workflow Silos Unite!" but that would have simply too unwieldy. We just covered, "Getting To Task Interoperability." Now we need to cover, "Getting To Workflow Interoperability."
In the next installment, I'll dive deep into workflow interoperability.
