Building IHE XDW Workflows

I've been working on a few XDW workflows lately, mostly dealing with variations on eReferral and Transfer. In developing these, it became pretty important to understand how the workflow itself works.  We've documented it in general using BPMN.  Ideally, what I would like to do is be able to represent the workflow description entirely in BPMN with a few annotations describing some key pieces of metadata about the workflow.  I haven't quite gotten there yet, but am pretty close.

What I have figured out is that the key to defining the workflow is a single spreadsheet table with the following columns:

• Trigger Event
• Responsible Actor
• Conditions
• Action
• Workflow Task
• Task Status
• Task Owner
• Input Documents
• Output Documents
• Notify
• Notes

The trigger event takes the form of "Workflow Task - Task Status", as in Request - COMPLETED, or a narrative description of an event, such as "Referral Response timed out" (e.g., indicating a maximum duration for a response was exceeded).  This tells you what initiates the activity.  The next two columns tell you who and when.  The responsible actor column is the workflow participant that has to do something, and the conditions tell you if there are additional preconditions that must be met.  For example, if the maximum time for a response timed out, AND there are no other acceptable responses, then the responsible actor must do something with another task.

And the next two columns start a "sub table", listing the things that the responsible actor must do.  It may for example, transition one task to another state, AND create two new tasks.  Each one of these gets a row. The action is usually create or transition, or create/transition, and the workflow task is one to be acted upon. Create is used to create a task that hasn't already existed.  Transition is used to transition a task that already exists to a new state.  Create/Transition is used when you don't know what the current status is for the task (it may not have been created yet, but it could exist).  Task Status indicates what the final state is for the task that was acted upon.  The task owner indicates who the task owner is.  Tasks can be created by the task owner, but may also be created by other workflow participants.  For example, in the workflow I'm looking at, one participant creates a Respond to Request task for each possible edge system that could respond, encouraging them to complete some activity.  During these actions, input or output documents can be added to the workflow.  Usually input documents are added during CREATE and IN_PROCESS states, and Output documents are added during IN_PROCESS, COMPLETE or FAILURE transitions.  It isn't usually the case that an input is added at the end of the task.  In some cases (although I haven't had to do this yet), the only action an actor may have is to add an input or output document to another task, and do nothing else.

An important step is that a notification should be given to the task owner and any expected actor who will be triggered by the state transition on the task.  Thus, is the Referral Requester workflow participant has a trigger on Response COMPLETED, then when the Referral Responder workflow participant the Response task to COMPLETED, it should notify the Referral Requester.  For this, I'm assuming that the DSUB transaction is used for notifications, and that the workflow participants are duly notified by some other actor (perhaps the Workflow Manager) of these cases.  There's no real subscription to set up, its just assumed that the notification transaction will occur under the appropriate cases.  When you use a Workflow Manager actor (as I did in my definition), one thing that you could do is make sure that 

1. It is listed as the intended recipient of the workflow document (meaning that it will be managing the workflow),
2. Some system, such as the registry or repository, interprets the intendedRecipient metadata in the provide and register transaction as a signal that a DSUB style notification should be given to the actor identified (in some way) in the Intended Recipient metadata. 
3. That workflow manager notifies any task owner of transitions that have occured on a task that were NOT performed by the task owner itself.  For example, task creations, FAILURE or COMPLETION transitions that may be caused by other external events, et cetera.
4. That workflow manager also notifies any actor responsible for activity on a trigger event that it can detect, e.g., a transition of a task.

In defining workflow in this manner, the table defines what MUST be done in the XDW workflow document, BUT, it does not prohibit additional transactions.  For example, in the Referral Request task, we only note that when a referral is needed (a narrative trigger event), the Referral Requester must create a Referral Request with final status being COMPLETED, and an input document of a Referral Request Document.  I don't say anything at all about the existence of intermediate states, such as CREATED, or IN_PROCESS.  It is quite possible that these states are recorded and the various transitions shown in the XDW document over time.  However, my definition doesn't depend on their existence, and doesn't prohibit it.  This enables other useful behaviors to be added later.  These states are essentially implicit in the workflow, and simply aren't documented with any requirements.

An important point in building these tables is that you have to consider that the state of the workflow should be transparent to an outside reviewer that does NOT have any understanding of the internal business rules associated with the workflow.  So, while you might assume that since a request has been completed, it is expected that the Referral Responder actors might be tasked with generating a respond, you wouldn't be able to tell if a task didn't exist for those actors.  Thus, some tasks that don't exactly need to be recorded in the workflow document to manage the state among the workflow participants still need to be made explicit so that others (such as dashboarding applications), can still provide a good indication to an outside viewer what the status of the workflow is.

I've transposed an short example of the table below (because I usually make it horizontal rather than vertically oriented).  I'll explain the key points after the table.  This is an example meant to illustrate different features of the table, it's not the actual workflow that I wound up defining.

Metadata\Trigger Event	Referral needed	Referral Request IN_PROGRESS		Referral Response READY		Referral Response COMPLETED -or- FAILURE
Responsible Actor	Referral Requester	Workflow Manager		Referral Responder		Workflow Manager
Conditions	N/A	N/A		Referral can be accepted	Referral cannot be accepted	Acceptable Response available	No acceptable response available and more responses expected	No acceptable responses available and no more responses expected
Action	create	create	create	transition		transition	N/A	transition
Workflow Task	Referral Request	Dispatch Referral	Referral Response	Referral Response		Referral Request	N/A	Referral Request
Task Status	IN_PROGRESS	COMPLETED	READY	COMPLETED	FAILURE	COMPLETED	N/A	FAILURE
Task Owner	Referral Requester	Workflow Manager	Referral Responder	Referral Responder		Referral Requester
Input Documents	Request for Referral	N/A	Request for Referral	Request for Referral		Request for Referral	Request for Referral	Request for Referral
Output Documents	N/A	N/A	N/A	Referral Response (Required)	Referral Response (Optional)	Referral Response (Required)	N/A	Referral Responses (Optional)
Notify	Workflow Manager	Referral Requester	Referral Responder	Workflow Manager		Referral Requester	N/A	Referral Requester
Notes			This task is created for each possible referral responder.			Normal Completion	Wait, hopefully someone will respond positively	Nobody responded positively, include all negative responses as output to allow manual review/escalation.

The idea of this workflow is to handle a managed referral request process, where there is a single requestor, and multiple possible referral responders.  There's a workflow manager participant that handles the business processing of the responses to choose among acceptable responses.  When an acceptable response is received, the referral request task is considered to be completed.  There are a lot of different ways to extend this workflow by adding new columns to it.  For example, you could be nice, and transition each outstanding referral response task to the FAILURE state once a referral response has been accepted, so that the Referral Responders can now ignore these tasks if it hasn't gotten to them.  You could also add a time out event to allow the Workflow Manager to renotify Responders of tasks that they haven't paid attention to, or escalate the request, et cetera.

Getting to Other Views

Having developed this table, there are now a couple of different things that you can do with it.  Often you need to explain multiple viewpoints of the workflow definition to satisfy to all and sundry stakeholders what is happening.  The table allows me to generate three different views:

BPMN

You can start to diagram the workflow in BPMN.  The general rules I've been following is that each workflow task becomes a task or activity in the BPMN diagram, and that each workflow participant (aka actor or task owner) gets a swim lane or pool. Conditions are used as conditional entry points into a task. Input and output documents are often included as components of the messages passed between tasks in different lanes/pools.

In an ideal world, I'd have the time to do some automation with a modeling tool so that I could graphically create the content in BPMN and subsequently generate the table, or import the table from a spreadsheet, and dynamically generate the diagram.  For now, I can live with managing the diagram separately from the table and going back and forth between the two.  It's just simply a matter of time and priorities.

Actor Requirements

When you sort this table by responsible actors and task sequence (effectively time), you get a description of the responsible actors view of the task to be performed, and what their required behaviors are.

Task oriented View

When you sort it through by workflow task and task sequence, you get a view of the steps of the workflow.

Generalizing and Specializing

The beauty of this table format is that it also allowed me to build more complex workflows by specializing from simpler ones, again by adding columns (rows really in my spreadsheet).  In my case though, what we wound up doing was defining the most complicated workflow, and then removing columns (generalizing) to get to simpler ones.  It doesn't really matter the direction that you do it in, what matters is that you can simplify or generalize these behaviors.

Notification (ala DSUB) is an important component of this workflow description, and the mechanism I've used is pretty straightforward.  I'm not sure if that's something to submit as a modification to the XDW profile (e.g., the Notification option), or in a specific workflow profile, but I think it is probably worthwhile to consider.

Combined 2015 CMS QRDA Implementation Guide Now Available

Combined 2015 CMS QRDA Implementation Guide Now Available

News Updates | July 29, 2014 Visit the eCQM Library Page to Review the Combined 2015 CMS QRDA Implementation Guide The Combined 2015 QRDA Implementation Guide for eligible professionals, eligible hospitals, and critical access hospitals (CAHs) to use for reporting electronic clinical quality measures (eCQMs) starting in the 2015 reporting year is now available on the CMS website. The 2015 Combined Implementation Guide provides technical instructions for QRDA Category I & Category III reporting for the following programs:  Hospital Quality Reporting including the EHR Incentive Programs and Inpatient Quality Reporting (IQR) Ambulatory programs including the Physician Quality Reporting System (PQRS), the Comprehensive Primary Care (CPC) Initiative, and Pioneer ACO CMS accepted public feedback on the draft guide from June 10, 2014 to July 8, 2014, and has made revisions accordingly for inclusion in this release. The CMS 2015 QRDA Implementation Guide is updated for the 2015 reporting year, and combines business requirements and information from three previously published CMS QRDA guides: The 2014 CMS QRDA Implementation Guide for Eligible Hospital Clinical Quality Measures   The 2014 CMS QRDA I Implementation Guides for Eligible Professionals Clinical Quality Measures [zip file] The 2014 CMS QRDA III Implementation Guides for Eligible Professionals Clinical Quality Measures [zip file] About the Combined Guide Combining the above guides into a single document provides a unified resource for implementers, eliminating the need to locate the individual program guides. More importantly, combining guides harmonizes differences among earlier versions of the CMS QRDA guides, especially between the QRDA-I guides for eligible professionals, eligible hospitals, and CAHs. The CMS 2015 QRDA Implementation Guide incorporates applicable technical corrections made in the new 2014 HL7 errata updates to the HL7 Implementation Guides for QRDA I and III. The new guide contains two main parts: Part A is the harmonized QRDA-I implementation guide for both eligible professionals and eligible hospitals/CAHs. Part B is the QRDA-III implementation guide for eligible professionals. It also includes appendices that annotate the changes between the HL7 QRDA-I and QRDA-III standards and the CMS QRDA specific constraints. Changes between the CMS 2014 QRDA guides and the new combined guide are provided as well. Additional Resources The 2015 CMS QRDA Implementation Guide is available for download on theeCQM Library Page in the Additional Resources section. To learn more about CQMs, visit the Clinical Quality Measures webpage.  For questions about reporting requirements using the 2015 QRDA Implementation Guide, please refer to the specific program’s help desk or information center.

IHE PCC Strategic Planning

The IHE Patient Care Coordination Technical Committee met this week to review the public comments received on the work it is doing this season.  I'll write up the details of what we did later.  More importantly the Planning Committee also met to review its strategic road map.

As part of that work, we came up with a revised mission and vision statement for the domain (which appear below) to help us guide the work.

Vision: The vision of Patient Care Coordination is to continually improve patient outcomes through the use of technology connecting across healthcare disciplines and care paths.

Mission: The mission of Patient Care Coordination is to develop and maintain interoperability profiles to support coordination of care for patients where that care crosses providers, patient conditions and health concerns, or time.

We looked at answers the following three questions to then identify key activities for the domain.

 1. What are the leading trends in Health IT and EHR system interoperability that most greatly impact you?

 2. What is the biggest change in thinking that should be applied to the problems of EHR interoperability?

 3. What capability in Interoperability would make you stand up and take notice?

Some of the topics that came up included:

• Distributed Care Coordination
• Dynamic Interface Development
• Updates to QED to support a RESTful transport (using FHIR)
• Expanding the influence of the Nursing Subcommittee

We are still evaluating the details, and so there is still some chance for you to have input.  Please provide it in comments below.

We done DID that

Every year the IHE PCC Committee goes through the process of updating its Strategic Plan.  This process involves brainstorming about the directions we could take with new profiles in the domain.  Yesterday during this process I came up with an extension of the idea originating in the IHE Care Management Profile, and further explored in this post.  The idea is to develop a way to perform Dynamic Interface Development (DID); the general concept is that there is a catalog of data elements from which you could choose information that needs to be transmitted in an interface. The catalog would need to be at the right level of granularity, approximately at the level of an IHE Template, a FHIR Resource, or a V3 RIM Class.  To create the interface, one would create a list of the data elements that are needed (these might be expressed as FHIR Query resources for common cases).  Having made the list, it would be fairly easy to automate creation of an interface to send the collection of data expressed in that set of queries.

There's a lot of work needed to get there, and there are a lot of little details between here and there, and some pretty major assumptions to test out over time.

   Keith

IHE Cardiology Technical Framework Supplement Published for Trial Implementation

IHE Cardiology Technical Framework Supplement Published for Trial Implementation The IHE Cardiology Technical Committee has published the following supplement to the IHE Cardiology Technical Framework for trial implementation as of July 18, 2014: Registry Content Submission - CathPCI V4.4 (RCS-C) This profile may be available for testing at subsequent IHE Connectathons. The document is available for download at http://ihe.net/Technical_Frameworks. An accompanying sample CDA document and sample data collection form are also available for download. Comments on all documents are invited at any time and can be submitted at http://ihe.net/Cardiology_Public_Comments/.

But It Changes my Workflow

I hear the complaint that implementing an EHR changes their workflow from a lot of physicians and nurses.  I also hear (from those who've studied up a bit), that EHR X is no good because it is just an electronic version of their existing paper workflow.

The other day I tweeted:
Why would you use an EHR that DIDN'T change your workflow? Improvement = Change

A few folks commented that change is not necessarily improvement, and I certainly agree.  But let's take a step back from that point.  You are going to start using an EHR, either a different one than you were currently, or a brand new one since you haven't used an EHR in the past.

Why would you do that at all if NOT to make an improvement in your practice.  And if you are making an improvement, that means that workflows are GOING to change.  I cannot think of a single case where a significant improvement (cost, time, efficiency, outcomes or otherwise) didn't result from at least one significant change in workflow.

Can you?

I agree, not all changes are improvements, and not all EHR implementations are done well, BUT, my point stands.  If you are implementing an EHR, you should expect your workflow to change.  And if you are implementing it right, you should expect it to improve.

     Keith

On Backwards Compatibility

HL7 has a great deal of experience with defining rules for backwards compatibility (which is not to say that those rules always worked).  They also have a whole document devoted to substantive change (for non-members, simply download HL7 Version 3 Normative Edition and read Substantive Change under background documents).  IHE and DICOM have similar rules about substantive change, which is part of what versioning and backwards compatibility are supposed to address.

The problem breaks down into two parts.  We'll start with two systems, N (for New) and O for (Old) which are using some version of some standard.  This is what we need for backwards compatibility that will support "Asynchronous Bilateral Cutover".

New Sender (N) sending to Old Receiver (O)

In this case, System O has certain expectations, and is already in the field.  So whatever had to occur in the message sent to system O should still be possible to send in the new version of the standard (if it isn't possible, then System N and System O don't have a common set of capabilities).  Moreover, if it had to be sent under the old version of the standard, it should also be required in the new version.  If not, then the two systems cannot readily communicate.

Old Sender (O) sending to New Receiver (N)

In this case, System N also has certain expectations, but before the new standard is fully baked, is NOT already in the field.  When receiving information from System O, system N should be able to deal with the fact that it is NOT going to get stuff that is new or changed in the new version of the standard.  Usually System N is a new version of System O, and could work under the "old rules".  So, keep working that way. One of the things that often happens in making changes to the standard is that previously optional stuff now has to be required (constraint tightening).  What System N needs to do in these cases is figure out what a safe and reasonable default behavior would be when it gets a communication from System O where those tightened constraints are not yet used.

Moving On

Tightening of constraints should be OK behavior in moving from version O to version N of a standard.  We know that loosening constraints is often a problem as we move forward.  However, the expectation of the receiver should be that old constraints are still OK for some period of time, in order to allow others to catch up asynchronously.  Determining this set-point is an interesting policy challenge.  At the very least, you should "grandfather" older systems for at least as long as they have to "upgrade" to the new version of the standard, and perhaps a little longer to deal with laggards (as we've seen has been necessary for 5010 and ICD-10 cutovers).

At some point, you have to drop support for the old stuff.  A good time to do that might be when it is time to move to version M (for moving on) of the standard.  What we want to do to support Asynchronous Bilateral Cutover is think about changes so that required behavior is invoked more slowly, and that things that were not previously required start off first as being desired, or preferred behavior (which is required in new systems, and allowed in old systems).

Exceptions

There will always be cases where an exception needs to be made.  That needs to be carefully thought out, and in new versions of standards, Exceptions to the backwards compatibility rules should be clearly identified when the standards are balloted.  We shouldn't have to figure our where those are just by inspecting the new rules.  Some features need to be retired.  Some capabilities cannot be changed in a way that won't impact an older system.  The key is to clearly identify those changes so that we can get everyone to agree that they are good (which is not the same as agreeing that they aren't bad).

With the new Templates formalism, we should be able to identify these issues with C-CDA going forward.  I would very much like to see HL7 sponsor a project to ensure that C-CDA is made available in the new format once it finishes balloting.