|A 1921 reference to the term Workflow as we use it today, from The Railway Engineer Volume 42|
There's a ton of information packed into that single sentence, so let me parse that for you:
- A lot of people in HL7 are interested in workflow.
- It will be a focal point of the next FHIR DSTU release, presently known as 2.1.
- The material will be developed fairly quickly (at least to support FHIR connectathon testing), and will likely be balloted in the next six months (although unlikely to be balloted in the next cycle due to the short time frame for it).
One of the things we didn't yet agree upon is what we mean by workflow, and it was fairly clear that what a lot of people were talking about addressed workflow at a variety of different levels.
Many workflow standards exist today without even defining what a workflow is. BPMN is a perfect example, as is OASIS Human Task (the standard IHE used to support Cross-Enterprise Document Workflow). Fortunately, the Workflow Management Coalition (WfMC) defines workflow in their glossary as:
The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.This is a fairly straightforward definition, which I will build upon further based on my work with BPMN over the past year or so. Some of the terms in this definition are a bit slanted towards business process automation and workflow management tools, but for the most part what it says can readily be applied to what we are trying to do with workflow in healthcare at HL7 and elsewhere.
From my perspective:
Workflow is the creation of a good or service through the collaboration of multiple parties performing a defined process.
Each component of this definition is essential.
An activity that does not provide some utility (the good or service) is at best boring, and at worst wasteful.
- If only a single party (person, organization or system) is involved, then we don't need to manage it in the same way as when is is performed by multiple parties, at at best our "workflow" becomes a process or algorithm by which a good or service is produced. So without multiple parties, our need to manage "workflow" disappears.
- The defined process is also essential, because that is how we can measure progress through a workflow.
A process is a defined sequence of activities and decisions to be performed by an entity that has a clear starting and ending point, and may have inputs and outputs.
Without clear endpoints, we cannot tell how far along a process is. Without sequence, we cannot ensure that steps occur in the appropriate order when necessary. Decision points allow for alteration or repetition of a process based upon defined criteria [wash, rinse, repeat until done]. Inputs and outputs provide for interim measurable results that show progression through the workflow, and through which quality of the process can be evaluated and managed.
The parties, entities or whatever phrase you might want to apply are simply autonomous actors, things able to do something of their own volition having been appropriately prepared. That can be a person, an organization, or a system, or some entity composed of two or more of those parts.
An activity is a unit of work which can be treated atomically. Activities are performed by people, organizations or systems (or by any composition of the same). Activities may be further broken down, in which case it can be viewed as a "subprocess."
Some processes are comprised of a single activity. When my daughter (either of them) creates a drawing, they may not have a defined process for how they do that activity (arguably, it is very ad hoc). But there is a very clear beginning point (a blank page), and an end-point, which often includes a decision to be made (an artist decision, a filled page, or bed-time, whichever comes first ;-). So even a not very well defined activity can have a moderately well defined process.
The definitions I've provided are clearly informed by BPMN, but are also consistent with other definitions of workflow found elsewhere, going back as far as 1921.
I don't know that it is all that important to get people to agree with MY definitions, so long as we agree to work from some definition. I think making sure that we understand the distinctions between the concepts associated with (in my definitions) the terms workflow, process and activity, we'll be able to move forward successfully.
One of the important distinctions that Lloyd made in the meeting is that Resources aren't activities. There is a difference between "Resource" and "Service", in that a resource can describe what needs to be done, e.g., a request or order. The service actually executes the activity, and as a result may alter, create, delete or access other resources. What FHIR operates on today are resources, and it includes the basic functions Create, Read, Update and Delete on those resources. Those familiar with security ontologies will realize is that the missing action from FHIR resources is execute, and that is what services enable, the execution of a process. And enabling collaboration (through FHIR) among multiple processes will result in integrated workflow, for perhaps the first time in healthcare.