Digital Transformation is not computerizing paper forms

This is very related to what we are trying to accomplish with CREDS, and so is sort of a followup to my previous post on CREDS, but is more broadly scoped.

It starts here with this tweet, but not really.  It actually starts with all of the work that people have had to do to mediate between the data in the EHR, and measurement of what that data actually means.

It boils down simply to how one asks questions in order to perform a measurement.

In the early days of quality measurement and/or registry reporting, it was not uncommon to see questions like this:

• Does this patient qualify for XYZ treatment?
• Has the patient been prescribed/given XYZ treatment?
• Is XYZ treatment contraindicated and/or refused?

And, the reporting formats be structured in Yes/No form in some sort of XML or other format.

It's gotten to the point that some of these questions and their possible answers have been encoded in LOINC.  Now, when used for a survey or assessment instrument, that use is fine.  

But for most registry reporting or quality measurement activities, this should really be handled in a different fashion.  This is a start, and can be written in Clinical Quality Language format, or even more simply in a FHIRPath Expression.

• Does this patient have any of the [XYZ Indications ValueSet]?
• Has this patient been prescribed/given [XYZ Treatment ValueSet]?
• Does this patient have [XYZ Treatment Contraindications ValueSet]?

The theme in this restructuring is: Ask the provider what they know and did, and define the logic to compute it.  But even better is to ask the provider what they know and did (and recorded), and have the quality measure reviewer actually do the compute on the quality measure.

Apply normal workflows to keep track of what is learned and done; these shouldn't be interrupted.  I can recall a case where normal workflow added a checkbox to an EHR screen just to get a clinician to acknowledge that they had reviewed and/or reconciled the medication list.

Building these value sets and the logic to evaluate them is hard.  Doing it so that it is interoperable across systems is also hard.  But honestly, the cost per provider to do this is so much less to do it once and do it well, than it is to have hundreds or thousands of systems all need to do this is much more costly, and likely to introduce differences in the compute, and variability in the reported values.

Stop asking for the answers, start asking for the existing evidence to get the answers you need consistently.  And if you cannot get the existing evidence, ask yourself why before asking that it be added to the normal workflow.

   Keith

Differences between SANER and Quality Reporting Measures

 

As I work through SANER IG Development, more of the content is being focused on explaining measures of situation awareness and how they differ from measures for quality reporting.  While quality reporting and situation awareness measures share some of the same structures, they have different rules of engagement.

1. Quality Reporting measures are expected to remain stable, Situation Awareness measures need to adapt to a changing environment and needs.
   
   
2. Quality Reporting measures have a longer time frame to implementation (e.g., months), situation awareness measures are much shorter (weeks or even days).
   
   
3. Quality Reporting measures have an identifiable financial return on investment based on payer and federal quality management and improvement programs (e.g., MIPS, MACRA, ACOs), Situation Awareness measures: Not so much.
   
   
4. Hospitals are directly incented for quality measurement implementation with enough $ for a positive bottom line impact. While there are some reimbursement programs available (e.g., to states for emergency preparedness), those $ generally flow to states and through them to facilities, and generally only offset some of the costs of implementation.
   
   
5. Situation Awareness measurement programs are driven by government mandates, Quality Reporting measures are incented by government payments.  It's a very thin gray line, because for most, the "incentives" are effectively mandatory for many implementers, but the fact that there's a payment involved means that the drivers for implementation inside an organization do exist for quality measurement.
   
   
6. Quality measures come out of the healthcare space, Situation Awareness measures come from emergency preparedness and response space.  The intersection between these skill sets results in a smaller group of SMEs familiar with both sides (and I'm not fully there yet).

Building software that builds software enforces quality

There's an interesting discussion over on the AMIA Implementation list server about software quality. As is often the case in many of my posts, it intersected with something I'm currently working on, which is a code generator to automate FHIR Mapping.  Basically I'm building software that builds software.

You find out a lot of things when you do that.  First of all, it is difficult to do well.  Secondly, it's very hard to create subtle bugs.  When you break something, you break it big time, and its usually quite obvious.  The most common result is that the produced software doesn't even compile.  The reason for this has to do with the volume of code produced.  A software generator often creates hundreds or thousands of times more software than went into it.  And even though it is difficult to do well, when you do it that way, you can produce 10, 20 or even 100 times the code that you would otherwise, with extremely high quality.

Software generators are like factories, only better, in this way.  If a component on the assembly line is bad (a nut, a bolt, et cetera), that results in a minor defect.  But ALL of the materials produced by a software generator with a very small exception are created by automation.  And a single failure anywhere in the production line halts assembly.  You get not one failure, but thousands.  The rare one-offs that you do get can almost always be attributed to bad inputs and a rare cosmic radiation event. Most of  the time we are dealing with electrons and copies of electrons; we never have just one bad bolt.  We have thousands of copies of that bad bolt.

Another interesting thing happens when you use code generators, especially if you are as anal retentive as I am about eliminating unnecessary code.  You will often find that the code you are generating is exactly the same with the exception of a few parameters which can often be determined at generation time.  When this happens, what you should do is base the class you are generating on a common base class, and move that code to the base class, with the template parameters that you specify.  This is a great way to reduce code bloat.  Rather than having fifteen methods that all do the same thing, the superclass method can do the common stuff, and the specialized stuff can be moved to specialization methods in the derived class.  Template parameters can help here as well.

In the example I'm working on, my individual resource providers all implement the basic getResourceById() method of a HAPI IResourceProvider in the same way, with specialized bits delegated to the derived class.  That's 35 lines of code that I don't have to duplicate across some 48 different FHIR resources.  I really only have to test it once to verify that it does what it is supposed to do in 48 different places.  If I was writing that same code 48 times, I guarantee that I'd do it differently at least once (if I didn't go crazy first).  No sane engineer would ever write the same code 48 times, so nobody using code generation should make the software do it that way either.

I once worked with a developer that generated a half million lines of code in this fashion.  In over two years of testing, implementation and deployment, his code generated a grand total of 5 defects.  For him, we could translate the traditional defects/KLOC metric to defects/MLOC, and he still still outperformed the next best developer by an order of magnitude.

That, my friends, is software engineering.

   Keith

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.

Principles of Standards Selection for use by the HITSC Clinical Quality Workgroup

One of the work items that I was asked to develop for the Clinical Quality Workgroup was to consolidate the principles I presented a couple of weeks ago into a short list of generally applicable principles.

• Fits into the existing/planned architecture
• Meets program goals and requirements
• Is well-suited and/or designed for the purpose
• Widely recognized, well-established, mature
• Has, or is expected to have implementation, adoption and use
• Testable and tested
• Has SDO support
• Readily available w/o encumbrances
• Low Complexity
• Extensible

Building from that are a list of questions that we could use to help with that assessment.

• What is our Architecture?
• The $64,000 question
• What are we trying to do?
• Does our architecture need to change to support that?
• Is this standard designed to do that?
• If not, why is it still a good fit?
• What risks are we willing to take?
• How mature is it?
• If new, does it build on previous knowledge?
• Has it ever been used in real world environment?
• Has it been tested?
• Can I get it today?
• Who maintains it?
• Is it easily and inexpensively implemented?
• Is it future-proof and adaptable to change?

My recommendation is that we present this to the HIT Standards Committee as something that could be considered as a process that is generally applicable.  Also, that a work stream be started to understand the architecture that we have.  I'd love to see a short slide deck presenting a block diagram that shows at a very high level what we currently have, and how the pieces already fit together.  I think the NwHIN Power Team and the Security/Privacy Work group already have the necessary expertise to address these issues relatively quickly.

On the what we are trying to do question, I was asked to explain what I meant by that.  From my perspective the question our workgroup was tasked with amounts to this:
What are the standards that support prospective assessment of what we need to do to provide quality care, and what we need to do to assess whether or not quality care was provided.  We typically call the former Clinical Decision Support, and the latter Clinical Quality Measures.

As I mentioned a couple weeks ago, there is ongoing work to harmonize the CDS and CQM standards within HL7, and we will see some of those outputs in the coming months.  I believe these efforts are better placed to support where we should be headed in the future, and they are a progression of existing standards HeD and HQMF Release 2 that we could start getting experience with in the next round.

   Keith

P.S.  I'm know I'm behind on posting, but I think I've finally caught up with myself.

Clinical Quality Workgroup discusses Standards Selection Criteria for CDS and CQM

Today I got to present to the HIT Standards Clinical Quality Workgroup on principles for standards selection.  I had raised the point at our last meeting that it would be good if, before we started selecting standards, we actually understood the principles behind which such a selection was made.

A lot of work has already been done in this area, as I reminded the workgroup.  I started from first principles as to why consensus standards are desirable, moving to a derivation from NIST's Guiding Principles for Identifying Standards for Implementation as found in the Framework and Roadmap for Smart Grid Interoperability, and then on to principles found in HITSP's Tier 2 standards evaluation criteria, and the unwritten principles (now written down) for IHE standards selection, and the written principles for taking a profile to final text.

Then I gave an overview of the feedback I had received from many interested parties who responded to this post, or whom I found it interesting to talk to about the issue, including the guy who labels himself as "a dumb family doc" but is now sitting in the National Coordinator's seat (he wasn't at the time I asked). Next time around I get to summarize this into a strawman proposal for the workgroup (the reward for a job well-done is another job).

There was a really great question from the caller from AHRQ, which was related to the point I raised about what is our standards architecture for Meaningful Use. After all, if you don't plan one, it just sort of happens. I'm hoping we can discuss that on a future call. I have some idea about what sort of architecture could be extracted from that program.

The transcript will be posted later, and you can find the materials and a subsequent transcript of what was discussed on the HIT FACA Web Site. Here are my slides:


We took the list of specifications above, and parceled out the pieces into slide 5, and put it on a white board [this picture is after we cleaned it up].

As you can see, there is plenty of overlap.  We also noted quite a bit of gap, because we are missing (actually, it exists, but it's lore rather than publication) a lot of specifications where we agree (at the conceptual level). 

In fact, we agreed that at the conceptual level, we are almost in complete agreement.  The one place where we have some variation is between QDM and HL7 Clinical Statements, where there are some disconnects.  There is also a great deal of consistency at the platform independent information model level.

One of the realizations that I came away with was that in the RIM, the rules for interpretations for how to deal with certain structures in the RIM are behavioral/interpretation models ion the computation viewpoint space, rather than logical models in the information viewpoint (e.g., joinCondition has implied behaviors).

There's plenty of work to turn this diagram into an Architecture, and that's what I'll be spending the rest of my week on (when I'm not doing other things).

I was extremely pleased with how this workout went.  We had a room filled to the brim (nearly 50 people) who were writing on post-its and pasting them up on this diagram.  We came to an agreement on where we agree and disagree, and we have some plans for how to move forward.  And I totally was making this up as the week was proceeding, but it worked really well.

We still disagree on some things, but now at least, we have a much better idea about where.  There was a point in the meeting where someone was talking about one thing, and I disagreed, and then we clarified what boxes we were both talking about, and were instantly back in agreement.

Clinical Quality Workgroup

The Clinical Quality Workgroup of the HIT Standards FACA met today to discuss issues around the harmonization of information models and logic for expressing CQMs and CDS and readiness of those for use in the next stages of meaningful use.  While we could have dived right into various standards, I suggested that we first establish some principles around which we would be evaluating the standards and making recommendations.  So, I was asked to make a list of said principles.  I have my notions, but I'd like to hear yours.

Here are some examples:
1.  The standards should be aligned around a common data model.
2.  The translation from representation in one standard to the other should be obvious and non-ambiguous.
3.  Value sets should be able to be separately maintained.

If you have inputs, add them as comments below (here or on Google+), or e-mail me (you can find my e-mail address on this page).

    Keith

ONC Commissioned CQM Testing Tool for MeaningfulUse

Clinical Quality Measure EHR Certification Certification of Electronic Health Record (EHR) technologies requires that EHR software products and EHR modules be tested, as applicable, for the capability to accurately capture, calculate and report the Clinical Quality Measure results. ONC has commissioned the development of the open source Cypress certification testing tool. Cypress has already encoded the measure logic required in a software implementation. The process for submitting the Cypress tool for official approval to be used in the ONC Certification Program is currently under way. The Cypress website has been and will remain updated to reflect the testing initiative.

Are we Final yet for MeaningfulUse Stage2? Perhaps Not

Apparently not.  I missed something pretty important in my review of the Standards rules with respect to quality reporting.  All I can say was that it was late...

These are two standards cited for quality reporting:

(h) Clinical quality measure data import, export, and electronic submission. Standard. HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture, (incorporated by reference in § 170.299).

-- AND --

(k) Clinical quality measure aggregate electronic submission. Standard. Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2 (incorporated by reference in § 170.299).

These are the references in 170.299:

(12) HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture, DTSU Release 2 (Universal Realm), Draft Standard for Trial Use, July 2012, IBR approved for § 170.205.

(14) Quality Reporting Document Architecture Category III, Release 1, Implementation Guide for CDA Release 2 (US Realm) Based on HL7 CDA Release 2.0, August 2012, IBR

approved for § 170.205.

Note that Number 14 is different from number 12, and that document that is still in ballot, in HL7.  So, ONC apparently cited a standard that hasn't gone through the consensus process for Meaningful Use Stage 2.  

I was saddened originally by the selection of QRDA III because I'd though what they had selected was still the early DRAFT in the Release 2 DSTU content, and we'd have to make a muddle of it to coordinate the two.  Now that it's the later draft, I'm actually happier.

I'm currently reviewing that standard now, which is why I bring this up.  So far, I have a few negatives that would require changes [following the consensus process].  I'm rather concerned that some would oppose changes because the DRAFT has been named in US Federal Regulation.  I hope that isn't the case, because the US Federal government has a process to fix a broken rule (they used it last time around for the misnamed PHIN Guide).

So, are we really final yet?  Perhaps not.  This does give me hope that we can address the language problem at the same time, but that might just be wishful thinking.

-- Keith

The Patient's Workflow

Thinks happen and then thinks happen. And this one has been very interesting to watch unfold in my brain, as I try to tie together eight impossible thinks before dinner.

---

I've been teaching quality standards this week, covering things like CDA, CCD, CCDA, QRDA, and HQMF as they relate to PQRS and QDM, and various quality improvement initiatives.  In discussion of the QRDA Release 2.0, I was explaining how structured documents had created QDM based templates, mostly starting from the CCDA templates to map to the NQF Quality Data Model.

"For some things," I said, "we had no CCDA template to represent a concept, such as for the QDM Communication area.  So, the workgroup created communication templates that specialize for the different domain specific attributes, sender and receiver.  The possible values for sender and receiver include patient and provider (and also information systems, if I remember correctly).  So, the workgroup created three templates to support quality measures around provider communication:

• Communication from Patient to Provider 

• Communication from Provider to Patient

• Communication from Provider to Provider

They didn't include Communication from Patient to Patient, because that doesn't include provider communications."

But then my S4PM badge poked me in the chest (which is amazingly difficult, given its sitting in a coat pocket 2000 miles from me), and I wondered a bit more about this idea.

I had a routine physical examination a couple of weeks ago, and my provider successfully met a possible quality measure with me via:  Communication from Patient to Patient Recommended.  This is QDM speak to say that this was an action he performed, where the category was "Communication", the domain specific attributes were sender=patient and reciever=patient, and the state of action was "Recommended".  The recommendation was in relationship to weight loss, where he suggested Weight Watchers, because it isn't just the weekly weigh-ins that help, but rather the communication and support between members that also helps.

In a related development, Farzad tweeted this link to me earlier today.  The most interesting idea in the tweet and link was that these are not provider's quality measures, but rather quality measures belonging to a patient.  These are MY measures for the quality of care that I'm getting.  The link is worth reading because the authors talk about a mechanism whereby they evaluate a measure in relationship to the patient, not the provider.

We've been having some discussions on Patient engagement quality measures for providers at the Society for Participatory Medicine, but let's turn this back around.  What are my quality measures?

Where are the quality measures that patients (or consumers) can apply to themselves and their data?  Who is developing those?  And how will we automate them and deliver them to patients?  And how can patients use this information to improve their quality of care?

Somewhere, there has to be some research about  patients who get better outcomes because of what they do and can control, and an understanding of the benefits (and costs) that their own actions have with respect to the quality of care they receive. I imagine that most reading this by now are going to focus on health and wellness actions. I'd like to shift your attention away from that, because that's not where I'm headed with this.  I'm bombarded by that data all of the time, and I have a pretty good idea what I should be doing from that perspective, and what my health and wellness quality and input data and measurements are.

What I'm really after are those things that have to do with how I as a patient relate to my healthcare system, my doctors, my payers, my employer, et cetera, that could also improve my outcomes within that system.  What data should I be tracking for that?  What are the measures?  What are the guidelines?  If I were to be diagnosed with a life-altering disease, I know that one thing I would do is join a patient community.  I already have enough information to show me that the value of that action would tremendously improve the quality of care I receive.  That's a pretty obvious case, and it's quite similar to what my doctor recommended to me for weight control, save that the patient population is different.

After thinking about this some more, I reminded myself that to improve a process, you need to document it and instrument it to measure quality.  And to do this, we need to look at the patient's quality measures from the patient's perspective.  Patient engagement and empowerment isn't about focusing on patients, but rather, returning the focus TO patients.

I don't have answers yet, just questions: What is the process from the patient's perspective?  What is the patient's workflow? What are the engaged patient's guidelines?

  -- Keith

P.S.  Even HL7 is looking at what Patient Engagement means for Health IT standards at it's plenary session this fall. I'm looking forward to see what fuel that session brings to this fire (pun intended).

Real Time Quality Measurement as Clinical Decision Support

The topic of "Real Time Quality Measurement" as "Clinical Decision Support" has come up recently in three different forums.  In the AHRQ RFI which I mentioned earlier today, in a previous face-to-face meeting of the HIT Standards Committee, and just now in the agenda for the Clinical Quality Workgroup for tomorrow's montly call.  I'm a member of that workgroup, but won't be able to attend the meeting, given that I'm in an all-day training teaching about standards for quality measurement.  As always in cases where I cannot attend the call, I read the materials and respond ahead of time to the workgroup, so that at least they have my input.  After rereading, I decided to share it as this post:

On the topic of conceptualizing CDS as real-time quality measurement, you’ve hit one of my favorite discussion topics.

Quality measurement is intended for process improvement. One of the first steps in process improvement is documentation of quality processes. The second step is to build measurement into those processes so that progress against quality can be measured as early as possible. In clinical care, the process is a care guideline, and when that guideline is instrumented to that it can be measured, it can also be instrumented so that it can be executable. An executable clinical guideline operating against measurable inputs is clinical decision support in a very real sense.

My post on Gozinta and Gozouta is nearly three years old, yet most of what I have to say in it still applies in the current day.

What has changed in the past three years is that HQMF is now in its second release cycle, and there are significant initiatives using it, including the Measure Authoring Tool, and Query Health. There are yet more opportunities to use it to define not just how a quality measure is computed, but also to define the inputs (and possibly even outputs) of a clinical decision support process. Just being able to describe the inputs to a CDS process in a way that would allow Health IT systems to automatically generate an appropriate interface to a CDS implementation would be a tremendous game changer.

This should be a consideration of the ONC S&I Framework Health eDecisions project. I have some ballot comments on HQMF Release 2.0 that HL7 will soon be publishing that will enable this kind of use, based on some earlier standards work that IHE did. That never got adopted, I think in part because a standard like HQMF was missing from the protocol. There is emerging work in the CDS space from the Clinical Decision Support Consortium (an active participant in the Health eDecisions project) that could readily take advantage of synergies between it, and HQMF as a description of the inputs it is expecting. The CDSC work takes a CCD document from an EHR and develops from it, a list of needed interventions for a patient, which it returns to the sending EHR.

The Data Criteria section of HQMF owes its existence in part to some of that early IHE work on Care Management. The idea was that the “data of interest” to the system (in the case of HQMF, data of interest to the measure) needs to be well defined. And having defined it well, and in a computer readable format, it could be used to automatically generate an input for a clinical decision support system. That input could be a CDA Document, implemented using the CCD specification, or one of the documents specified in the CCDA specifications. It need not contain all of the specified data of interest, just that data of interest that is available to the provider, in order to be useful.

Knowing what data is of interest can also be used on the EHR side to prompt the provider to ask good questions. This is yet another form of Clinical Decision Support.

One of the missing points will be trying to figure out how to specify what the outputs of the Clinical Decision Support system would look like. Here, I believe we need to do more work on care planning. The output of the CDS system can be a care plan that specifies further diagnostics, interventions or goals which might be appropriate for the patient. Specifying what the outputs look like in a way that is actionable is important. But it need not be so detailed as to suggest exactly what needs to take place and in what order, as that is a case where systems might innovate.

  -- Keith

AHRQ Request for Information on HealthIT and Quality Measurement

AHRQ recently posted 15 questions about Quality Measurement in a request for information from the public.  Unlike other RFIs I've seen lately, this one is remarkably clear and concise.  Even so, I thought it would be interesting to try an summarize the fifteen questions even further.  Sometimes I find restating the question in simpler terms makes them easier to answer:

1. Who are you and why should we care?
2. Whose voice isn't being heard and how can we make it louder?
3. What do you think is hard and how could it be made easier?
4. How should we talk to patients?
5. Measure developers?
6. How is quality measurement related to clinical decision support?  Are they the same thing?
7. How can we go faster without making your life impossible?
8. Is MAT Helping?  What else could we do?
9. What about Natural Language Processing?
10. What do we need to deal with longitudinal data?  
11. How should we talk to doctors?
12. How do we get stakeholders to talk to each other?
13. How can we move away from claims based CQMs?
14. What have you found to be successful?
15. Please show us ... (some of us are from Missouri)...

These are great questions, and I'll be thinking about some of the answers over the coming weeks.  The deadline for responses is August 20th, 2012.

NQF Quality Data Model Update June 2012 Comment Period now open!

This appeared in my inbox. NQF is announcing (with very little fan-fair) the opening of the public comment period on revisions to the Quality Data Model from now through Mid-July.

---

Greetings,

   Thank you for your interest in the Quality Data Model.  The National Quality Forum is pleased to announce that the Quality Data Model Update June 2012 and companion Style Guide are available for comment on the National Quality Forum website from June 15^th to July 16^th.

Click here to be taken to the NQF website and QDM Update June 2012 commenting tool.

HL7 Offers Free Ambassador Webinar on Quality Reporting for Meaningful Use

Health Level Seven® International

For Immediate Release

                                                                               

Contact: Andrea Ribick

+1 (734) 677-7777

andrea@HL7.org

HL7 Offers Free Ambassador Webinar—Setting the Standard for Quality Reporting and Meaningful Use

          Ann Arbor, Michigan, USA – June 13, 2012 – Health Level Seven^® International (HL7^®), the global authority for interoperability and standards in healthcare information technology with members in 55 countries, will present a complimentary Ambassador webinar titled “Setting the Standard for Quality Reporting and Meaningful Use” on Monday, June 18, from 1:00 – 2:00 pm EDT.

Significant efforts are underway in the U.S. and elsewhere to develop an end-to-end approach to quality reporting from electronic health records.  This webinar will cover the latest on the evolving interoperability standards being developed by HL7 in support of quality reporting (including eMeasure, Quality Reporting Document Architecture, and Consolidated CDA).  It will provide an overview of these standards and discuss their relationship to proposed requirements for Meaningful Use of certified EHRs in the U.S. 

Bob Dolin, MD, FACP, president and chief medical officer at Lantana Consulting Group, vice chair of HL7 International, and co-chair of the HL7 Structured Documents Work Group, will be presenting the webinar. Dr. Dolin is a co-editor of both the CDA^® standard and the CCD implementation guide. Dr. Dolin has also been the co-editor of many CDA-based implementation guides, including the greenCDA^®.

          To register for this free webinar, please visit http://www.hl7.org/events/ambassador201206/.

          HL7 Ambassadors present standardized presentations about HL7 as speaker volunteers. They are available to present at local, regional or national conferences. Please contact HL7 at +1 (734) 677-7777 if you would like to schedule an HL7 Ambassador for an upcoming event.

About Health Level Seven International (HL7)

Founded in 1987, Health Level Seven International is the global authority for healthcare information interoperability and standards with affiliates established in more than 30 countries. HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s more than 2,300 members represent approximately 500 corporate members, which include more than 90 percent of the information systems vendors serving healthcare. HL7 collaborates with other standards developers and provider, payer, philanthropic and government agencies at the highest levels to ensure the development of comprehensive and reliable standards and successful interoperability efforts.

HL7’s endeavors are sponsored, in part, by the support of its benefactors: Abbott; Accenture; Allscripts; Booz Allen Hamilton; Centers for Disease Control and Prevention; Duke Translational Medicine Institute; Epic; European Medicines Agency; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; Hospital Corporation American (HCA); IBM; InterSystems Corporation; Kaiser Permanente; Lockheed Martin; McKesson Provider Technology; Microsoft Corporation; NICTIZ National Healthcare; Novartis; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; Quest Diagnostics Inc.; Siemens Healthcare; Thomson Reuters; the U.S. Department of Defense, Military Health System; and the U.S. Department of Veterans Affairs.

Numerous HL7 Affiliates have been established around the globe including Argentina, Australia, Austria, Bosnia and Herzegovina, Brazil, Canada, Chile, China, Croatia, Czech Republic, Finland, France, Germany, Greece, Hong Kong, India, Italy, Japan, Korea, Luxembourg, Netherlands, New Zealand, Norway, Pakistan, Puerto Rico, Romania, Russia, Singapore, Spain, Sweden, Switzerland, Taiwan, Turkey, United Kingdom, and Uruguay.

For more information, please visit: www.HL7.org

# # #

Clinical Quality Workgroup Update

The HIT Standards Committee Clinical Quality Workgroup met today to discuss the status of the recommendations of the Essential Components (Value Set) Tiger Team, and the Optimal Characteristics Tiger Team.

The Essential Components Tiger Team has pretty much completed our initial scope of work, resulting in four recommendations:

1. Establish NLM as a single authority for the validation of value sets used in Stage 2 quality measures.
2. ONC should expedite recommendations of the Implementation Workgroup (Jan 2012) and Vocabulary Task Force (April 2010) related to establishment of a publicly available value set repository.
3. The value set repository established by NLM should build upon the IHE Sharing Value Sets (SVS) profile for storing and serving value sets, and incorporate Common Terminology Service 2 (CTS2) methods for managing vocabularies referenced by value sets.
4. Establish a web service for human and machine consumption of Meaningful Use 2 value sets. Consider NLM, AHRQ, or CDC as the Internet host for validated value sets.

Some of the interesting points made on the call today:

1. The value set format selected describes the expanded value set, rather than the definition.  Looking forward, there should be a way to express the definition of a value set also.
2. ONC should consider making available a forum where the public can report issues and/or questions raised about value sets.  That forum should be publicly available so that the public can also see what the status of current issues are, and what if any resolutions or answers are available.

You can find the slides below.

---

Clinical Quality Workgroup -- Essential Elements Tiger Team

The HIT Standards Clinical Quality Workgroup is rapidly closing in on its initial recommendations for making value sets accessible.  We reviewed 4 recommendations on our call yesterday:

Within our scope was making recommendations in support of a short-term value set infrastructure enabling Stage 2 quality measure deployment.  Out of scope was the longer term infrastructure.  

The recommendations we discussed are listed below briefly.

1. Establish NLM as a single authority to validate value sets used in Stage 2 quality measures.
2. Ask ONC to expedite recommendations made by the workgroup in January this year (especially see slide 20) and by the Vocabulary Task force in April of 2010 (powerpoint).
3. Specify the standards to use for exchange of value sets.  Two choices were presented:
1. IHE Sharing Value Sets
2. HL7/OMG Clinical Terminology Services 2.0
4. Enable web access for human and machine readable consumption. 

On the first two topics, the workgroup appeared to be in good agreement.

CTS2 and IHE SVS

I was caught a bit off-guard with respect to recommendation #3 becausethe workgroup had already developed a consensus on recommending the IHE SVS profile on the call last week.  It appears that there were some observers that were concerned about the use of that profile, especially since such a recommendation appeared to exclude the use of CTS in the architecture (even though it doesn't as I explain below).

The situation is a bit confusing for many:  The IHE Sharing Value Sets profile is a simple implementation of two of the APIs described in the CTS 1 and CTS 2 specifications.  It is designed for a very simple use case of searching for and downloading value sets.  It is NOT designed to support broad management capabilities needed to maintain, validate or curate value sets.

The CTS standard originated as version 1.0 in HL7.  CTS 2.0 became a joint HL7/OMG work effort, with HL7 defining essentially a functional specification, and OMG defining an implementation of that functionality.  This pattern has been used in many HL7 / OMG collaborations. 

I think the reason that the workgroup struggled with the question is because the scope was sharply defined with respect to implementation urgency.  If you are going to develop a vocabulary (value set) maintenance infrastructure, you should be applying an architecture that accounts for standards like CTS, whether your view be short term or long term.  However, regardless of what the architecture is, for the purpose of deployment of value sets to Health IT systems.  They don't need an extensive API in order to access identified value sets.  What they need is very simple.

As always, when posed with an either/or question, the answer is usually to restate the question.  Both CTS2 and IHE SVS are pertinent and appropriate for the infrastructure.  The Infrastructure should be oriented around CTS (long term), but APIs to access and download value sets should include IHE SVS (short term). 

Enabling Web Access

On the final recommendation, the workgroup also struggled a bit.  We kept falling into the trap of solution vs. requirement. The key requirement for web access is that there be a single source of truth for value sets.  Whether that requirement is met by a single host (web site) through which access is granted, or multiple hosts accessing a singular database or service supplying the content, or a model of deployment supported via replication or federation is not material.  We were well in agreement on there being a single source of truth for value set deployment but kept getting confused in drafting our recommendation by specifying solutions that meet that goal.

Coordination

There was insufficient time for me to bring up one issue that I am concerned about.  At present, NLM, AHRQ, CDC and ONC are all expending efforts on managing vocabulary and/or value sets for a variety of different purposes.  I'd like to see better use of HHS resources applied to the management of vocabulary and value sets, without so much duplication of effort.  

Clinical Quality Workgroup

Today was my first call as a member of the Clinical Quality Workgroup of the HIT Standards Committee.  This work group is chartered with:

• Recommending technical standards for eMeasures
• Recommendations for Managing the Quality Measure lifecycle.
• Improving Usability and Integration of quality measures into healthcare processes.
• Suggesting how to link e-Measures with Clinical Decision Support
• Identifying Responsible Stewards for eMeasures and their components

Much of today's discussion in the workgroup was around our charter, and the eMeasure life-cycle depicted below.

This looks a bit like a waterfall development model.  I raised the issue that quality measurement really needs to be built-in with the definition of the process (the clinical guideline) whose outcome you are trying to measure.  A number of other work group members echoed my concerns.

One of the members of the workgroup pointed out that the current processes for developing quality measures today are developed around the abstracting paradigm, and that when you re-architect them to support an EHR-based paradigm, the definition of what you are measuring will likely change.  Both measures might achieve the same objective, but would not necessarily be comparable.

An issue that we didn't get to talk about was how this workgroup, or HITSC would better communicate it's needs around quality measures to the relevant SDOs which are actively working in this area. Fortunately, those organizations are very well represented by members of the workgroup, including HL7, NQF, S&I Framework/Query Health, IHE, ISO, and others.

The workgroup is dividing up into two tiger teams.   One is tactical, and that is where much of the work I've been doing on Query Health and HQMF applies.  The other is strategic, and really focused on the overall process, which is where I have a great deal of interest.  As the ONC rep put it, you can be on as many as you like, just remember that you are the one who will be aware of the impact it has on your calendar.

Oh well, I guess that anything worth doing, is probably worth being double-booked for.

    Keith

Half of ACO Quality Measures are in MeaningfulUse

I was doing a review of the ACO Quality Measures yesterday.  One thing I noted was that at least half of them are also in Meaningful Use.  The cool thing about that is that this team has already reported that most MU measures can be computed from the HITSP C32 with the addition of procedures section, and that nearly all can be addressed by adding smoking status and vitals (see pages 4-6 of their paper).

What about the other half?  Well, six of them come from what will now be a CMS supported survey, three of them come from claims data, and another one comes from Meaningful Use attestation reports.  So, of the remainder, what isn't in Meaningful Use Stage 1, and can it be computed from the HITSP C32?

These are the remaining measures:

1. Medication Reconciliation at Discharge (NQF #97)
2. Fall Risk Screening (NQF #101)
3. Depression Screening (NQF #418)
4. Proportion of Adults 18+ who had their Blood Pressure Measured within the preceding 2 years (CMS)
5. Diabetes Measures (NQF #729
6. Ischemic Vascular Disease (IVD): Complete Lipid Profile and LDL Control (NQF #75)
7. Treatment for CAD w/ Diabetes/LVSD (NQF #66)

Looking at each of these:

Fall Risk (#2) and Depression (#3) screening assessment scores can be recorded in the HITSP C32 Results section.  So, if you find an assessment result, you can tell that these have been done.

The diabetes measures (#5) are from the MN Community Measurement instrument.  These account for five separate measures in the ACO rule and are very simple to compute from CCD medications, results, vital signs or social history (for tobacco use) sections:

1. HgA1C < 8
2. LDL < 100
3. BP < 140/90
4. Tobacco Non-Use
5. Aspirin Use

The IVD (#6) and CAD (#7) measures can also be readily computed, as they are very similar to other computable results in Meaningful Use stage 1.

That just leaves #1, Medication Reconciliation on discharge.  Because the CCD is not a discharge summary, you'd really want to look at a different document to compute that measure.  But if you did open up a discharge summary, and found one of the required entries of the IHE RECON profile, you could be assured that medication reconciliation was performed at discharge.

So, half of ACO measures are meaningful use measures, and you should be able to compute nearly all of the the other half from the standards already required for Meaningful Use stage 1.  And it could even get better under stage 2 when we have other documents supported for Transitions of Care.

NQF: Quality Measure Webinars

Another release from NQF related to Quality Data Model...

---

October 11, 2011 Join NQF for two upcoming webinars focused on the latest version of the Quality Data Model and the recently-launched Measuring Authoring Tool, respectively. On Wednesday, October 19, NQF staff will host “The Quality Data Model (QDM): Version 2011,” where discussion will focus on the latest changes to the current QDM draft standard – now out for public comment – and its impact on measure development and care delivery. The presentation will conclude with discussion and Q&A. Register now. On Thursday, October 27, NQF staff will host “The Measure Authoring Tool (MAT): An Introduction.” Discussion will focus on key features and functionalities of the MAT, as well as its importance in advancing electronic measure (eMeasure) development. Participants will learn how the MAT “creates” an eMeasure, and hear key questions to consider before using the MAT. Following the presentation will be discussion and Q&A. Register now.  National Quality Forum | 601 13th Street NW, Suite 500N, Washington DC 20005 | 202.783.1300 | Unsubscribe