We need to fix this...

One of the worst things that can happen to a vendor is to release a product that doesn't work in some way.  In software, we call this sort of breakage a bug.

Fixing bugs is something that vendors have to do all the time.  Software is much more complicated that just about anything other than organisms.  There are simply so many "moving parts".

So why should an SDO or profiler be exempt from this process?  The reality is that it shouldn't be. We've discovered many problems with HL7 standards and IHE profiles over the years.  And we have the necessary processes in place to fix them.  Unfortunately, we don't always have processes that work quickly enough for our customers, implementers or developers.  I've seen what it takes to get a "rapid project" off the ground, and it's not something that you want to do lightly, but neither is it as quick or agile as I think we need to be able to support.

In part, I think that is because we lack experience operating at "Internet Speeds" in correcting problems with standards that we are developing at those speeds.  But where development needs to complete in 9 months for such a project, fixing a bug feels as if it needs to complete not in 9 weeks, but for some, 9 days.  We cannot fix things yet at either of those speeds, but we need to get better at it.

You might argue that we shouldn't have these bugs in the first place.  Back when I was in computer sales, we used to say that you could have quality, speed, or low cost, so long as you pick any two.  If you want to operate at internet speeds, and do so on a budget, something has to give.  I'd be happy to change those priorities, but so long as we don't have time to do things right, we'll always have to make some time to do things over.

Tell ONC to use CCDA 2.1 for Stage3 / 2015 Certification for MeaningfulUse !

Comments close shortly on the ONC Certification Proposed Rule.  If you've already submitted yours, I'd still like you to tell ONC three more things:

1. HL7 is currently in the process of approving a project to update C-CDA 2.0 to 2.1 ensuring backwards compatibility with Version 1.1 named in previous Certification and Standards Rules.  This will avoid the unnecessary and potential dangerous situation of having to record two documents with dissimilar information about the same patient and encounter to support asynchronous bilateral cutover.  The project team hopes to complete this effort by July or August at the latest.
2. The changes would enable a C-CDA compliant 1.1 system to read and understand as much of a C-CDA 2.1 instance as is technically feasible.
3. We think this is a good idea, and would prefer it over other ONC suggested solutions (i.e., using 2.0 and sending two versions to support compatibility).

Click here to comment on the rule.  If you want to copy and paste my words above into your comment, feel free to do so!

     Keith

P.S. SDWG approved the PSS today!  On to the next stages.

Update on the HL7 Relevant and Pertinent Project

A team of 23 or more met today to kick off the relevant and pertinent project.  We had some wide ranging discussion about our engagement model, which probably needs a week or so to cogitate and ferment before it produces a good general outline.

So far, I'm thinking that our engagement model needs to be asking open-ended questions that we can turn into computable requirements for automating the process.  I don't expect clinicians to understand fully what can and cannot be computed.  We'll have to see how that goes.

I have two external calls next week to further engage others in this project, and we now have a regularly scheduled Wednesday afternoon HL7 call from 1:30 to 2:30 pm.

Minutes from the call are on the HL7 Wiki.

Who should be in charge of developing HealthIT Standards for the US

The 21st Century Cures Act recently cleared a hurdle in the US (approval by the House Energy and Commerce committee) to go onto the next step, a vote in the House of Representatives.  Quite frankly, having read various versions of the bill, and having seen its evolution, I have to wonder who should really be doing this job.  Various people have commented, and the reaction is decidedly mixed in industry.

I'm going to focus on one simple point in the proposed legislation.  Current language for the Charter Organization suggests engagement with ANSI accredited standards organizations.  I think that is broken.  Other language in the same draft is better: "nationally or internationally recognized standard development organization".  That phrase is much more appropriate to the work in standards that has already been occurring.

There are many international players who should be engaged, such as HL7, DICOM, IHE International, IEEE, and the US TAG to ISO TC 215.  Some of these are ISO Liaisons rather than ANSI accredited (HL7 is both).  Neither IHTSDO (home of SNOMED CT) nor Regenstrief (home of LOINC) are ANSI accredited, but certainly should be engaged.

While I think HL7 should play a role in standards development for the US, it is an international organization.  I don't want to see the damage too much US influence would do to its standing among international affiliates (this damage is already occurring as a result of Meaningful Use).  If there was an HL7 US affiliate (as there should be), that would certainly be a group to be engaged with.  We also need players like IHE USA, as well as other "local" standards bodies like X12N, WEDI and NCPDP.  I call them local because they are little used outside of the US market, with almost no chance of international adoption (as far as healthcare goes).

Are we to go back to another model like HITSP?  I think not.  I hope not.  I'd really like to see this be a sustainable organization, rather than something funded by government contract, only to die when the money runs out (as the $10M appropriation would).  I've suggested other models in the past. Canada tried to bring everything under one roof and succeeded for a while, and other countries have national bodies that bring together or coordinate at least some parts of standards development.

The Challenge of Negation in Quality Measurement

One of the later discussions today in HL7 Structured Documents was how to resolve the issue of not having a way to represent certain events (encounter, procedure, supply) that did not occur.  These events are relevant in QRDA because there are now some quality measures which require being able to count numerators or denominators based on events that might not have occurred (perhaps for some reason).  For example, patient was not supplied this medication because it was out of stock.

One proposal was to allow use of the negationInd RIM attribute as an extension in these classes.  I'm vehemently opposed to this for several reasons.  Regardless of whether this extension would show up only in QRDA documents, the possibility that it could wind up back in the patient data stream as an input for providing care is reasonable.  Understanding how software mistakes happen, this creates a situation where one system could easily "misunderstand" the data, because it was never designed to do so, and at the time the design, it would never have expected its understanding to have to change. So a correctly developed system which found itself ingesting data that may have come from a quality management pathway, could wind up introducing incorrect data into the patient record.

Structured Documents is still working on how to resolve this problem.

Some brief CCDA Updates

The C-CDA Update Project Scope statement was reviewed by Structured Documents today.  The committee has not yet approved the project, but not rejected it either.  We need a project team, and potentially some funding. We don't have much time, so I will be scrambling to see if we can still pull this off.

The kickoff meeting for the Relevant and Pertinent project is presently being scheduled for next week, a Doodle poll has been sent out to the Structured Documents, Patient Care and Clinical Interoperability Council (CIC) mailing lists.  CIC signed on as a cosponsor to this project last week, and provided some great feedback.

Travel Weary

I head out today for my last travel for some short period of time (probably not long enough, at least according to my wife).  I spent last week (it seems like longer ago than that) just outside Paris near the CDG airport, at the HL7 Working group meeting.

Last Tuesday I mentioned a quickly run project to update C-CDA 2.1.  We talked with the steering division and they approved the idea in principle.  We've updated the C-CDA 2.0 Project Scope Statement and will be voting in Structured Documents later this week to approve that additional scope of work.  We'll see how that goes.  Some still want to see ONC back off to C-CDA 1.1.  While I agree that wouldn't be a bad idea, I want to make sure that the only sensible decisions they could make would lead everyone to success.  If we only leave them with the choices to back off to C-CDA 1.1, or proceed with a compatible but rather difficult to use C-CDA 2.0 (at least with regard to asynchrounous bilateral cutover), then we could wind up in a very challenging situation.  Given that ONC invested in the 2.0 work, I'm sure they'd like to see it be adopted.  There's some important material in that package (Care Plans) that we really need to meet some of the MU Stage 3 goals.

At the same time, we are also planning the kick-off meeting for the Relevant and Pertinent project to occur some time after Memorial day.  I already have an introductory call scheduled with the Health Story project the first week of June.  We probably won't begin the official engagement with them until later.  The Clinical Interoperability Council also signed onto the project last week.

Keeping up with school this term has been a little bit challenging, but fortunately I've only got four credit hours.  I must have been prescient when I scheduled things that way.  I have a lot more to line up for myself there, and I'm way behind on some of my planning, but will be able to catch up in the next couple of weeks.

I'm looking forward to meeting up with friends this coming Memorial day.  I managed to get the lawnmowers working this weekend and cut about 2 of my nearly 3 acres.  The tractor that came with the place does a good job.  I also cut up about half a cord of wood for drying and later splitting.  I have about another half-cord to finish with.  Before I left for HL7 I had someone come out and cut down the three trees in my side yard that were rotting and dying (one had half fallen over the week before).

Dual CCDA Reprise and an Action Item for You!

One of the issues that has been taking up my time over the last five weeks is an evaluation of the backwards compatibility issues between C-CDA 2.0 and C-CDA 1.1 with the Structured Document workgroup at HL7.

There are basically three different kinds of problems and one non-problem that we thought we might find:

1. Things that just don't work without a fix to one specification or the other.
2. Things that do work, but which are ugly if we are to use them, and so we'd like to make some changes to resolve them.
3. Things that could work but might need some clarification or explanation as to how to resolve in the Asynchronous Bilateral Cutover case where a dual-capable C-CDA was being used.
4. Things that simply work (which isn't really a problem).

There are also three different levels of compatibility that we likely needed to address:

1. Cases where the incorporate provisions of the rule would be impacted.  These are cases where the C-CDA entries are required to be transferred in some way to the EHR, such as with problems, medications, and medication allergies.
2. Cases where the viewing requirements might be impacted (different section requirements), or where clinical content varied between versions of a document.  For example, the Care Plan Section in C-CDA 1.1 includes Goals content, but in 2.0, there is a separate goals section.
3. Cases where other ("secondary") uses of the content, such as with quality measures, would potentially be impacted. These are not specifically requirements of the Certification rule, but are capabilities that some have used to facilitate other requirements.

The essential feedback from the evaluation is that it is technically feasible to create a C-CDA document that supports both specifications and which might be understood by both systems. However, such a solution seems to be more technically challenging that any would like.  HL7 members think we can do better.

The solution appears to be to quickly issue a DSTU Update of C-CDA to address these issues. Because of the timing of the regulation, we think this might be workable, but there are still a bunch of ducks we need to get in a row and then shot down.

SDWG will be seeking advice from its steering division and the TSC this evening, and will likely be taking action on it based on the outcomes.  I will report more on this later in the week (perhaps as early as tomorrow). Those I have discussed this with seem to think that it is feasible.

We have maybe six weeks to accomplish this task.  Due to the work of the Dual C-CDA task force we have an idea of what changes would need to be quickly implemented.  Here is how I think the timing works:

The ONC comment period closes in a month.  They will take at least two months to review the comments and produce a new rule, perhaps three.  One month before they submit the final rule, they have to have the published content available.  That gives us six weeks (not counting this one) to get 'er done.

Your action item is to reference an updated C-CDA in your comments on the Standards and Certification rule.  The only way to ensure that ONC references a new edition is for a) HL7 to make one available quickly, and B) for you to make comments referencing the C-CDA DSTU Update.

To submit a comment, click the link above, and hit the SUBMIT A FORMAL COMMENT button on the right hand size underneath the the title.

Haven't I seen this pattern somewhere else?

With thanks to Randal Monroe, creator of XKCD as always.

Experts don't need usability

Or at least that is what I get out of the for comment only ballot on the EHR Usability Criteria from HL7.

How have they failed HL7 Membership?  Let me count the ways:

The overview to the spreadsheet contains no descriptions of the structure or columns.
Information is presented in hard to read color combinations where there is no explanation of the meaning of the different colors used.  In one column, there are five different background colors in use, and two different text colors, with no indication as to why these colors are used.

In a ten column layout for 610 rows, six of those columns are blank more than 85% of the time. Three are blank more than 95% of the time, and 100% is blank all of the time.  Why is this material even there?

The table appears itself to be denormalized representation of two different kinds of row, a "header row", for which one or more conformance rows appear. The overlap between rows is distinguished by a single column named TYPE, for which no explanation of the codes in it appear anywhere.  Of the six columns usually containing data (see above), four apply to one TYPE, and two to another.

Finally, if HL7 wants this work to be taken seriously, it had better work on demonstrating it has a clue about the usability of documentation and specifications.  While I am encouraged about progess made in C-CDA HTML views in Structure documents, this is at the other end of the spectrum (the opposite of progress ... which much be congress).

This should never have happened, and if I see material like this again, I'll do my best to encourage the behavior that it represents: revolting.

My advice to this committee is simple: Get some usability help, and stop using inappropriately configured tools.