Cross Enterprise Document Workflow

Automating workflows within an enterprise is very different from automating them across enterprises. Within an enterprise one can expect a common platform for workflow automation. Processes can be well-defined, controlled and responsibilities assigned for management and escalation. Think about what you go through to purchase a piece of hardware or software in your own environment. Across enterprises it gets quite a bit more complicated. A common platform is hardly likely. Obtaining agreement on processes is not easy, and can require quite a bit of manual intervention. Think about what it takes to approve a new supplier for goods and services. In most businesses though, dealing with a new supplier still works because there are well defined inputs and outputs at the interfaces between the organizational workflows. You issue a PO, the supplier responds with a well defined package of goods or services and an invoice. When all goods and services are delivered, you pay the bill.

Imagine how complicated cross-enterprise workflows would get in your organization if your IT department required detailed information about the steps used to diagnose and repair a broken laptop that it sent out to someone else to repair, and furthermore wanted to automate the workflow across the two organizations to keep track of status. Some will tell me that they even manage this, and I'm certain they do. Usually with one or two other organizations that they have developed a pretty strong business relationship with. Scale that up to hundreds of other organizations or more, and I can assure you that it isn't done.

But in healthcare, these sorts of workflows happen all of the time. And healthcare providers need to track and route what is happening. Enter Cross Enterprise Document Workflow (XDW). The purpose of XDW is not to "automate" workflows within or even across enterprises. Instead, it's about tracking what happens, or should happen in the next few well-defined steps, and being able to look inside any "sub-workflows" initiated.

Think about a simple referral. Provider detects finding, refers patient to specialist. Specialist examines patient, treats patient and report back to the orginal provider. Getting a bit more complex, the specialist has an additional finding that he/she sends off to someone else (e.g., pathology) to look at. That result is reported back to the specialist. Because of that result, additional treatment (e.g., surgery) is needed. Complications due to surgery require additional treatment (e.g., PT) for recovery. And so on.

Consider that each provider involved in care may have a referral network that includes hundreds of other healthcare providers and organizations. Consider also that the patient may decide to use other healthcare providers that aren't already known to the originating provider.

So we need to think about this differently. The function of workflow automation in healthcare needs to support tracking what is happening to a patient without requiring a "definition" of the workflow to exist up front. XDW allows a healthcare provider to initiate a task, provide inputs in the form of documents, and to track the status of a task, and look at the "outputs" (again, documents). A provider that is working on a task can "claim ownership" of it, generate outputs associated with it (e.g., diagnostic results or consult notes), and initiate new tasks to ensure the completion of the workflow that was initiated by the initial request for consultation.  As the workflow proceeds, it can take new and unanticipated directions without any pre-coordination being required by the initiating provider.

Sounds like cool stuff.