Stages of Standards Development

One of the most amusing things (because if I didn't laugh I might cry) about the Meaningful Use program is the way that executives who have never paid anything more but lip service to standards are now reporting as experts on their effectiveness (or lack thereof) and the related causes.  Reports out of the HIT Standards committee about the need for improvement of CCDA are a perfect example of this.  However, the problems being reported almost certainly aren't the real problems that need to be addressed.

I have a theory about Stages of Standards Development that is fairly similar to Lohlberg's stages of development, but applied to standards and interoperability.

1. We used this standard because we would get punished (or not rewarded) if we didn't.
2. We used this standard because you told us too.
3. We used this standard because everyone else is using it too for this problem.
4. We used this standard because we are actually paying attention to interoperability.

In the first stage, the use of the standard is to avoid punishment.  Application and understanding of the standard is low.  The minimum work is done to pass the tests, and no thought or effort is put into the use of the standard to do anything more than to comply with the requirement.

The second stage is no much different, other than the user of the standard now recognizes authority, and may actually understand that there is a reason for being granted the authority.  So they may pay a little bit more attention to the standard, but don't really yet understand it.

The third stage is when the user of the standard looks around and sees that lots of other folks are using the same standard, and they could benefit from it as well.  In this stage, there are some they can learn from who are at more advanced stages and others who are not.  At this stage, they pay quite a bit of attention to learning as much as they can about the standard to make it work.

In the final stage, they stop worrying so much about the standard, and really start focusing on the intent and purpose of it, which is to enable interoperability between systems.  They stop looking at all the slavish ways the standard can magically solve the interoperability problem for them, and start realizing that standards are a major component of interoperability, but that other things are needed to support it as well.

Meaningful Use will only take us so far over time.  Stage 1 and the 2011 criteria only enabled level 1 and 2 adoption behaviors.  Stage 2 and the 2014 (Release 1 and 2) criteria starts to enable level 3 adoption behaviors, and creates an environment where level 4 behaviors can emerge.  But they do nothing to support level 4 behaviors.  The REC program supported some higher level behaviors, but it too really only stopped at level 3.  The workforce education program may have contributed a bit more to higher levels.  The Beacon program certainly tried to support level 4.  However, most of the money for these programs is well past gone.

Interoperability is a journey.  Standards are an important tool along that journey that are necessary. But most don't even know how long that journey really takes.  We had RFC-822 and before that RFC-561, and even today, after more than 4 decades, e-mail is still not perfectly interoperable. Remember Lao-Tzu: The journey of a thousand miles begins with a single step.  We've taken a few so far, let's keep going.

ONC 2014 Edition Release 2

ONC figured out that it had a versioning problem with it's third release of the Certification and Standards rule.  This one (original entitled the 2015 edition) has been renamed to the 2014 Edition, Release 2.

What's new?  Not a lot actually.  As originally envisioned, there were plenty of changes coming to EHR vendors and users.  As written, it's a much smaller list of changes for everyone, which I summarize below.  A lot of what I complained about in the proposed rule is gone from the final rule. Other issues have simply been put off until stage 3 and 2017. In their own words ONC has "not adopted the Proposed Voluntary Edition. Rather, we have only  adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange."

• Split CPOE into separate criteria for ordering Medications, labs and imaging.
• Decoupled content and transport capabilities for transitions of care
• Shifting the “incorporation” into an updated “clinical information reconciliation and incorporation” (CIRI) criterion.
• Adopted Version 1.1 of Direct Edge Protocols
• Decoupled the transport and content capabilities of the VDT certification criterion.
• Allowed "any method or standard" to be used to "electronically create syndrome-based public health surveillance information for electronic transmission" for ambulatory use.  The net effect here is to enable meaningful users to claim the capability for the purpose of incentives if they electronically transmit surveillance data to public health.
• Included an optional set of data elements (patient demographics, provider specialty, provider address, problem list, vital signs, laboratory results, procedures, medications, and insurance) to support surveillance.  This optional list on an optional criteria, basically serves the purpose of telling people the eventual direction they might go in a couple of years.
• Discontinued use of the Complete EHR concept and Complete EHR certification
• Created an ONC Certification Mark

There you have it, an even shorter summary of the short list of what ONC has added to certification in 2014.

---

I forgot to include Table 3 from the rule, which lists the differences between the various editions. It is quite useful

Table 3. Gap Certification Eligibility for 2014 Edition, Release 2 EHR Certification Criteria
2014 Edition Release 2		2014 Edition		2011 Edition
Regulation Section	Title of Regulation Paragraph	Regulation Section	Title of Regulation Paragraph	Regulation Section	Title of Regulation Paragraph
314(a)(18)	Optional – computerized physician order entry -medications	314(a)(1)	Computerized physician order entry	304(a) 306(a)	Computerized physician order entry
314(a)(19)	Optional – computerized physician order entry - laboratory
314(a)(20)	Optional – computerized physician order entry – diagnostic imaging
314(f)(7)*	Optional – ambulatory setting only – transmission to public health agencies – syndromic surveillance	314(f)(3)	Transmission to public health agencies— syndromic surveillance (ambulatory setting only)	302(1)	Public health surveillance (ambulatory setting only)
314(h)(1)	Optional – Applicability Statement for Secure Health	314(b)(1)(i)(A) and 314(b)(2)(ii)(A)	Transitions of care—receive, display, and incorporate transition of care/referral summaries. Transitions of care—create and transmit transition of care/referral summaries.	N/A	N/A
314(h)(2)	Optional – Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging	314(b)(1)(i)(B) and 314(b)(2)(ii)(B)	Transitions of care—receive, display, and incorporate transition of care/referral summaries. Transitions of care—create and transmit transition of  care/referral summaries.	N/A	N/A
314(h)(3)	Optional –SOAP Transport and   Security Specification and XDR/XDM for Direct Messaging	314(b)(1)(i)(C) and 314(b)(2)(ii)(C)	Transitions of care—create and transmit transition of care/referral summaries.	N/A	N/A

* Gap certification does not apply for the optional data elements listed in 314(f)(7).

---

HL7 September Ballots: The Good, the Bad, and the Ugly

I should probably do this in reverse order, so that I end it on a positive note.  Yesterday was the close of the September ballot cycle.  I reviewed several ballots, but three stood out for me.  Here they are from the worst to the best.

The Ugly: Provenance

In the we need a template for every possible combination of ways to specify author and document, section or entry, this one takes the cake.  What you really need are three to five templates to represent authorship or assembly, and some policies about how they must be used in documents which conform to requirements about provenance.  This specification tries to make templates to enforce what is necessary for every possibility, instead of telling people what needs to be done in different circumstances, and expecting them to be able to follow some very general and simply policies.  Most of the requirements it tries to enforce through templates are already mechanisms by which CDA interprets authorship.  This one could use a rewrite to dramatically simplify it.

The Bad: QUICK

This one did itself in by providing evidence that it had the worst reason to develop a separate standard.  The image captured below is from section 4.7 of the overview:

The point being that if there really is that much similarity, then why not improve FHIR to meet the needs, or develop extensions.  We don't need yet another information model.  Yeah, I know, "it's ... and you have different requirements than ...," but I'm really over that argument.  

To their credit, they did ask: "Can (and should) QUICK and FHIR be harmonized into one model? If so, how could this be achieved and still meet the intent of both models? If not, how should the two models relate?"  

I'd get this one under FHIR Governance as quickly as possible and stop messing around with yet another UML model.

The Good: CQL

This isn't just good, it's actually astonishingly good.  In my early college years for my Microcomputer class, I once wrote a mini-operating system instead something simpler suggested by the instructor to solve the problem.  He presumed I had submitted something else I'd written for another purpose and didn't give me full credit until I complained to him about it.  I pointed out that it quite elegantly solved the problem he asked it to, and that when assembled (yes it was in assembly), it did exactly what he wanted (which was to support ANSI terminal emulation).

CQL looks like a similar kind of component.  It hardly looks like something that was prepared for an HL7 ballot, but frankly, it really solves the problem that it was asked to solve, which was to develop a language that would support Clinical quality and clinical decision support.  It reads well, and it has a certain elegance that things developed based on a simple model do.  I really liked this one, and it got a very rare affirmative from me on it's first ballot.  I suppose if I had been following it more closely I could have found some fault with it, but it actually looks pretty good.

Test mobile interoperability at the IHE Connectathon

Take the lead in mobile interoperability IHE is focused on incorporating new mobile capabilities into our profiles to advance interoperability, and now is the time to choose these profiles for testing at the IHE North American Connectathon. The industry is quickly moving toward an anytime/anywhere approach where care providers and individual patients need access to protected health information and lightweight devices that must be interoperable to keep your organization relevant with increasing customer demands. How will testing IHE mobile profiles advance product development? Patient Demographics Query for Mobile (PDQm) is the first IHE profile to be compliant with FHIR. PDQm allows mobile devices such as medical devices, web-based EHR/EMR applications and other mobile devices/applications to access patient demographics. Mobile Patient Demographics Query (PDQm) is offered in Connectathon testing. Mobile Access to Health Document (MHD) Profile enables transportation of medical documents from a mobile device to EHRs or PHRs. MHD is offered in New Directions testing service at the Connectathon. Why is the inclusion of FHIR (with a RESTful interface option) important to IHE profiles? FHIR is comprehensive healthcare content and representation standard developed by HL7 that utilizes REST-based transport to enable mobile healthcare applications, medical device integration and creating flexible custom workflows. IHE infrastructure supports FHIR standards as it matures to enable interoperability, offering your customers ways to streamline and improve patient care and drive down bottom line costs. HIMSS 33 W Monroe, Suite 1700 Chicago, IL 60603 www.himss.org

Is HealthIT Software Development an Informatics Job?

I'm working on a term paper for my Business of Health Informatics class.  This question cropped up while I was writing the paper.  My answer is fairly simple: it depends.  The developer writing straight forward middle-tier database access code, or implementing the service layer, or the user interface probably doesn't need (but might benefit from) informatics training,

However, the designer and architect would certainly benefit from it.

So, is it an informatics job?  No for most.  And yes for some.  In general, I would say about 2 or even 3 orders of magnitude more people writing Health IT software would answer no.

What do you think?

Three new IHE PCC Profiles for Connectathon this Year

This cross my stream this morning while on vacation, and I thought it valuable enough to share with others. Thanks to George Cole of Allscripts for getting the word out on these profiles which he edited and contributed greatly to. I especially agree with George on RECON. We updated this profile so that systems which supported "incorporate" in Meaningful Use could readily claim implementation of it. I know that's most of you out there ;-) Keith P.S. I'll be back after vacation finishes (today is the last day).

---

Hello everyone:

3 relatively new (or improved) profiles from IHE PCC for your consideration:

RECON – new and improved. Very useful for all of us to consider, so I’m hoping to see lots of systems sign up for this Reconciliation of Clinical Content and Care Providers. Your systems probably reconcile medication lists as a part of Meaningful Use, so this profile may be almost a freebie. Additionally, the content specifics for managing item identifiers will be generally useful as the use of document exchange increases.

MCV – Multiple Content Views, allows one CDA document with styleCode values from a catalog of styleCode values to be displayed for different uses; one document with a complete and also a patient view is one scenario that is possible. This may also lead to a more consistent display of content across the community.

ROL – Referral / Order Linking, for handling the roundtrip of referrals and referral responses, with content specifications to facilitate linking all related documents.

These are all new, and therefore run the risk of being dropped without sufficient interest. They are also all of such general usefulness that I really hope all of our products are interested in testing all three.

Please share with others – I know there are many more people that might consider testing these profiles. Maybe some of our famous bloggers might take up this topic to spread the word ;)

Thanks,

--george

The Impedance Mismatch

A quiz question that tripped me up today is a perfect illustration of one of the more challenging issues in developing standards: The Impedance Mismatch.  It was a true/false question of the form:

X qualitative adverb A affects Y.

According to the text:

X qualitative adverb B affects Y.

... where the degree of qualitative adverb B is greater than the degree of A (I verified that before I submitted the quiz for grading...)

Is the statement true or false?  If false, the implication is that Y is not qualitatively affected by X at least to the degree specified in A, but that is not explicitly stated, only implied by the language of the question.  If true, it does not accurately define the degree with which X affects Y.  What is happening is that a qualitative measures of slightly, moderately or heavily is being turned into an adjective for classification which is then used in a question that then has a Boolean result.

Herein lies the rub.  We have three different ways to answer a question, qualitatively on an ordinal scale, as one item from a set of classifications, or as a Boolean value.  And we haven't even touched on the various ways in which saying "I don't know" could impact it.  When looking for information to solve a problem, the challenge is often in making sure that the question being raised is asked in the right way.  When you build your forms or your interchange standards, are you dealing with the correct representation of the variety of possible answers?  If not, you could wind up with situations that cannot be adequately represented.  On the flip side, is your representation of variety so constrained as to be widely different from the data that is captured in the system that needs to communicate to the reciever?  Is it possible to infer the answer from data that is captured, if so, you might save some effort.  Making sure that the outgoing signal from one system is aligned with the incoming requirements for the other, basically that they have matched impedance, is very important to maximize information transfer.

In this particular example, the question being asked in my case was actually "Did you understand the material on how A affects B".  The outgoing signal (from the quiz) if I truly understood it, would have focused on is the work "slightly", rather than any other word in the question.  It's subtle enough (and confusing enough) that I'd almost call this a trick question except that that only trick was that the answer was cleverly evoked to see how well I did understand it.

   Keith

P.S.  This experience has provided me with a new test tasking skill that I can share: Look for qualitative adjectives in true/false questions, and test your answer against how well those apply.

P.P.S. This ends my Root Cause Analysis for how I messed up my most recent quiz.