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

What to worry about in the MeaningfulUse 2015 Certification NPRMs

After two weeks of 12-hour a day training (which is why this blog has been uncharacteristically quiet), I was awarded Friday by ONC with way to many pages to read, just like everyone else.  I'm barely 25% done on the Certification rule, but many have already asked for my views and observations.  Here is what I know so far:

There are 67 certification criteria, up 18 criteria from 49 last cycle.  The criteria has been rewritten to apply all of Health IT, not just EHR systems.

The Clinical Criteria

Within the clinical criteria sub-section 170.315(a) there are 23 criteria, 7 are unchanged, 11 revised, and 5 new criteria.

Things you don't have to worry about: CPOE for Medications and Imaging, Medication and Medication Allergy Lists, Imaging Results, Patient List Creation, and Electronic Medication Administration Records.

After updating your vocabulary to the new standards, you also don't have to worry about these:
Demographics, Problem Lists, Smoking Status, and Family Health History.

Now, start worrying, but not too much yet:

Simple Stuff

Vital Signs just got a little more complicated, but for anyone who has been following HITSP, IHE, CCD, C32 or C-CDA specifications, these are pretty simple upgrades.  There are a few new "vital sign" codes that can be applied for dealing with BMI, or oxygen saturation, but for the most part, this is pretty straightforward stuff.

Drug/Drug and Drug Allergy and Intolerance checking also got a bit more complex, in that now you are expected to record what providers do with those alerts.  If you haven't instrumented them already, you will be expected to do so.  This is also fairly simple and obvious.

CDS adds the same requirement to record what providers do in response to an intervention, again, not a big lift.

On requesting patient specific education resources, a new requirement that they be able to be requested in the patient's preferred language has been added.

Moderately Challenging

Among the moderately challenging requirements, the following have been added or revised:

Lab CPOE is about to get harder, and easier.  There are new standards to apply for the compendium, and the order.  In general though, this one is a wash, PROVIDED we can get labs (which have NO incentives to use MU standards) to start using them.  This will be work, but also have value for everyone under that proviso.  

If you don't already support the HL7 Pedigree standard, the new rule splits it out as a separate criterion.  It won't be as hard as say, the C32 or the C-CDA, but it will be challenging if you have to do it to support the CMS rule for your customers (I haven't even cracked that one open yet, so I don't know what the ramifications are for that).

Difficult

They've changed capturing Advance Directives to capturing details about other documents, such as birthing plans.  The rationale sounds good, but I'm not sure the two really want to work the same way, especially given the new care planning work in C-CDA Release 2.0*.

Drug Formulary and Drug List Checks will also be on the more difficult side if you haven't already adopted the NCPDP Formulary and Benefit Standard v3.0 standard that was part of the voluntary criteria.

Populating the Implantable device list is probably going to include a whole new set of user interfaces for folks.  I know of some, but not many EHR systems that presently capture this data.  Of course, I would expect most are all able to be configured to capture it, but then when you add the measures for whether it was captured for patients, it gets a bit trickier.

The big mess is in the capture of social, psychological and behavioral data.  I don't doubt the value of this as specified in the rule, but it begins to become invasive with respect to patient privacy.  Not only will this involve a bunch of new data capture screens, but also requires enhanced security due to the more sensitive nature of some of this data.  It also begs the question of how much data SHOULD be required under the certification and incentive rules.

Adoption of the CDS Knowledge Artifact and Service standards is also going to be challenging. There's still a lot of work being done to clean up and harmonize the specifications.

Overall, I long for the day when a Certification rule adopts no standard that is still in its infancy. Granted, we have a long way to go before we get there, but we are still in that period of early growth where every day brings new changes.  At some point, I'd love to get this program to a point where the improvement is more evolutionary than revolutionary.  I'm not arguing the need for revolution, BTW, just wishing that we didn't need so much of it at once.

   -- Keith

P.S. There will be more when I've had a chance to read another hundred pages or so...

* Note that while I think C-CDA Release 2.0 is also going to be challenging, I haven't really analyzed all the details for that yet, since it is in the Care Coordination Section.

The new phone books are here...

Just in time to ruin my weekend....

------

HHS Issues Proposed Rules for Stage 3 of the Medicaid and Medicare EHR Incentive Programs and the 2015 Edition of Health Information Technology

 

Today, the Department of Health and Human Services’ (HHS) Centers for Medicare & Medicaid Services (CMS) issued a proposed rule for Stage 3 of the Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs. Separately, the Office of the National Coordinator for Health Information Technology (ONC) issued a proposed rule for the 2015 Edition of Health Information Technology (Health IT).

 

EHR Incentive Programs Stage 3 Proposed Rule

 

The Stage 3 proposed rule focuses on making the EHR Incentive programs more flexible, simplifying and reducing burden of providers participating in the program, driving the interoperability of health IT, and improving patient outcomes.

 

The CMS Stage 3 Meaningful Use proposed rule includes proposals that would:

 

• Realign the reporting period into a single one for all providers starting in 2017 (hospitals will participate on the calendar year instead of the fiscal year);
• Allow providers the option to start Stage 3 of meaningful use in either 2017 or 2018 (required in 2018), which gives providers an extra year to start than under current regulation;
• Reduce the overall number of objectives to eight in order to focus on the advanced use of EHRs;
• Remove measures that are redundant or obtained wide-spread adoption;
• Align clinical quality measure reporting with other CMS programs; and
• Propose the use of application program interfaces (APIs) that could enable the development of new functionalities to build bridges across systems and provide increased data access.

 The Stage 3 proposed rule’s scope is generally limited to the requirements and criteria for meaningful use in 2017 and subsequent years. CMS is considering additional changes to meaningful use beginning in 2015 through separate rulemaking.

 

2015 Edition Health IT Proposed Rule

 

The ONC 2015 Edition proposed rule builds on the foundation established with the 2011 and 2014 Editions.  It proposes to adopt standards and certification criteria designed to foster innovation, open new market opportunities, provide more choices to the care community for electronic health information exchange, and support ONC’s vision for interoperability.

Specifically, the 2015 Edition proposed rule would:

·         Enable a more flexible certification program that supports developer innovation and focuses on interoperability;

·         Adopt new and updated vocabulary and content standards for the structured recording and exchange of electronic health information;

·         Facilitate the accessibility and exchange of electronic health information by including enhanced data portability, transitions of care, and application programming interface (API) capabilities as part of the 2015 Edition Base EHR definition;

·         Adopt standards to address health disparities, including standards for the collection of social, psychological, and behavioral data, and for the accessibility of health IT;

·         Prioritize the privacy and security of data a priority, by ensuring relevant privacy and security capabilities and by addressing the exchange of electronic sensitive health information  through the Data Segmentation for Privacy standard;

·         Improve patient safety by applying enhanced user-center design principles to health IT, enhancing patient matching, requiring relevant electronic health information to be exchanged (e.g., Unique Device Identifiers), improving the surveillance of certified health IT, and making more information about certified products publicly available and accessible; and

·         Increase the reliability and transparency of certified health IT through surveillance and disclosure requirements.

 

A press release will be available at:  http://www.hhs.gov/news. A Consumer Fact Sheet will be available at:  http://healthit.gov/newsroom and a Technical Fact Sheet for the 2015 Edition Proposed Rule will be available at:  http://healthit.gov/newsroom.

The Stage 3 and 2015 Edition proposed rules may be viewed at:  https://www.federalregister.gov/public-inspection.

The Draft 2015 Edition Certification Test Procedures will also be published and may be viewed at http://healthit.gov/2015-Edition-Certification.

 

More information the EHR Incentive Programs is available on the CMS website at http://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/index.html.

More information on ONC’s editions of certification criteria can be found at http://www.healthit.gov/policy-researchers-implementers/standards-and-certification-regulations.

If you have any questions regarding the Stage 3 proposed rule, please contact the CMS Office of Legislation.  Please contact Blair Hedgepeth, ONC Legislative Liaison at blair.hedgepeth@hhs.gov with any questions regarding the 2015 Edition proposed rule.  Thank you.

Strategy and Tactics in Standards Development

I like to play chess.  Over the past couple of years though, instead of playing chess, what I've been doing is solving chess problems.  My wife this morning asked me how I solve the problems ... can I see the answer to the problem in my head, or do I do something else first.  It depends actually.  Some problems the answer is fairly obvious, I see a particular weakness or pattern on the board, and the solution is pretty obvious, even if a few moves deep (three or four at most).  In other cases, while I can identify a weakness I want to exploit, I cannot see the full solution immediately.  But I can often find the first move, and as the board unfolds, the remaining moves become more obvious.  When I struggle, I fall back on trial and error.  I make a move, and either it is the right one, or it isn't.  Eventually, I solve the problem, but this is perhaps the most frustrating and least satisfying way to solve the problem.

In developing standards, the same thing is true.  Sometimes you can identify the solution pretty quickly, the strategic objective is obvious, and the tactics just fall into place.  At other times, the strategy is identified, and the tactics unfold as you start to head in a particular direction.
The results depend on the two components: Whether you chose the right strategic objective, and whether your tactics addressed those objectives.  Let's look at a couple of cases:

The Direct Project

The strategic objective of the Direct project was identified as creating an "on-ramp" to health information exchange.  SOAP-based exchanges were rejected because they were too complex to solve the problem.  The tactics shifted towards SMTP, and we now have an e-mail based on-ramp for health information exchange through Direct.  In this particular case, we have a tactical success, but most would probably agree that Direct strategically was a failure.  The original desire of some of the project initiators was actually a RESTful health information exchange API, but as a strategic goal, that couldn't happen because the necessary infrastructure to support the tactics associated with that didn't exist at the time Direct was created.  Subsequent initiatives, such as FHIR and IHE's Mobile Access to Health documents profile better addressed the "simple on-ramp" requirements, and are being evolved through the Data Access Framework project to achieve a better on-ramp.

Mobile Access to Health Documents

IHE's Mobile Access to Health Documents profile was looking at addressing how to simplify edge connections from mobile devices to better support information exchange.  Tactically it was in a better environment.  The infrastructure to support the necessary tactics for this profile were under development in FHIR, and what IHE had to do was simply execute on profiling the right components of FHIR.  We had to wait a little bit for FHIR to be more complete, and so the tactics weren't clear from start to finish until later in the profile development.  Again though, I think few would argue, that given the environment that we are in today, the tactics, given the identified strategy are fairly clear.

BPMN Whitepaper

The BPMN white paper (was previously an appendix, but we've changed scope a little bit) identified a fairly clear strategy: Enable automated development, implementation and testing of IHE workflow profiles.  Tactically, BPMN is the right solution space for this work, but the evolution of our implementation is a bit challenging.  I'm bogged down a little bit in the tactical details right now. There are a number of issues that I need to address, and unfortunately, there are at least two and possibly more different ways that those could be resolved, some of which are supported by existing tools, and others which are not.  So, trial and error needs to come into play.

In war and chess games, strategy and tactics problems are unforgiving.  If you miss the strategy or the tactics, you wind up with a loss.  In standards development, it's not quite the same situation.  We can learn from our mistakes, and while past failures may be disappointing, they aren't all or nothing losses or successes.  There are always opportunities for do-overs and refinement.

Workflows are hard to Change

As an organization, is it easier to change your data model or your workflow?  For all the complaints I've heard about the former, it is almost always changes to the latter that can kill a process improvement initiative.  Ask a provider to complete an extra field on a form they already fill out, or change the forms they've been filling out for years so that they make more sense, and which will they choose?  Invariably, the former rather than the latter, even though the latter may be much more useful.

You actually have to demonstrate that a new workflow is better, because few can hardly imagine it being anything other than what it has been forever.  It isn't all bad though.  I'm beginning to see some evidence that some organizations are paying attention to how they can change workflows to provider better service.  While those organizations are starting to catch on, it will take a while for many others.
Today I made an appointment to see a new Dentist (finding and scheduling dental appointments is somehow much easier than doctors).  After registering me in their system over the phone, the office staff pointed me to the forms they have for me to print out online.  Eventually they'll get to the point where it is safe and easy for me to fill them out and submit them online or over e-mail, but that will take another decade.

The very fact that they were willing to change their workflow to gather the same data though, while they had me engaged on the phone making an appointment, left me impressed.

What are you experiences changing workflows in your organization?

   Keith

Balance in Governance

One of the biggest unrecognized challenges to balance in consensus standards development processes is lack of balance in Governance.  What do I mean by that?

Governance is about who decides.  Who decides what the priorities are?  Who decides where scarce resources are deployed.  Who decides not just what gets done, but who does it?

Let's look at several examples of lack of balance in government in standards development over the last decade:

CCR: The CCR steering team was made up of medical professional societies.  The team decided overall direction for CCR development.  Vendors and other participants in the development of the standard were not permitted to be part of the steering team.  This resulted in a great deal of unnecessary conflict in the development process, and in the end, the ultimate death of CCR as an XML standard (the core data elements of CCR live on today though, in CCDA and elsewhere).

ONC/AHIC/HITSP:  While HITSP had a generally balanced process for development and approval of specifications, it was ONC and AHIC who determined what specifications would be worked upon.  ONC set the general direction, and AHIC filled in the specifics. And whether or not the project was viable based on the consensus of the HITSP membership, HITSP still had to deliver specifications to meet the use cases handed down by AHIC.  This resulted in specifications such as Biosurveillance which consumed a great deal of effort, and resulted in previous little change (recall that this Use Case came out not long after the anthrax scares of 2011).

ONC/The Direct Project: ONC decided what it wanted and initiated a project to make it happen.  It was widely touted as a great success, unfortunately, the specifications are still "government created" as they have not yet been taken up by any SDO, so no non-governmental body exists for maintenance, and there are still challenges in deployment.  The decision about what project to work on (a governance decision) was made by ONC.

ONC/S&I Framework: This has been better, but with a lot of variation in how these projects are executed.  The best example of governance challenges are with the HQMF and Health eDecisions. The projects were separately initiated and staffed, with little overlap.  Fortunately, both projects were also done through HL7 governance.  When challenges arose about incompatibilities between models in the two specifications, HL7 initiated a review and rework process that has resulted in much greater harmonization across these specifications.  This is a perfect example why consensus in governance is critical.

Argonauts and HL7 FHIR: This one is fun.  It's greatly touted collaboration of a number of Health IT juggernauts with HL7 on accelerating the development of FHIR.  The project management and decision making about what projects are to be focused on is restricted to a closed group (the original Argonaut members).  Others can participate so long as they do so according to the structures created by the original decision making body.  The end result may well benefit the whole industry, but the decision making about what to do is closed.  For example, how are OAuth2 specifications to be evaluated, and if there are changes necessary to existing specifications, where will those be done? There isn't a consensus group making that decision.

ONC has asked some key questions in their recent publication of the Interoperability Roadmap. Many of these impact governance issues similar to those I've raised above.