Differing views of Workflow

Today was an exercise in patience for me, something that I do not do terribly well.  During it, I heard from two different people with different viewpoints about how we should approach the Radiology Remote Read profile.  I also realized that one of the reasons for the different viewpoints was that they were operating from different perspectives on workflow, and that the solutions each proposed was optimized for ONE of these perspectives.

One viewpoint is that of the service provider, who is only interested in their tasks, and accepting and processing them as quickly as possible.  But another viewpoint is that of the overseer of the entire workflow for a patient, who is interested in seeing what is happening across all the different tasks associated with completing the work for that one patient.  Yet another viewpoint is that of an overseer of the whole process, who is interested not just in what happens for one patient, but also looking at a roll-up aggregated view of what happens to patients in general.

I see a cube, painted with a workflow in various swimlanes, rotated in one direction, it shows a patient view, in another, a viewpoint of the service provider (workflow performer) and the tasks they must perform, aggregated and cut differently with some visibility down through the cube, perhaps the final viewpoint.

XDW works well when the patient view is at the forefront.  It optimizes workflows around the patient.  Task oriented structures like Universal Procedure Step optimize differently, for the processors of work list items, and the viewers of the queues managed using that structure.  The two compete for attention, and neither adapts well to the viewpoint of the other.

Over the long term, I think XDW needs to shift from a Document Based workflow storage structure, to a resource based storage structure, where the resources are workflow instances, and task instances, and the workflow instance resources reference the various task instances.  This would work fairly well I think in FHIR, because you could reference task resources in the Workflow Instance, and ask the tasks change state, the composition that is constructed of the Workflow Instance and all of its associated tasks becomes the "Current Workflow Document", yet its management is much simpler. To change the state of a task means that you only need ensure transactional integrity around the task itself, not the entire document.  In the real world this happens.  Given two performers of different tasks, they complete and update the task independently.  It adds some complexity because it means that certain activities (services) need to be able to complete fully (this task completes as that one starts).  We don't have those capabilities in XDW yet, and likely will not until the necessary task and workflow instances resources have a home, perhaps in FHIR, or perhaps elsewhere.

I say this, because if we had an infrastructure like this, I think the standards selection process we are going through now would be a lot less painful.  I may even propose this tomorrow, because if I have to sit through another four and a half hours of the kind of discussion I sat through yesterday, I think my head must explode.  The task instance resource becomes the way to implement the "task oriented queue".  A query on the task instance resource for task instances of a particular type becomes the base query for the "queue" of tasks of that type to be performed in a system.

Where does that leave our poor Remote Read profile?  It is perhaps a profile proposal ahead of its time.  But, if we did this right, it might become a profile proposal that would be completed with half of what it needs, and be there to push us forward with its unmet requirements.  Hopefully this will all gel in my brain before the next few hours of calls to discuss this profile.

In the meantime, to quote a friend ... please send more brains...

Too many masters in 2015 Certification

I've finally finished my review of the 2015 Certification Criteria.  As a reward I now get to read the Stage 3 Penalties Rule next.

I put together a spreadsheet containing a bunch of useful factoids from the rule.  The first tab is probably the most important.  It shows:

Heading	Description
2015 Citation	The section of the NPRM
Criteria	The name of the criterion
New/Revised/Unchanged	Whether the criterion is new, revised, or unchanged, or whether comments are asked for.
Comments	Notes on the criterion
2015 Standards	What standards are referenced and where in the rule
2014 Citation	Where the former criterion that was similar to it can be found

Having completed this work, I can tell you overall, I'm not really satisfied with this rule.  For one, there are way too many references to unfinished work.  It would have been better to delay and let that work be finished, or simply not reference it this time around if it was not critical to the regulation. Unfortunately, I think ONC is trying to please too many masters on this regulation.

As a set of "Health IT Certification" requirements, it NEARLY COMPLETELY misses everyone Health IT modules supporting anyone previously excluded from Meaningful Use.  For example, while we have criteria on sending to public health, there are absolutely NO CRITERIA for public health to receive using Health IT that conforms to these standards.  This is a huge miss.  The ONLY reason we don't have a similar miss in Labs is because a Hospital EHR has to be able to transmit lab results.

Some material, such as the administrative criteria is overkill in the extreme.  Three different signatures, plus requirements for FIPS Level 2 certified encryption modules?  Really?  For a automating a part of the business that previously used copiers and fax machines and wet ink signatures (that could be applied with a stamp).  This is using a sledge-hammer to swat fleas.  There is really no accounting for physician workflows from the point of care of the patient to the point where payment is being requested.  A great deal more work is needed here before we could ever support this level of technology.  90% or more of what is needed could be done without imposing nearly such a complex set of technology requirements.

Also, while I very much welcome some of the requirements around C-CDA validation, this could have been applied very much at a sub-regulatory level.  NIST and others already have the opportunity to propose and the Secretary the authority to approve testing methods.  They need NOT be spelled out in regulation.  Having done so prevents NIST or others from developing or using better and more efficient testing methods that don't necessarily follow the patterns in the regulation.  So much for innovation and efficiency in testing if that path is continued.

    -- Keith

P.S.  In case you haven't seen it, John Halamka and Micky Tripathi have summarized both rules, in what Health IT News called "The Good, The Bad and the Ugly of Stage 3 MU".

Remaining 2015 Certification Criteria

I've finished looking at the certification criteria, but still have about 150 pages of more reading until I'm done with the ONC Certification Rule.

Here's what I've found in the remaining criteria:

Public Health

All the standards have been updated to more recent versions.  This shouldn't be a huge shift, but I suspect the new Immunizations guide will have some new capabilities that you want to look at.  They dropped the "Cancer Case" certification criteria from the 2014 edition in favor of a separate case reporting guide based on the IHE Structured Data Capture Work.  But for that, ONC also wants to know if we should use FHIR.  I think timetables dominate here.

The HL7 Healthcare Associated Infection Reports (you might remember this as "Hospital Acquired Infections" if you are a) old enough, and b) politically insensitive) now have a home in a criterion designed to capture information about antimicrobial use and resistance.  These specifications and this project has been around in HL7 for quite some time.

They've also added a criterion to support transmission of electronic survey data to public health using the HL7 National Health Care Surveys implementation guide.

Design and Performance

In design and performance, gratefully, numerator and denominator recording remain unchanged. 

Safety Enhanced Design (SED) gets a big makeover.  They added Demographics, Vitals Signs, Problem List, Implanted Device List, Decision Support Knowledge Artifact and Service, and Incorporation of Lab Tests and Results into the original list of ten items requiring SED.  Rather than summarize the set of changes, let me just tell you to read this section closely.

On the use of a Quality Management System, this is the pertinent quote:

For the 2015 Edition QMS criterion, we are taking that next step by not permitting health IT to be certified that has not been subject to a QMS and also requiring health IT developers to either use a recognized QMS or illustrate how the QMS they used maps to one or more QMS established by the federal government or a standards developing organization(s) (SDOs)

Basically, this means get on board with QMS.  You could get away without one previously, but now they are serious, and if you've rolled your own, you will have some work ahead of you to map to the standards.

Accessibility: There's been a push to make sure that not only is data accessible to patients in an accessible fashion, but also that the design of  EHR systems takes into account accessibility requirements for providers.  This is another section where you will want to look closely, and have your User Centered Design (UCD) folks look over your shoulder (or you over theirs).  If you don't have any UCD folks on staff, be worried.  [I'm still maintaining an A.E. Neuman pose on this section].  There's also a push to document all accessibility standards or laws that the Health IT module conforms to.  The list of standards and laws here seems like overkill ...

C-CDA testing will be toughening up (and its about time).  I think the certification criteria is a bit overboard in this area, because a lot of what they describe could be addressed in a sub-regulatory fashion in how they test C-CDA creation and display.

Application access to the common clinical data set is a huge addition in this rule.  This is the API criterion, which functionally describes what the API should do.  The closest standard we have for this is FHIR, which is where I expect this to go eventually, but ONC clearly heard that it wasn't ready yet [even though they've mentioned at least five standards that are still in the making in this rule so far]. I'm sure most EHR systems have this capability, the question is whether they want to expose it quite so far as is required by ONC.  Some of the documentation that EHR vendors have they consider to be trade secret, released only to customers under an NDA.  That situation seems likely to change if the rule goes through as currently written.  It is an interesting consideration, because elsewhere in IT, the situation is remarkably similar to the current situation in Health IT, that product APIs are often only released to licensed users of the product.

Transport Protocols

There's not much new here, although with Direct they'd like to add an Implementation Guide on Delivery Notification.  There's a bit of rework on the Edge protocols around XDR/XDM, regarding support for XDM.  The SOAP transports remain unchanged [I might guess that their maturity is showing ;-)].  On the new side, there's HPD with a separate request and response criteria, optionally utilizing Federation.

Administration

This is another new one, and frankly, a bit of a mess.  There are three separate capabilities required for signatures (are these guys signature happy or what? ... what else would you expect from auditors). There's an additional set of C-CDA templates also required supporting what is effectively attachments, although that specification has certainly received mixed reviews from the HL7 Attachments workgroup during its development.  This one needs a careful look, because maybe there will soon be an attachments rule, and my guess is that it would reference this NPRM, if it ever sees the light of day (after 15 years of waiting, I have reason to be dubious).

Thus ends my review of the criteria, there's still some 150 pages left, including the actual rule text itself.  Once I finish that, I'll have another spreadsheet to share, and then on to the Penalties rule.

   -- Keith

Changes to View, Download and Transmit under the 2015 MeaningfulUse Certification Criteria

This is a big one by itself, and so deserves its own post.  To be fair, they didn't change anything else in this section (Patient Engagement), but beyond Secure Messaging, there wasn't much else there beyond this one.

First of all, they updated the standard to C-CDA 2.0.  But there's a lot of additional features here:

1. Patients need to be able to view their imaging and laboratory reports 
2. They ask for comments on whether patients (Apps really) should have access to the API mentioned elsewhere in the rule.
3. They add addressee to the Audit History (this is minor)
4. They want to know if they should focus only on CCD creation (rather than any other kind of document allowed in C-CDA).
5. They ask again about the maturity of an as yet unpublished specification from HL7 (Data Provenance)... you can guess my answer on that one.  
6. They dropped specification of a Clinical Summary (mostly I think it moved to the Penalties Rule*)
7. On Transmit, they wonder if adding the Trust Bundle Distribution Specification is worth doing.
8. Finally, they wonder if they should add a WCAG 2.0 Level AA requirement (they are already at Level A)

Some feedback on these: First, with regard to access to other reports, I'm all for it, but I would suggest these need not be conformant YET to any published specifications.  I'd be OK with some optional criteria around this (e.g., Diagnostic Imaging Report in C-CDA, or use of XD-LAB for Laboratory results), but at the moment, there are plenty of these that simply aren't available in this format.  Patients need the data, let's not get in their way.

App access to an API is basically what Blue Button Plus Pull was about, and I think that would be a good place to start.  They could build on FHIR and Mobile Access to Health Documents, but given FHIR's readiness, I think a functional requirement is sufficient.  The industry will likely choose FHIR and MHD without any further prompting from ONC.  I think document access is the right place to start.

On the whole CCD question, my answer is thus: Vendors who haven't figured out that it is the section templates that they need to worry about, and NOT the document templates are few and far between.

DPROV is clearly not mature, having not yet even been born by HL7 as a DSTU.  That's still out in HL7 for reconciliation, although they don't note that in the NPRM as they did with everything else.  I still have comments that have yet to be reconciled on that one (now scheduled for early April), and the major delay for me has simply been conflicting schedules.  As I said in a tweet, the metadata on that project should tell you something about its provenance.

On dropping the clinical summary, I think some functional work is necessary here, but unfortunately, the HL7 Pertinent and Relevant project is still being developed and has yet to be approved as a project (we are targeting before HIMSS).

I'll let John Moehrke take on the Trust Bundle stuff, that's not up my alley.

With regard to Level AA, I'm not so sure about that, mostly because of mobile.  Level AA can be challenging in a desktop browser.  With mobile, it could be more so.  I have to think about that one.

   -- Keith

* I used to call the CMS rule the Incentives Rule, but that no longer applies in most cases.

More on MeaningfulUse Certification: Quality and Security

Quality Reporting

For quality measures, the challenge is that the standards that folks have been working on just aren't ready yet.  This is largely in part due to the whole Health eDecisions/Health Quality Measure Format incompatibility created a couple of years ago.  A self-inflicted wound if ever there was one, but one that is healing, but not fully healed yet.  I'm not sure how to respond to this one yet.  I think we stay the course, but one of the things I'm looking for this cycle is whether provisions have been made to pilot new technology.  That will show up in the Incentives rule (should I be calling it the penalties rule).

Throughout this section, one change you will see is that:

... when a Health IT Module is presented for certification to this criterion, we would expect that testing of the Health IT Module would include demonstration of a user’s ability to ____ without subsequent health IT developer assistance beyond normal orientation/training.

This basically is saying that users have to be able to execute the functions that the module is certified to without having to call on the vendor for support.

Security

On security, you can rest easy with regard to the certification criteria, as they remain unchanged. They do ask for comment about when SHA-2 (SHA-256 for example) should be phased in and how.

What? Me Worry? Care Coordination in MeaningfulUse

I've just made it past the Care Coordination section of the Meaningful Use Certification NPRM.  Clearly I'm picking up speed, and hope to be done the rest of the rule today, but thought I'd share what I've learned thus far:

Not to Worry about:

There isn't a thing that you shouldn't worry about some in this section, unless of course your name is Alfred E. Neuman.

Worry about a little:

Transmission of Laboratory Test Reports, and incorporation of Laboratory Test Results both have updated standards.  This isn't really a huge lift, but you will need to pay some attention to the new standards.

Worry about:

Data Segmentation for Privacy is a new requirement, so even though it is fairly easy (tag documents as being more restricted for example), you should pay a bit more attention to this.  

If you are one of those called out on Data Portability for making it hard to use or configure by the customer, you have some work ahead of you, otherwise you'll be just fine.  I'm not too worried about this one.

For Reconciliation, they'll be tightening up the testing.  This is long overdue in my opinion.

Worry about a lot:

There's a technical term for the quantity of change in the Transitions of Care requirements that is NSFW.  We call it a ****-ton in software engineering terms.

First, there's a version change in C-CDA which adds a number of new document types.  That alone is a big effort, but not as big as before the template versioning problem got resolved.

Next there's some stuff about validation checking CCDA documents.  Now, if you haven't been checking whether inputs to your EHR system coming from outside the user organization are valid to begin with, you have quite a bit to worry about (I personally am not too worried about this). However, this is going to involve some product change in a few places because ONC will now be looking over your shoulder at how you do this.

Can your product handle an XDM file in a Direct communication?  If not, you need to worry about this.

Finally, you need to make sure that identities you communicate are well suited for patient matching down the road.

These last two items are small in and of themselves, but they are all wrapped up in one VERY BIG certification criterion.

e-Prescribing is another area where there's a boat-load of changes.  In addition to requiring NEWRX messages, ONC is proposing the testing of five other transactions in NCPDP Script 10.6: RXCHG/CHGRES, CANRX/CANRES, REFREQ/REFRES, RXFILL and RXHREQ/RXHRES. 

Also, they have proposed the use of structured sigs in prescriptions.  No more dumb text which led to this mess in my daughter's prescription.

Lastly, there are Care Plans, which is another completely new thing in C-CDA, and has some serious ramifications.  I'm all for this one, but as a new requirement, you'll need to examine it deeply.

MeaningfulUse Objectives-Measures-Certification Criteria-Standards Cross Walk

One of the things I love about the Meaningful Use NPRM's is how people across the industry share the load of analyzing the rule. Last week Corey Spears gave us all links to the bookmarked PDFs. Yesterday evening, Hans Buitendijk (formerly of Siemens and now Cerner) sent me his spreadsheet, which you can find here.

     Keith