New IHE Radiology Profiles Released for Trial Implementation

The IHE Radiology Technical Committee has just published the following supplements to the IHE Radiology Technical Framework for trial implementation as of May 30, 2014:

• Digital Breast Tomosynthesis (DBT)
• Mobile Access to Health Documents for Imaging (MHD-I)

The documents are available for download at http://ihe.net/Technical_Frameworks.

Open Data vs. Data Exchange Standards

On the NwHIN Power Team call, we were talking about HPD+ readiness for Meaningful Use.  There was general consensus on the call that this specification was too new to be consider readied for prime time.  If compared against the teams readiness criteria (recently published here in JAMIA), it likely wouldn't make the grade.

One of the discussion points was to have ONC explore the following:

1. Capture Direct addresses with other publicly accessible data currently stored in the NPI database.
2. Making that data part of the open NPI data available to developers to innovate with.

From the perspective of the need for directory information, this seems to be the most likely and best pathway to ensure that the "Directory" problem reported by users of The Direct Protocol would be available for those who need directory information to be readily available to support Direct implementations in 2014 and 2015. It also enables innovation and resolution of the problem without necessarily mandating the final solution in regulation.

I like this answer.  Maybe we should consider the problem we are trying to solve, not the solution.  After all, not every data interchange problem need be solved with a standard (whoops, did I actually say that?)

    Keith

The Customer is always Right

One advantage to working in the context of standards development is the ability to have discussions with stakeholders in standards that can be open and honest.  Could you imaging having some of the conversations that occur in Standards development in a vendor/customer context?  The only relationship more challenging that I can think of is the regulator/regulated relationship.


    Keith

Thinking Beyond Change

One of the challenges with the US Healthcare System [sic] is not in figuring out what needs to change, but rather how to implement such a change without completely tearing down everything and starting over from scratch.  Yes, tearing it all down would be very satisfying -- except to those who lost their lively-hood in the course of it.

That is the challenge.  Because any initiative to tear down a 30-year-old infrastructure will be opposed by those who are part of that infrastructure.  Any workable change strategy has to include everyone, and not write off any stakeholder.  It must provide for a mechanism to transition from one state to the next.  It isn't about figuring out the best way to do things, but rather, figuring out a better way to do things given where we are, and where we'd like to be.  This is not an engineering challenge, or not so much.  It's much more a political challenge.

Yes, you can be a great innovator and tell us how we should rebuild everything from scratch.  That's not going to be practical, nor is it likely to be implemented.  What I want you to do is show me how to get to a better place that just about everyone can support.  That's effective change, and damn it, that's really hard. It's very easy to design from a clean slate.  Our's has 30 years of chalk dust on it, and permanent marker, and chips and smudges that just won't come out.  Make it work with what we have.  That's where the real challenge is.  I love being able to deal with green fields.  But mostly we have today aren't just green fields, but cow pastures.  Be careful where you step.

   Keith

Pedaling Backwards to Move Forwards

If you guessed that this post was about the most recently released proposed rule on Meaningful Use, you would be correct (The hashtag may have helped).

The key to the whole rule is summed up nicely in one table, which I reproduce below:

If you were scheduled to demonstrate:	You would be able to attest for Meaningful Use:
	Using 2011 Edition CEHRT to do:	Using 2011 & 2014  Edition CEHRT to do:	Using 2014 Edition  CEHRT to do:
Stage 1 in 2014	2013 Stage 1 objectives and measures*	2013 Stage 1 objectives and measures*                 -OR- 2014 Stage 1 objectives and measures*	2014 Stage 1 objectives and measures
Stage 2 in 2014	2013 Stage 1 objectives and measures*	2013 Stage 1 objectives and measures*                 -OR- 2014 Stage 1 objectives and measures*                -OR- Stage 2 objectives and measures*	2014 Stage 1 objectives and measures*                  -OR- Stage 2 objectives and measures

*Only providers that could not fully implement 2014 Edition CEHRT for the reporting period in 2014 due to delays in 2014 Edition CEHRT availability.
While I could have said I told you so about crazy deadlines, I always understood that the deadlines for meaningful use stages weren't ONC's to control, but were rather set by Congress.
What I'm hoping that we all learn is that MU should be using standards that are ready for prime time, and should set the bar at the right place for success.  If we want to promote use of new standards, maybe that should be a menu option, and there should be a way to those who pilot test new standards that ONC wants to see used a way to certify based on pilot testing rather than lab testing.
I can tell you based on any pilots I've been part of, that pilot testing is certainly a higher bar than any lab-based testing I've seen for Meaningful Use or any other standards program.

Status Quo Post

Something occurred to me as I looked at how we respond to change.  We can project forward to some degree what will happen as the status quo ante becomes the status quo post, but only to a certain point.  It is very hard to imagine what things would be like if nobody ever remembered the way things were before.

Remember analog music?
... life before e-mail?
... traveling without a GPS?
... pay phones instead of cell-towers?
... slide rules?

Some of you reading this don't (I forgive you for being young).  Could you have imagined at the time these things entered our lives what life would be like when these things became so pervasive to the point that our children grew up never knowing a world without them?

So it is with change.  Not only can we not really imagine what it would be like to do this different thing, but it is very hard to imagine a culture where this new idea is the new baseline, the new normal, and our old way is completely forgotten.

As hard as it is for a technologist to do this, think again about how conservative we are in healthcare with respect to change in process, which makes it even harder to think this way.  But this is what we have to do every day.  Or will will just be the status quo ante, and then, the forgotten.

Not on my Radar Screen

Some folks have asked me why I'm not at Conference X, or what it would take to get me to Workshop Y.

When I started working as a software developer many decades (ouch) ago, one of the things that I looked
forward to was going to various conferences and workshops.  Initially, I'd get to go to about one a year.  As I grew more experienced (and older), I was able to get to maybe two a year.  Then I began speaking at some conferences, and the number increased, but the ones I spoke at weren't necessarily the ones I would have chosen to go to for career development purposes (in other words, to have fun and learn something new).  And as I went to more, the number I got to got to for "career development" actually grew shorter.

These days I get to travel to more than a dozen events annually, but the number of events which are "just for fun" (in other words, selected by me to learn something I wouldn't otherwise get in my day job) is still around one annually.

If it doesn't have to do with any of the topics to the right as related to Healthcare Standards or Interoperability, then it is likely not part of my day job responsibilities.  It might be fun, but it fits into the 1-2 that I get to go to for career development every other year or so rather than doing my day job.  And getting into that list is difficult.

Conferences that fall into this category include things like:

• Medicine X
• TedMed

Mostly I work on standards, not software.  Yes, I still use (and write) software in my day job, but that demonstrates implementation of standards, not code.  So you likely won't find me at things with names like (even when it might overlap with my day job):

• ____ Code-a-thon
• ____ Hack-a-thon

I'm not a policy wonk except where Healthcare Standards intersects with Healthcare Policy.  So you'll not usually find me at policy related events, unless they are totally focused on Healthcare Standards.  And that list is rather short and mostly on an emergency basis.

I'm not an Academic (but I am in school).  You won't likely find me at AMIA for anything work-related.  I might show up this year and next, but if I do, it may well be on my own (educational) dime.  I'm trying to fit this one into my current travel plans as my one career development conference, but when you go to as many conferences as I do, slipping in an extra one is actually harder.

My "standards portfolio" includes EHR and departmental interoperability, it doesn't include imaging, monitoring devices, pharmacy, or payer-side stuff (even though I know a bit more than a little bit about each).  I do cover public health to some degree, as well as quality.  So you won't usually find me at the interoperability showcase at RSNA, will find at HIMSS and am catch as catch-can for various public health events (depending on who you can get to drag me in).

My zone is International, but mostly focused in North America, and specifically US-based activities.  So if your conference is right in my sweet spot, but happening in Europe or Asia, one of my colleagues may likely be there, but not me unless there is another reason for me to appear.

I'm not running a Startup nor employed by one. Somehow, that also seems to rule me out as an innovator, but I don't worry about that too much.  So you won't find me at conferences devoted specifically to startups, or at innovation (unless it intersects with standards).  That's actually OK.  Innovation and Standards are actually two different tracks which have some overlap.  I also don't do "Hype of the Week/Month/Year" club stuff.  So you won't see me at things like:

• Healthdata Palooza
• Big Data Anything

Where you will find me:

• Health Level 7 Workgroup Meetings
• IHE International Events (including the upcoming IHE World Summit)
• ONC S&I Framework Activities

Note:
This doesn't mean I'm not interesting in seeing your conference, or even in attending or presenting, but it likely means that I don't have budget (and may not have the time) to attend it.

Regional Adaptations of CDA Templates

One of the outcomes of last years work in IHE on attempting to utilize the CCDA templates was an approach to template constraint for regional and national projects that can simplify documentation.

Rather than creating templates constraining a first set of adopted templates, we looked at using the realmCode element within the document to "Nationalize" or "Regionalize" or "Localize" templates. RealmCode in the HL7 RIM is defined thus:

When valued in an instance, this attribute signals the imposition of realm-specific constraints. The value of this attribute identifies the realm in question.

So this becomes a completely appropriate approach to localization for regional or national projects.

Why does this simplify things?  Because it addresses the idea that regional constraints for the use of CDA are approached from a different perspective, usually dealing with vocabulary / value-set bindings for the region, or various namespaces used for various kinds of identifiers.  In PCC we sort of cobbled together the notion of Identity domains based on the HL7 notion of Concept Domains, which allows RealmCode to be used to support binding of specific identifier namespaces to identity domains.

How would you validate these constraints?  Generally you'd do something like this using the old way of creating a new template for the locale:
In this XML Context:  //*[cda:templateId/@root='locale-specific-template-oid']
Verify this rule is true: cda:code/@code = 'X' and cda:code/@codeSystem='Y'

But using realmCode, you'd do something like this:

In this XML Context:  //*[cda:templateId/@root='standard-template-oid-adopted-by-realm' and /*/cda:realmCode/@code='locale-specific-realm-code']
Verify this rule is true: cda:code/@code = 'X' and cda:code/@codeSystem='Y'

From a locale-specific testing basis, since realmCode/@code is expected to be your locale, you could even omit that second operation, and simply invoke a set of tests when your realm is asserted in the document.

HL7 and ISO will soon be embarking upon the development of a set of internationalized templates for the CCD (and hopefully all of CCDA over a longer time period).  I'm hoping we can redefine CCDA in terms of US Realm specific requirements on that internationalized effort.  It will make all our lives that much easier.

   Keith

Because MeaningfulUse

I listened closely at three different workgroup's meetings last week at the HL7 WGM as nine different project scope statements, none of them more than 100 hours old (that's about four days) wended their way through committees last week in order to meet deadlines for a September Ballot.  What's the reason for this deadline I asked, and invariably the response is "Because ... Meaningful Use ... Standards ..."

And I laugh because I can add.  If the rule shows up in December, then you have to have the text ready in October AT THE VERY LATEST.  And the ballot is August for the September WGM, and you need at least 6 seeks to reconcile and publish as the very best speed.  Some of these projects carry forward work that has already been in flight, and others are simple add-ons, but some are truly brand new standards.  And those are the ones that make me laugh at the absurdity of it all, because if you want mature standards, newborns just don't make it, and the numbers just don't add up.

Oh Congress, what have you wrought with these crazy deadlines?  Do you even care?  Did you even care? Did you even know?  All rhetorical questions.

There are times that I wish there was a cost to members for voting for a Project Scope Statement.  I wish votes cast for a project were a scarce resource whose value could be subject to market demands.  I've wondered if there is truly a revenue model for HL7 simply around the development of standards and the execution of ballots.

Because ... I need a better reason that Meaningful Use to develop standards.

Physician, Heal Thyself...

I was reading a post over on Kevin MD today, and I just had to think "face-desk".  It's a real head knocker of a post.  This physician uses three anecdotes to explain why the current sets of quality measures are flawed and not evidence-based.  And of course, she's right, at least these examples are flawed.

But the real problem isn't the complaint, so much as it is the approach.  If it's not OK to do anecdotal medicine, why is it OK to make anecdotal complaints like this.  If you want everyone to do present high quality evidence, couldn't you at least survey the quality measures you opine are so deeply flawed and indicate whether these are the three outliers in a very small set, or three rather easily found common examples?

I don't doubt the physician reporting the problem is right to complain, but to call all the measures deeply flawed based on three fairly high profile media cases shows a misunderstanding of what it means to do the work.  At the moment, all we have is one expert's opinion.  From my recent studies, that's the lowest quality evidence we could have been presented on the topic. I'd be interested in seeing what else could be wrong here, its a shame she didn't take the obvious step.

   Keith

Just Popping in at the HL7WGM

Yesterday I had another one of those "I'm glad I came here" moments at the HL7 WGM.  I had a "free" quarter, so decided to see what was up with Claims Attachments.  They were discussing the Complete Documentation Templates specification.  One of the issues that came up was trying to identify what this thing was and several things became clear to me during the discussions:

The specification is designed to meet the needs for CMS Auditing with respect to attachments.  The payers in the room indicated that their needs were mostly met already just using the Consolidated CDA, and they didn't need further conformance requirements.  So now it seems that we could have two kinds of attachments, one required for CMS, and other that would be desired by Payers.

"How," I asked, "is this administrative simplification?"  

Several other people in the room responded positively to that query, but we never quite got an answer.

One of the issues raised by this document was how you would be ask for attachments conforming to it, rather than just the Consolidated CDA.  One proposal was to request new LOINC codes, at which point I almost exploded (OK, perhaps I did explode).  After all, the LOINC codes that are used in CCDA came out of the original Attachments guides, why did a new attachment guide using the same concepts (History and Physical, Consult, et cetera) need to have NEW LOINC codes.  If we start messing around with new LOINC codes, those codes aren't even going to show up in CCDA, so many will question whether they are even valid CCDA (they still would be since those value sets are dynamic).  One possible solution is to simply request a new LOINC modifier code, which doesn't confuse LOINC document ontology, and meets the requirement need.  That suggestion seemed to have merit, but we never decided on it.

Following all this discussion, the comment that raised up all these issues (a descriptive name for the guide) triggered a motion to rename the document.  I observed then something I've never seen in all my years of committee work, which was a tied vote which had to be broken by the chair. The motion failed, which means that we remained at status quo.  This is a good thing in my mind for a tied vote, because it is easy to move from status quo later, but hard to go back to it.

I'm sure there will be a lot more to do on this topic, the guide itself attracted quite a number of negatives (89 out of 101 votes), many of which still have to be resolved (70 out of 101) before it can move forward. There's enough negatives on this ballot that the committee may decide it needs to go out for another cycle.

Tuesday at the HL7WGM

It's already Tuesday at the HL7 Working Group Meeting.  Today I taught the CDA and XDS class to a small but very interactive International group of developers, including some from Saudi Arabia and New Zealand.  It's a fun class to teach and I was happy to be able to bring some of my experiences in Saudi Arabia to the classroom here in the US.

Monday was a good day.  My one burning issue for the week was to make sure that we finally addressed the issue of format codes for CCDA, which we resolved yesterday.  However, we also worked out (for the next FHIR DSTU), the structure of FHIR RPC services, which is essentially:

[base]/_services/FHIR/ServiceSpecificURL

And makes it pretty obvious that if you want to define your own services simply using something other that FHIR to identify your "services" namespace.  So I hadn't expected to resolve that issue so easily (even if it took nearly an entire quarter to do it).

And then finally at the Cochairs dinner (which I get an ex-officio invitation to as a Board member), it was reported that HL7 TSC has adjusted some of its procedures to ensure that we don't have a repeat of the CDA stylesheet incident.  John Quinn and the TSC by the way were all over the issue before I had even brought it up to the board last month.  And as far as it goes, I think we truly have corrected the issues that need to be corrected.

Now the decision I need to make is whether I have enough time to attend the TNP before I have to go finish my homework.

   Keith