I first started playing with workflows standards in the late 90's, before I ever got involved in Healthcare. Digital publication was (and still is) all the rage, but back then it was only for high-end users, and there was a good deal of workflow involved that crossed multiple organizations. It was a critical concern of many customers of the XML database product I worked on.
If you wanted to publish an article, you might need some photos or graphics to go with it. You needed to acquire those, negotiate rights, develop and approve content, layout, et cetera, before the article ever went live. You may even have needed some time to covert the article from a proprietary format to a standard format using XML.
Back then there were numerous workflow engines (I recall one from Toshiba that I investigated fairly deeply), and also some standards. The Workflow Management Coalition (WfMC) had been around for a bit (about 5 years) and had some workflow APIs it had evolved. A number of workflow engines even supported those APIs. It was like a DOM for workflow, except that back then we had to interface to those APIs using CORBA, because REST hadn't been invented yet. There were also a number of other workflow products, including a family of products described as group-ware, the most famous of those had a darling little name that we morphed into an epithet describing its most egregious failure, we called it Bloats [Lotus Notes].
We are now looking into workflow in FHIR, but I think at the moment only superficially, assuming that there are some common structures and capabilities built into (mostly) ordering and fulfillment processes. Here's where I'd advise taking a step back from "Healthcare IT", and look at what is already available in existing IT. But to do that, we probably need a brief history lesson on what already exists, and its purpose as it relates to workflow.
WfMC created XPDL and Wf-XML, but these weren't even extant at the time I was looking at their efforts. Instead, what I had been looking at was the Workflow Client Application (Interface 2) Application Programming Interface, otherwise known as WAPI. This specification, circa 1996 describes the "things a client needs to do" to integrate with a workflow engine. We want to integrate workflows in healthcare, not integrate with a workflow engine, but this is a pretty good description of some of the functional capabilities we need to support.
OASIS formed the BPEL workgroup sometime in 2003, to develop Business Process Execution Language. Object Management Group (OMG) developed BPMN, and eventually BPMN 2.0 to be the format for Business Process Modelling Notation. All of this stuff is fine, but the reality is that it doesn't meet the needs for workflow implementers very well. XPDL, BPEL and BPMN make it possible to describe workflows and execute workflows, but they don't really help much in enabling the capture of essential data for workflow management. There's a whole passel of discussion in the workflow community on Choreography vs. Orchestration, but the reality is that it doesn't matter to us, both describe execution, which is a step beyond where we want to be in FHIR at first.
OASIS Human Task does support some of the information capture needs. If you look at Human Task and many of the operations it supports, you'll see a great deal of overlap with WAPI described above. Human Task defines a WSDL for its operations; an API or set of functionality that systems supporting workflow need. Where Human Task succeeds is in describing the data that is needed to manage a workflow. Where it mostly fails is in the heavyweight SOAP/WSDL based approach used to manage that workflow.
Human Task became the basis for IHE's Cross Enterprise Document Workflow (XDW) [now in Final Text form!] IHE's XDW takes that description in Human Task and turns it into the closest thing to a workflow resource that we have today: an XML Document that becomes a repository for a specific workflow instances state. Updating that document updates the state of the workflow. The biggest challenge that XDW implementers have is in the grain size. It's off by one. What they want to update is the task in a workflow, not the entire workflow.
So, take a look at the various references for workflow here. Next time I'll explain what I think we need to do with this in FHIR, and how it will enable healthcare workflows in Healthcare IT.
Keith
If you wanted to publish an article, you might need some photos or graphics to go with it. You needed to acquire those, negotiate rights, develop and approve content, layout, et cetera, before the article ever went live. You may even have needed some time to covert the article from a proprietary format to a standard format using XML.
Back then there were numerous workflow engines (I recall one from Toshiba that I investigated fairly deeply), and also some standards. The Workflow Management Coalition (WfMC) had been around for a bit (about 5 years) and had some workflow APIs it had evolved. A number of workflow engines even supported those APIs. It was like a DOM for workflow, except that back then we had to interface to those APIs using CORBA, because REST hadn't been invented yet. There were also a number of other workflow products, including a family of products described as group-ware, the most famous of those had a darling little name that we morphed into an epithet describing its most egregious failure, we called it Bloats [Lotus Notes].
We are now looking into workflow in FHIR, but I think at the moment only superficially, assuming that there are some common structures and capabilities built into (mostly) ordering and fulfillment processes. Here's where I'd advise taking a step back from "Healthcare IT", and look at what is already available in existing IT. But to do that, we probably need a brief history lesson on what already exists, and its purpose as it relates to workflow.
WfMC created XPDL and Wf-XML, but these weren't even extant at the time I was looking at their efforts. Instead, what I had been looking at was the Workflow Client Application (Interface 2) Application Programming Interface, otherwise known as WAPI. This specification, circa 1996 describes the "things a client needs to do" to integrate with a workflow engine. We want to integrate workflows in healthcare, not integrate with a workflow engine, but this is a pretty good description of some of the functional capabilities we need to support.
OASIS formed the BPEL workgroup sometime in 2003, to develop Business Process Execution Language. Object Management Group (OMG) developed BPMN, and eventually BPMN 2.0 to be the format for Business Process Modelling Notation. All of this stuff is fine, but the reality is that it doesn't meet the needs for workflow implementers very well. XPDL, BPEL and BPMN make it possible to describe workflows and execute workflows, but they don't really help much in enabling the capture of essential data for workflow management. There's a whole passel of discussion in the workflow community on Choreography vs. Orchestration, but the reality is that it doesn't matter to us, both describe execution, which is a step beyond where we want to be in FHIR at first.
OASIS Human Task does support some of the information capture needs. If you look at Human Task and many of the operations it supports, you'll see a great deal of overlap with WAPI described above. Human Task defines a WSDL for its operations; an API or set of functionality that systems supporting workflow need. Where Human Task succeeds is in describing the data that is needed to manage a workflow. Where it mostly fails is in the heavyweight SOAP/WSDL based approach used to manage that workflow.
Human Task became the basis for IHE's Cross Enterprise Document Workflow (XDW) [now in Final Text form!] IHE's XDW takes that description in Human Task and turns it into the closest thing to a workflow resource that we have today: an XML Document that becomes a repository for a specific workflow instances state. Updating that document updates the state of the workflow. The biggest challenge that XDW implementers have is in the grain size. It's off by one. What they want to update is the task in a workflow, not the entire workflow.
So, take a look at the various references for workflow here. Next time I'll explain what I think we need to do with this in FHIR, and how it will enable healthcare workflows in Healthcare IT.
Keith
0 comments:
Post a Comment