Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Monday, April 6, 2015

A Domain Model for Workflow

To your right is the model we produced on last Friday's IHE call discussing where we are going with the BPMN white paper.  This is a simplified domain model that we produced to help explain where the BPMN workflow definition fits in, and which shows other data objects are used in a workflow.

We started with a use case familiar to one of the IHE members on the call, the need to manage care for patients via regional programs.  In his case, it was national programs in the third world, but another participant who contributed to this model was clearly dealing with a US-centric care management model as well.

We have in this model a care management program which is defined by guidelines.  Patients are enrolled in this program, and are the subject of care plans, which customize guidelines for each patient based on certain criteria.  These guidelines reference a variety of different workflows that are defined: Patients are screened, tested, diagnosed, treated and followed up on, each of these separate steps potentially involving multiple parties.

To enact the care plans, the Care Management program can instantiate or invoke a workflow on an enrolled patient, making the patient the subject of this workflow.  The workflow itself is compesed of multiple tasks, which have various data elements as inputs and outputs, the output of one task quite possibly being the input to the next one.  The care plans themselves have outcomes, both potential (goals) and actual, and these outcomes are also measured by the various data elements.

This domain model addresses the work that providers need to do on behalf of patients, and exposes the data at the level of granularity where it needs to be readily accessed in the various interoperable components.

I don't think there are any big surprises in this model.  I'm certain people could argue for different clarifications, for example, data elements associated with inputs, outputs and outcomes certainly also relate to data element definitions which appear within either the guidelines or the workflows that support them, or in the goals that show up in care plans.  If you are focused on these aspects of the system, I would agree, you probably need to go a bit deeper.  I'm still focused on what's in the dotted lines, and so think I have enough detail to address that.  HL7 FHIR Resources could readily address data elements, but what is missing for me now, and for workflow in generate in healthcare, is a ready mechanism to represent the Workflow and Task boxes.  This will be one of the areas that I'll be talking to folks in the HSI workgroup in HL7 about in the coming weeks and we'll see where this goes.



Post a Comment