Thursday, July 29, 2010

Meaningful Use Posters

Thanks again to Robin Raiford, most recent recipient of the Ad Hoc Harley Award, you have access to a large print poster explaining the Meaningful use rules in one large poster.  These are designed to be printed on a plotter, or viewed at 100 or 200% on a computer screen.  There are three versions, all containing the same data, depending upon the size that you want to print it at:

Robin's dedication of this work appears below:

"Meaningful Use Stage 1 Final Rule, The White Board Story" − Version 1 − July 28, 2010

 
This poster is dedicated in honor of all those who have lost loved ones since the IOM Study "To Err is Human" was published in 1999, to all those victims of Katrina who suffered or died since we could not share their records with another location, to my mom who died because she did not have the benefits of an interoperable EHR and her doctors could not share lab results across doctors and across visits, and for my nephew who is paralyzed from a medical error . . .  Please tell this meaningful use story with all the energy and passion that it will take to transform a country . . . We have a big job to do and this is just Stage 1 . . . Let's get going!

 
Disclaimer - This chart is not an official federal document and has been created for public use and convenience of seeing the "big picture" in one large "white board" created by Robin Raiford, RN-BC, CPHIMS, FHIMSS as a volunteer follow on work done as part of the HITSP Communication, Education and Outreach Committee. Any omissions or corrections, please contact Robin Raiford on Linked In.  Other useful companion posters can be located at www.hitsp.org and click the Education and Outreach tab at the top of the website.

Wednesday, July 28, 2010

Things you can do with XDS (Humor)

I was doing a Google search to locate more implementations of the IHE XDS family of profile to update the map.  Of course, IHE is not the only organization to use the XDS acronym.  Here are some of the more amusing things that you can do with XDS that I found:

Synchronizing your time of day clock
Transmitting Time of Day Using XDS Packets [PDF]
Listen to music
The NHT XDs speakers are very nicely finished...
Watch TV
...switch programs on the XDS Pro-4 using Serial Commands... [PDF]
Predict demise of roads
X-DRAIN AND XDS: A SIMPLIFIED ROAD EROSION PREDICTION METHOD [PDF]
Play Golf
Acer XDS Cabriolet Iron Set
Control Broadcast Devices
... (XDS), offers a sophisticated architecture for high-level, real-time control of broadcast devices ...
And if we are going to have this much fun, of course Disney has to get involved...
Disney Xds Sportstacular

      Keith

Final Meaningful Use Rules Published

The final rules have been published in the Federal Register (Thanks to Robin again for these links).
Robin's bookmarked versions will be posted as soon as I get them. 

If you are looking for my commentary on these rules, my thoughts on the Incentive Rule and my Summary of the standards and certification rule are also readily accessible.
NOTE: The commentary about support for SNOMED CT for procedures in the Standards Rule STILL doesn't match the regulatory text as I mentioned earlier.  Remember that it is the regulation that counts, not the explanatory text.

Tuesday, July 27, 2010

And the next Ad Hoc Motorcycle Guy Harley Award goes to...

About the award
The rules of who gets the Ad Hoc Motorcycle Guy Harley award are completely arbitrary. There is no nominating committee, although nominees are always welcome. The bar to recognition is fairly high if the first and now second recipients are any evidence.  I hope to maintain the quality of recipients in subsequent awards. I wont' award more than one a year for the same type of industry service, and I expect to award no more than five a year.

 
This next awardee must have been either a school teacher or a librarian in a former life.  She wades tirelessly through mounds of paper making sense of it in amazing infographics.  She's plowed through at least the equivalent of a carton of paper making sense of specifications from numerous SDOs, most recently turning her attention to the Meaningful Use Regulation.

 
This certifies that
Robin Raiford of Eclipsys

 

 
Has hereby been recognized for outstanding contributions to the forwarding of Healthcare Standardization

 
Robin, congratulations and thank you for all your many years of service making it easier to understand mounds of paper.  You should also get an award for paper conservation, but that's not my arena.  My thanks also goes to Robin's employer, Eclipsys, who kindly makes her time available to do this work.

 


 
Why is Robin getting this award? If you've seen any of her bookmarked copies of the MU rules, or any of the previously released  HITSP cross-reference matrices, you'll get it.  Here are some links to her latest work posted by John Halamka and also distributed to the EHRA today.
As Robin said about these in her last e-mail:
Please feel free to distribute widely on every blog, list, web whatever to get this info out there so we are all not doing the same thing – getting to the bottom of what we need in “the system shall” statements. I also redid the 2 page MU quick facts with a watermark “for informational purposes only”. Post away so some consultant does not get rich doing this.
BTW:  Given that my first post on the MU standards is still gettting about 40 hits a day even a two weeks later, I'm posting a link to this page there.

January 16, 2011
She's at it again. Here are the bookmarked final rules from 2010 and January 2011 which are available in Google Docs for viewing or download

Moving from C32 Version 2.3 to 2.5

Updated 12/15/2010 to provide an example for uncoded, and added examples for value elements. 
Just for fun, I'm going to pretend that you have ignored my recommendation to use HITSP C32 Version 2.5, and are using an older version, like C32 Version 2.3. Maybe you had 2.3 already implemented, and were waiting to see what happened to meaningful use before you piled on more work. So, now you want to know what you need to do to make the switch?

Moving to V2.4

Fortunately, it's not really all that difficult. Between version 2.3 and version 2.4, the big change was the introduction of C83 (CDA Content Modules) and the harmonization of HITSP Section and Entry templates across HITSP Components. Some HITSP specifications (like C28, C38 and C48) used IHE Profiles, others (like C84) used Health Story/HL7 Implementation Guides, and others (like C32), just used straight CCD. Making the shift between Version 2.3 and 2.4 was basically a matter of replacing the ...88.11.32.xx template identifiers with the ...88.11.83.yy template identifiers (where xx == yy in almost all cases), and adding a few IHE template identifiers. Here are the major changes you need to make:

In the CDA Document

Where you had:
‹ClinicalDocument ...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.1 '/›
   ‹templateId root='2.16.840.1.113883.10.20.1 '/›
You would add the following:
‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.6'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.2'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.1'/›
   ‹templateId root='2.16.840.1.113883.10.20.3'/›

In the CDA Header

Where you had...
‹languageCommunication›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.2'/›
Add...
‹templateId root='2.16.840.1.113883.3.88.11.83.2'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.1'/›

Note: You could remove the template 2.16.840.1.113883.3.88.11.32.2, but need not, and this pattern follows throughout for the 88.11.32.xx templates.

Where you had...
‹participant...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.3'/›
Add...
‹templateId root='2.16.840.1.113883.3.88.11.83.3'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.4'/›
Where you had...
‹performer...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.4'/›
Add...
‹templateId root='2.16.840.1.113883.3.88.11.83.4'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.3'/›

In Sections

For each of the sections below, add the specified templates to either the section or the entry
Section NameIn this CCD SectionAdd these Section TemplatesIn this C32/CCD EntryAdd these Entry Templates
Insurance
Providers
2.16.840.1.113883.10.20.1.92.16.840.1.113883.3.88.11.83.101.1
1.3.6.1.4.1.19376.1.5.3.1.1.5.3.7
2.16.840.1.113883.3.88.11.32.5
2.16.840.1.113883.10.20.1.20
2.16.840.1.113883.3.88.11.83.5.1
1.3.6.1.4.1.19376.1.5.3.1.4.17
Allergies2.16.840.1.113883.10.20.1.22.16.840.1.113883.3.88.11.83.102
1.3.6.1.4.1.19376.1.5.3.1.3.13
2.16.840.1.113883.3.88.11.32.6
2.16.840.1.113883.10.20.1.27
2.16.840.1.113883.3.88.11.83.6
1.3.6.1.4.1.19376.1.5.3.1.4.5.3
Problems2.16.840.1.113883.10.20.1.112.16.840.1.113883.3.88.11.83.103
1.3.6.1.4.1.19376.1.5.3.1.3.6
2.16.840.1.113883.3.88.11.32.7
2.16.840.1.113883.10.20.1.27
2.16.840.1.113883.3.88.11.83.7
1.3.6.1.4.1.19376.1.5.3.1.4.5.2
Medications2.16.840.1.113883.10.20.1.82.16.840.1.113883.3.88.11.83.112
1.3.6.1.4.1.19376.1.5.3.1.3.19
2.16.840.1.113883.3.88.11.32.8
2.16.840.1.113883.10.20.1.24
2.16.840.1.113883.3.88.11.83.8
1.3.6.1.4.1.19376.1.5.3.1.4.7
Product2.16.840.1.113883.10.20.1.532.16.840.1.113883.3.88.11.83.8.2
1.3.6.1.4.1.19376.1.5.3.1.4.7.2
Advance
Directives
2.16.840.1.113883.10.20.1.12.16.840.1.113883.3.88.11.83.116
1.3.6.1.4.1.19376.1.5.3.1.3.35
2.16.840.1.113883.3.88.11.32.13
2.16.840.1.113883.10.20.1.17
2.16.840.1.113883.3.88.11.83.12
1.3.6.1.4.1.19376.1.5.3.1.4.13.7
Immunization2.16.840.1.113883.10.20.1.62.16.840.1.113883.3.88.11.83.117
1.3.6.1.4.1.19376.1.5.3.1.3.23
2.16.840.1.113883.3.88.11.32.14
2.16.840.1.113883.10.20.1.24
2.16.840.1.113883.3.88.11.83.13
1.3.6.1.4.1.19376.1.5.3.1.4.12
Vital Signs2.16.840.1.113883.10.20.1.162.16.840.1.113883.3.88.11.83.119
1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2
2.16.840.1.113883.3.88.11.32.15
2.16.840.1.113883.10.20.1.31
2.16.840.1.113883.3.88.11.83.14
1.3.6.1.4.1.19376.1.5.3.1.4.13.1
Result2.16.840.1.113883.10.20.1.142.16.840.1.113883.3.88.11.83.122
1.3.6.1.4.1.19376.1.5.3.1.3.28
2.16.840.1.113883.3.88.11.32.16
2.16.840.1.113883.10.20.1.31
2.16.840.1.113883.3.88.11.83.15.1
1.3.6.1.4.1.19376.1.5.3.1.4.13
Procedures2.16.840.1.113883.10.20.1.122.16.840.1.113883.3.88.11.83.108
1.3.6.1.4.1.19376.1.5.3.1.3.12
2.16.840.1.113883.10.20.1.292.16.840.1.113883.3.88.11.83.17
1.3.6.1.4.1.19376.1.5.3.1.4.19
Encounters2.16.840.1.113883.10.20.1.32.16.840.1.113883.3.88.11.83.127
1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3
2.16.840.1.113883.3.88.11.32.17
2.16.840.1.113883.10.20.1.21
2.16.840.1.113883.3.88.11.83.16
1.3.6.1.4.1.19376.1.5.3.1.4.14
Comment2.16.840.1.113883.3.88.11.32.12
2.16.840.1.113883.10.20.1.40
2.16.840.1.113883.3.88.11.83.11
1.3.6.1.4.1.19376.1.5.3.1.4.2


Moving to V2.5

The major change affecting C32 going from version 2.4 to 2.5 were modifications supporting the meaningful use code sets. If you had already supported the HITSP code sets use in C32 Version 2.3, this didn't really effect you as a producer. As a consumer of C32 Version 2.5, there was a significant change related to coded content. For many of the C32 entries, there was one and only one allowed code system, and if you included the ‹code› element, you used the required code system. In Version 2.5 the requirements were clarified. There are two ways to use ‹code› or the CD data type in ‹value›

  1. Coded data using required vocabularies.
    In this case, the code and codeSystem attributes are required on ‹code› and contain the codes in the required code set. So, for problems, if you used SNOMED-CT, you'd do something like the following:
    ‹code code='57054005' codeSystem='2.16.840.1.113883.6.96'/›
    ‹value xsi:type='CD' code='57054005' codeSystem='2.16.840.1.113883.6.96'/›
  2. Coded using other than required vocabularies
    In this case, the nullFlavor attribute is required. If coded using other than the required vocabulary, the alternate code goes in ‹translation›, and the code and codeSystem attributes of the ‹translation› identify the code using an alternative coding scheme.  And if you used ICD-9-CM for problems, you'd do something like the following:
    ‹code nullFlavor='UNK'›
      ‹translation code='410.9' codeSystem='2.16.840.1.113883.6.103'/›
    ‹/code›
    ‹value xsi:type='CD' nullFlavor='UNK'›
    ‹translation code='410.9' codeSystem='2.16.840.1.113883.6.103'/›
    ‹/value› 
  3. Not coded at all again requires nullFlavor:
    ‹code nullFlavor='UNK'/›
    ‹value xsi:type='CD' nullFlavor='UNK'/›
Which brings us to the final table of this post, which tells you what OIDS to use and where to put the codes you are using:

Coded ItemVocabularyOIDCode/Translation
ProblemsSNOMED CT2.16.840.1.113883.6.96C
ICD-9-CM2.16.840.1.113883.6.103T
MedicationsRxNORM2.16.840.1.113883.6.88C
NDC2.16.840.1.113883.6.69T
MDDB (Medispan)2.16.840.1.113883.6.162T
MMSL (Multum)2.16.840.1.113883.6.175T
NDDF (First DataBank)2.16.840.1.113883.6.208T
MMX (MicroMedex)2.16.840.1.113883.6.176T
MSH (MeSH)2.16.840.1.113883.6.177T
NDFRT (VHA National Drug File)2.16.840.1.113883.6.209T
SNOMED CT2.16.840.1.113883.6.96T
Lab TestsLOINC2.16.840.1.113883.6.1C
ProceduresCPT-4*2.16.840.1.113883.6.12C**
ICD-9-CM2.16.840.1.113883.6.104***C**

Notes:
*HCPCS is made up of CPT-4 and several other vocabularies. This is just the OID for CPT-4, I'm still digging into the remainder.
**C32 Version 2.5 does not have a preferred vocabulary for procedures, so any code system can be used in the code element
***ICD-9-CM Procedures uses a different OID than ICD-9-CM Diagnoses, this is NOT a mistake

Warning: These aren't necessarily all of the changes that you will need to make to your application, but it does cover the largest ones.

Monday, July 26, 2010

The Impertinence of Automation on CCR and CCD Generation

One of the key statements of the CCR and CCD specifications is found in the very first sentence of the CCR standard (emphasis is mine):
1. Scope
1.1 The Continuity of Care Record (CCR) is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient’s healthcare, covering one or more healthcare encounters.  It provides a means for one healthcare practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of car
This statement answers the oft-asked question:  In a CCD/CCR, which observations, medications, et cetera, should be sent?  The answer is "the most relevant" or "pertient" ones.  The notion of relevance, and the need for it in the standard is best shown in John Halamka's post on Standards for Personal Health Records.  What providers don't want is a pile of "electronic paper" to wade through.  The terms relevant and pertinent were terms that were chosen with great care and deliberation by the members of the ASTM Heatlhcare Informatics committee for that very reason.

I get asked the question about what to send quite a bit in the HL7 class on the Continuity of Care Document (which I'll be teaching again in Cambridge, MA in October at the HL7 Working Group meeting), and in other venues.  The answer I give is always the same.  Relevance is a clinical decision that right now needs to be made by a trained care provider, and is based on context.  What is relevant to one care provider is not necessarily relevant to another.  For example, while your dentist may want to know that you've experienced a heart attack, details such as which side of the heart, or the exact ejection fraction ratio, may not be as relevant to them as they would be to your cardiologist or GP.

The question of relevance depends not only on who you are communicating with, but also what is known at the time of communication.  An observation that may not be relevant today could be of importance later once new medical knowledge is discovered.  Obviously, you can only determine relevance based on what you know right now.  Trying to cover ones anterior anatomy by transmitting data that "might be relevant in the future, but isn't known to be relevant now" is just another way of trying to avoid making a clinical decision.

A lot of people are struggling with how to determine relevance without the immediate judgment of a care provider.  They want to know what the definition of relevance is.  There are no simple answers here.  This is a clinical decision support problem, and while there are many different guidelines, there are no hard and fast rules.  Even a rule such as "Send the first, send the worst, and send the last" migh err in sending either too much, or too little.  The worst blood pressure reading for a patient might be during surgery, when it expectedly dropped as a result of the procedure.  Is that the "right" blood pressure result to send? Probably not.  Which is worse?  A white blood cell count that is very high or very low?  It depends, and it may well be that what you want is the trend over the last week because the patient is recuperating from an infection after chemotherapy.  Again, context is important, and I suspect that any attempt to set a rule of thumb will fail.

What I suggest developers pay attention to is the user interface that providers need to select the most relevant clinical observations to send.  Once you have some experience with that, and with what providers actually do with it, you can start thinking about how to provide more clinical decision support for providers.

Another question I get asked quite a bit is when to send a CCD/CCR, and is usually in the context of long inpatient stays.  My answer for that is fairly simple, at transfers of care.  I've also been asked whether a transfer from emergency to inpatient counts as a transfer of care.  This is also pretty simple, in the US it is a policy question, and the relevant policy makers say yes.

   Keith

P.S.  IANAL, but I strongly suggest that algorithms determining the most relevant data to show a healthcare provider are properly in the domain of FDA regulated medical devices.

Friday, July 23, 2010

Registration Opens for IHE Interoperability Showcase at HIMSS and NA 2011 Connectathon


IHE Community,



New Registration Announcement for HIMSS11 Interoperability Showcase & IHE 2011 N.A. Connectathon:



HIMSS11 Interoperability Showcase & IHE N.A. Connectathon registration is open from August 16, 2010 to October 8, 2010
New extended date! Please read below for more details on how new participants can prepare for the opening of registration, plus the sign-up for the final HIMSS11 Showcase & IHE N.A. Connectathon Registration Kick-off Webinar(s).

New Participant Overview & Education:
New participants are encouraged to listen to the recording and/or slides posted online from the June 10, 2010 webinar presentation, IHE 2010 N.A. Connectathon & HIMSS11 Interoperability Showcase Registration Overview. Plus, listen to other archived presentations and slides from the IHE 2010 Educational Webinar Series on-line here.
           
IHE 2010 N.A. Connectathon & HIMSS Interoperability Showcase Registration Overview webinar highlights:
  • Learn how to prepare for Showcase & Connectathon registration opening August 16, 2010
  • Learn about the key components of the HIMSS Interoperability Showcases & IHE Connectathon
  • Discover the new features & scenarios planned for demonstration at HIMSS11
  • NOTE: This recorded presentation will NOT cover the final registration process, pricing and participation levels for the HIMSS11 Interoperability Showcase and IHE 2011 N.A. Connectathon.
HIMSS11 Showcase & IHE 2010 N.A. Connectathon Registration Kick-Off Webinar for ALL Participants:
Final Registration details will be announced on August 12, 2010 in a joint session that will cover both the HIMSS11 Interoperability Showcase & IHE 2011 N.A. Connectathon. We will also repeat this session again on August 17 & 31, 2010 for those interested parties that are unable to attend the August 12 session. Please register in advance by using the links below.


2011 Event Dates:
IHE 2011 N.A. Connectathon: January 17 -21, 2011 at the Hyatt Regency in Chicago, IL.
HIMSS11 Interoperability Showcase: February 21 – 24, 2011 at the HIMSS11 Annual Conference & Expo in Orlando, FL.
HIMSS11 Annual Conference & Exposition: February 20 – 25, 2011
Registration Kick-Off Webinar Dates & Registration Links:
Thursday, August 12, 2010 at 10:30am – 12:00pm CT - Register Online 
Tuesday, August 17, 2010 at 9:30am – 11:00am CT – Register Online
Tuesday, August 31, 2010 at 9:30 – 11:00 am CT – Register Online
Want to Learn More?
For more information, please visit our website or contact us directly at secretary@ihe.net.
Integrating the Healthcare Enterprise- Visit http://www.ihe.net/.

Thursday, July 22, 2010

Another Oops in MU Rule Text?

It's a good thing the ink is still drying on the final rule text for meaningful use.  Robin Raiford is an extremetly detail oriented person who also does some of the best chartography making send of meaningful use, standards, and all the rest that I know.  Robin reports in a widely distributed e-mail that:
While gathering data for the poster and validating the dots were all correct – I have found 7 errors in Table 3 of the CMS final rule in the table layout.


If you read the text close, they kind of jump right out at you. In table 3 there are 7 items that have “unique patient” in the description of the measure and they are grouped in that portion of the table under “Measures with a Denominator of Unique Patients Regardless of Whether the Patient’s Records Are Maintained Using Certified EHR Technology”, rather than with the “unique patients” denominator items . My dots in the poster were not lining up exactly – and I discovered I had placed them using the text – not the table. So that is how I found it.
I have passed this on to the Co-chairs of HIT Policy and HIT Standards and John Halamka has passed on to Tony Trenkle at CMS for comment. So either there are two meanings for “unique” or something is in the wrong place in Table 3. So stay tuned how CMS resolves or makes it know their intent. Since one has Denominator of UNIQUE PATIENTS Regardless of Whether the Patient’s Records Are Maintained Using Certified EHR Technology and the other Measures with a Denominator of Based on Counting ACTIONS for Patients whose Records are Maintained Using Certified EHR Technology Stage 1 Objectives – this has HUGE implications for the ED and those 11 measure that include POS 23 and POS 21.
As I learn more, I'll post it here.  Thanks Robin, and keep up the goodGREAT work!

     Keith

Where is the XSD for CCD?

This is a question that shows up in various places quite a bit. People who are familiar with mainstream XML development want a schema to support conformance to all of the constraints of an XML implementation.

The CCD is a specialization of the CDA specification, for which you can find schemas. These schemas are available from HL7. If you are already an HL7 member, you can get them for free.  If not already a member, you can purchase them from the HL7 store (The CDA standard and CCD implementation guide will set you back $50.00 each).

Why isn't there a schema jsut for CCD?  The W3C Schema standard just isn't able to solve this particular problem.  To make a long story short, XML descends from SGML.  One of the requirements in SGML for DTDs which made its way into XML and subsequently the XML Schema specification was implementation simplicity in parsing tags.  This means that schemas are not permitted to use any look-ahead to determine the type of an element.  They can only look at the element name.  The problem comes into play when you need to distinguish between for example, a problem, and a result.  Both of these use the observation element of the CDA, with differing requirements on what appears inside.  But, the element has the same name, and so cannot have different requirements according to the W3C schema specification.  Another example that W3C schema doesn't support very well are co-occurence constraints.  These are constraints that say if A is X, then B must be Y.  These kinds of contraints are very difficult to model in W3C schema (yeah, I know, it can be done using certain features, but those are the very same features that often break, or aren't supported in schema driven persistence models).

In the contest between the information modeling perspective which says that these two things carry many of the same semantics, and the business viewpoint which says that there are different rules that apply, something has to give.  The HL7 XML ITS says that the information model, which ensures semantic interoperability, is paramount, not the business viewpoint which imposes these different constraints.  After all, semantic interoperability has been the Holy Grail that we've all been persuing, right?

All is not lost (especially if you code in Java).  The Model Driven Healthcare Tools project (MDHT) from Open Health Tools has a great deal of support for CDA, the CCD, IHE XPHR and the HITSP C32 specifications.  Those of you using .Net might be a bit stuck.  I encourage you to participate in the MDHT work, because there is a definite need for EMF driven .Net code generation tools here.

XHTML for CDA Release 3

CDA Release 2 uses an HTML-like markup language to support narrative text.  The table below shows the coorespondence between the two:



CDAHTML
‹content›‹SPAN›
‹linkHTML› (attributes are identical)‹A›
LINK›
‹sub›‹SUB›
‹sup›‹SUP›
‹br›‹BR›
‹footnote›‹footnoteRef›(not available)
‹renderMultimedia›‹IMG›
‹paragraph›‹P›
‹list listType="ordered"›‹OL›
‹list listType="unordered"›‹UL›
styleCode="className"class="className"
ID="value"ID="value"



For CDA Release 3 there's been a formal proposal to use XHTML to support the narrative text. I'm very much in support of this for several reasons. You can take a class on XHTML, buy a book on it, and hire engineers with experience in this markup language. From a technical perspective, this also eliminates the need for a "default" stylesheet, since the XHTML is already there.

There are a couple of places where I suspect we will want to "Profile" XHTML to limit some of the capabilities.  The W3C developed Modular XHTML for this sort of purpose.

What are the challenges and their implications?  The biggest issue has to deal with where and how the document structure is stored. 

The structure of the CDA Document today is as a list of sections representing using a RIM class called an Organizer.  These sections can possibly contain recursive subsections.  All of these are intermingled into the RIM structure of the CDA.  Using XHTML would likely separate the organization of the text from the structured entries describing it.  The current document structure organizes content in a certain way, and that organization carries semantic meaning (not all aspects of presentation are fluff!).  This change would require some thought to determine whether: 
  1. The XHTML structure is used to organize the content, with sections attached to XHTML organizing elements such as ‹div›.
  2. A parallel organization structure is incorporated into the structured entries.
There are strengths and weaknesses to either of these.  The biggest weakness of using the XHTML representation for organizational structure of the content is the loss of the organization structure in the RIM classes.  One reason this is an issue is because of something called context conduction.  Context conduction allows certain pieces of context (i.e., the subject, author or performer of an act in a clinical statement) to be conveyed from larger structural components.  Loss of the organization structure in the structured entries would make it more difficult for systems to determine who was the author, subject or performer associated with a given act using fairly simple programatic constructs.

Duplicating the organizational structure in the structured entries has other problems.  Any time you duplicate information in two different places, you have an associated risk that the duplication process was not carried out correctly.  The question then becomes how to determine which structure is correct.

Fortunately, I think there is a solution to both of these problems.  The organizational structural of the document is implicitly represented by block elements in the content.  That structure can be made explicit through an algorithmic transform of the content.  Specifying the algorithm by which the structure is duplicated enables use of that structure to convey context information.  The remaining question is whether it would be better to convey the structured entries in the CDA Release 3 document using that algorithmically developed structure (which could require a validation step), or letting the application use the algorithm when it needed to make inferences about context.

I think at this point, I'm in favor of duplicating the organizational structure in the entries, but could be readily convinced that it isn't necessary.  An advantage to not carrying the implicit structure is that you can have other parallel structures in the structured entries.  This gives you another "view" of the data that is separated from the presentation view.  An example of where this could be valuable is in developing treatment plans.  A component of a treatment plan is the particular condition or conditions which it treats.  That could be the context for that portion of the treatment plan, which could simplify the transmission of the treatment plan content.

An additional benefit of using XHTML to convey document structure is that it allows lists and tables to also be used to convey structure.  Tables and lists are organizers of information even more so than document sections.  Why should they not be treated in the same fashion in CDA?

I expect the discussion and development of this formal proposal will take quite a bit of time over the coming months.  It will certainly result in some challenging problems that need to be solved if we are to move forward in this direction.  I look forward to those challenges.

Wednesday, July 21, 2010

Time to Start Thinking about IHE Profile Proposals

The IHE annual cycle includes a time of year where proposals for new profiles are accepted.  Four domains in IHE have a nearly synchronized calendar for profile proposals: IT Infrastructure; Patient Care Coordination; Quality, Research and Public Health; and Patient Care Devices. 

Proposals are accepted in August/September, reviewed in October/November, and approved to move forward in November/December.

I'm expecting an official call for proposals some time in the next few weeks, which will have more details about how to submit your proposals.  Meanwhile, be thinking about
  • what problems you need solved,
  • which domain in IHE might be able to hep you solve it,
  • how the situation might look if the problem no longer existed.

XSLT Tricks for CDA

There's a reason why HL7, IHE and HITSP profiles/implementation guides on CDA recommend or even require the Act.text and code.orginalText to be present in entries, and to point to the narrative text rather than duplicate it.  The key reason for having these present at all is to allow information systems to have access to the text values used in the exchange.  This supports exchange of the free text strings when two systems do not use the same coding systems (e.g., as for exchange of medication information under meaningful use).  The main reason for pointing to the content instead of duplicating it is to eliminate a potential source of error in implementation.  But another reason for pointing instead of duplicating is that it creates a link between the human readable text and the machine readable entry.  This link can be used in XSLT transformations to support features like mouseovers.

For example, suppose you had the following narrative content:

‹text›...‹content ID='problem-1'›Headache‹/content›...‹/text›

You can guess that because there is an ID attribute on the text element, something may be pointing to it.  Indeed, in this case, there is:

‹entry›
  ‹observation classCode='OBS' moodCode='EVN'›
      ...
    ‹code ...›
      ‹originalText›{reference value='#problem-1'›{/orginalText›
    ‹/code›
      ...
  ‹/observation›
‹/entry›

Now, if you wanted to generate a mouseover from this entry, it should be pretty simple.  Every element that contains an ID attribute should generate an HTML element with a title attribute that contains the text you want to show up on the mouseover.  This first template shows how you might handle the content element (note that you should do something similar for paragraph, list item and table elements, but I'll leave that as an excercise for the reader).

‹xsl:template match="cda:content"›
  ‹span›
    ‹xsl:apply-templates select="@*|*|text()"/›
  ‹/span›
‹/xsl:template›
This just wraps the content an HTML SPAN tag, and calls other templates to handle its content, including attributes, elements and text.

The next template handles the ID attribute.  When a content element contains an ID attribute, this template will be used:
‹xsl:template match="@ID"›
  ‹xsl:attribute name="ID"›
    ‹xsl:value-of select="."/›
  ‹/xsl:attribute›
  ‹xsl:variable name="theID" select="concat("#",.)"/›
  ‹xsl:apply-templates select="//cda:reference[@value=$theID]"/›
‹/xsl:template›
It copies the ID attribute to the HTML elementy generated (the SPAN tag used in the previous template), and then applies any template matching any reference element pointing to this ID.

You can see that template below.  The reference element can appear inside a code, routeCode or value element or in a text element inside the various acts (and a few others, but these are the key ones).  Having found the reference, this template finds the code element associated with it and applies a template on the code element that will generate the titel attribute.

‹xsl:template match="cda:reference"›
  ‹xsl:choose›
    ‹xsl:when test="../../self::cda:code|../../self::cda:routeCode|../../self::cda:value"›
      ‹xsl:apply-templates mode="code" select="../.."/›
‹/xsl:when›
    ‹xsl:when test="../self::cda:text"›
      ‹xsl:apply-templates mode="code" select="../../cda:code"/›
    ‹/xsl:when›
  ‹/xsl:choose›
  ‹xsl:text› ‹/xsl:text›
‹/xsl:template›
This next template finally generates the title attribute.
‹xsl:template match="cda:code|cda:value|cda:routeCode" mode="code"›
  ‹xsl:attribute name="title"›
    ‹xsl:value-of select="../../@codeSystemName"/›
    ‹xsl:if test="not(../../@codeSystemName)"›
      ‹xsl:value-of select="../../@codeSystem"/›
    ‹/xsl:if›
    ‹xsl:text›: ‹/xsl:text›
    ‹xsl:value-of select="../../@displayName"/›
    ‹xsl:text› ‹/xsl:text›
    ‹xsl:value-of select="../../@code"/›
  ‹/xsl:attribute›
‹/xsl:template›
This may appear to be a lot of work to generate a title attribute.  I could have written this quite a bit more simply, but I wanted to be able to use a similar XSLT to generate event method calls (onmouseover or onclick) that would do other sorts of cool things in the user interface for this stylesheet.

For meaningful users in the US, this is just one way that you can take advantage of the coded data present in the HITSP C32 specification.

Excercise:  Generate a CDA stylesheet that will display not just a mouse-over, but a popup window containing other data appearing in the entry.

Tuesday, July 20, 2010

HL7 Responds to Meaningful Use

Health Level Seven® International
For Immediate Release       
Contact: Andrea Ribick
+1 (734) 677-7777
andrea@HL7.org

Meaningful Use Standards Final Rule Names Five HL7 Standards and Implementation Guides
Version 2.5.1 Implementation Guide for Electronic Laboratory Reporting to Public Health Now among HL7 Publications Needed for Meaningful Use
          Ann Arbor, Michigan, USA – July 19, 2010 – Health Level Seven® International (HL7®), the global authority for interoperability and standards in healthcare information technology, today announced that five of its standards and guides will be used in the U.S. final rule on standards and certification criteria for meaningful use.
The interim final rule published in January of this year included:
  • HL7 Version 2.5.1 for the submission of lab results to public health agencies.
  • HL7 Version 2.3.1 or Version 2.5.1 for submitting information to public health agencies for surveillance or reporting (excluding adverse event reporting).
  • HL7 Version 2.3.1 or Version 2.5.1 for submitting information to immunization registries as the content exchange standard and the CDC maintained HL7 standard code CVX—Vaccines Administered as the vocabulary standard.
  • HL7 Clinical Document Architecture, Release 2 (CDA) Continuity of Care Document (CCD), a Version 3 standard based on the HL7 Reference Information Model, as one of two options for content exchange standards for the receipt of a patient summary record.
In addition, the final rule now includes the HL7 Version 2.5.1 Implementation Guide for Electronic Laboratory Reporting to Public Health when HL7 Version 2.5.1 is used for reporting lab results to public health agencies.

HL7 Members are Heard by ONC
In March, HL7 published comments on the Interim Final Rule on Standards.  As a result of feedback from HL7, its members and others in the healthcare industry, a number of changes important to HL7 members were made to that rule.

Overlaps and Inconsistencies with Previously Selected Standards Are Reduced
HL7 recommended that ONC provide clarification on overlaps and inconsistencies between standards required for use in Federal Agencies under Executive Order 13410 and standards that had been previously recognized under this order.  The final rule incorporates many more of the implementation guides that had been previously recognized by HHS as requirements, including the ANSI/HITSP C32 Version 2.5 implementation guide.  These changes greatly reduce the number of inconsistencies and overlaps between the final rule and Executive Order 13410.

Implementation Guidance Has Been Added
HL7 recommended that the Final Rule provide more implementation guidance.  The new rule incorporates implementation guidance for Immunizations using HL7 2.3.1 or HL7 2.5.1, use of the Continuity of Care Document using the HITSP C32 Version 2.5 specification, guidance for public health reporting using HL7 2.5.1 developed by the Public Health Information Network, and for laboratory to public health using the recently approved HL7 Version 2.5.1 Implementation Guide for Electronic Laboratory Reporting.

Transport Standards Inconsistencies Eliminated
HL7 recommended that the transport standards section be altered to accommodate the use of the selected HL7 standards.  The final rule does not make any recommendations for transport.

Description of CCD Improved
HL7 observed that the description of CCD in the Interim Final Rule was inaccurate.  The interim final rule described CCD as being a Level 2 implementation guide of CDA.  CCD supports both structured narrative (Level 2) and coded data (Level 3).  ONC corrected these errors.  Furthermore the selection of the HITSP C32 Version 2.5 Specification for implementation guidance means that CCD documents exchanged for meaningful use will contain coded data (Level 3).

Use of Appropriate Standards for Discharge Summaries
HL7 pointed out that Discharge Summaries require content that is not described or supported in the CCD.  ONC acknowledged that Discharge Summary documentation can be separated from the content of the CCD, but did not select an alternative standard for them.

Use EHRs for Clinical Purposes
HL7 recommended that the text in the Interim Final rule which required use of the EHR to perform eligibility and claims transactions be removed, as this is inconsistent with EHR systems as described by the HL7 EHR Functional Model.  The final rule removes the requirement for the EHR to perform claims or eligibility transactions.

“The final rule on standards for meaningful use will improve the potential for interoperable exchange between healthcare providers.  HL7 and its members are proud to have been a contributor to this historic regulation,” said HL7 CEO Charles Jaffe, MD, PhD. “The HIT Standards Committee deserves our gratitude for this significant achievement. We must continue to advance the vision of the committee if we hope to reach the goal of improving the care of our patients.”
          For more information, please visit the HL7 website at http://www.hl7.org/. HL7 International members may download copies of the standards and implementation guides for free. Nonmembers may purchase them at http://www.hl7.org/.

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; Booz Allen Hamilton; Centers for Disease Control and Prevention; Duke Translational Medicine Institute (DTMI); Eclipsys Corporation; Epic Systems Corporation; European Medicines Agency; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; Intel Corporation; InterSystems Corporation; Kaiser Permanente; Lockheed Martin; McKesson Provider Technology; Microsoft Corporation; NHS Connecting for Health; NICTIZ National Healthcare; Novartis Pharmaceuticals Corporation; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; QuadraMed Corporation; Quest Diagnostics Inc.; Siemens Healthcare; St. Jude Medical; 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, Brazil, Canada, Chile, China, Colombia, Croatia, Czech Republic, Finland, France, Germany, Greece, Hong Kong, India, Italy, Japan, Korea, The Netherlands, New Zealand, Romania, Russia, Singapore, Spain, Sweden, Switzerland, Taiwan, Turkey, United Kingdom, and Uruguay.

# # #

Robin's Eggs

Easter eggs are those little nuggets in software applications the provide a cool little extra to the user. Robin Rainford provides her little nuggets as bookmarked editions of the PDF versions of the final rules.

 
Thanks to John Halamka for making them available on the web:

Friday, July 16, 2010

How to use HITSP C32 Version 2.5 for Meaningful Use

David Tao asks an excellent question:

Keith, re C32 v2.5, it points to HITSP C83 and C80. I THINK that v2.0 of those documents (published January 2010) is appropriate to use, but the FR is not specific about that, and I know that some people assume that C83/C80 v1.1 (published July 2009) are the appropriate versions. I hope NIST will clarify this soon, but do you have a recommendation and have you had any conversations with ONC or NIST about that?



Thanks,


David


David,

I KNOW that those are the appropriate documents to use.  Those are the specifications that support meaningful use with C32.  If you tried to use the meaningful use vocabularies with earlier versions, you'd be in trouble because those versions don't support it.  The C83 Version 2.0 specification was written after the interim final rule was published and modified accordingly to support it. 

     Keith

Thursday, July 15, 2010

Race and Ethnicity in Meaningful Use

Today a question crossed my desk about the vocabulary terms to support Race and Ethnicity specified in the Meaningful Use Standards rule and in the Incentives rule.  In short, the question was, what are the code values that I need to use to specify race and ethnicity.

The rules didn't say.  Instead, they reference an OMB directive that tells you the high level concepts that your terminology has to roll up to.

If you are looking for a terminology that works, look at the CDC Race and Ethnicity vocabulary.  This is THE vocabulary that is specified in the HITSP C32 Version 2.5 specification for how to use the CCD, and is the common vocabulary that appears in many other HITSP specifications.  You can utilize a value set just supporting the short list of OMB mandated categories, or you can drill down into more details.

Some states (such as Massachusetts), have mandated a deeper level of reporting for these concepts.  The CDC vocabulary supports that level of detail and yet remains consistent with the OMB guidelines.

     Keith

BTW:  I made comments on these rules that they should be consistent with OMB guidelines.  I'm pleased to see those comments adopted in the final rules.

Virtual Medical Records, HL7 Models and Simplification

As I've previously reported, there are a number of different activities in HL7 regarding simplification.  One of these activities is around the development of a model for the virtual medical record (VMR) to use in the Domain Analisys Model.  The VMR concept has been around for more than a decade, but has yet to really be standardized.

The HL7 Clinical Decision Support workgroup is currently exploring the US Federal Health Information Model.

I have (as usual), a somewhat different view of what the VMR should be.  The VMR to me is to the medical record as the Document Object Model is to XML and HTML.  It is described by a UML model with a set of classes, interfaces and the relationships between them, and then has bindings to various programming languages and formats (Java, JavaScript, PERL, C++, PHP, XML, et cetera). 

All HL7 Version 3 models derive from the HL7 V3 Reference Information Model, Data types and vocabulary.  I don't see this changing in the VMR, but I do forsee changes to how we would develop a model for it.  As I've been exploring this area, I see some things missing from the current HL7 methodology.  The first of these is interfaces.  Interfaces represent an excellent way to capture common design capabilities.  There are two examples of "interfaces" that should be used in the VMR.  The first of these is the "Annotatable" interface.  A class that implements this interface supports the ability to add annotations to an information item (a class in the model) that has an author, data enterer, date of authorship, and free text.  This interface represents a way to access annotations described in the A_Annotation (Universal) COCT_RM590000UV CMET that is used in several places in HL7 Version 3. 

Here's a bit of pseudo-code defining Annotation and the Annotatable interface.

class Annotation extends Act {
    String readwrite Text;
    List readonly Authors;
    List readonly DataEnterer;
    Act readonly Subject;
}

interface Annotatable  {
    List readonly Annotations;
}

The Annotatable interface can be implemented by any Act.  It provides access to the list of annotations on that act.  Each annotation provides access to the text, authors, data enterer, and the act that is the subject of the annotation.

The Severity interface is similar, except that it provides access to a single Severity class that represents the severity of a concern, allergy, or reaction.

I'm using about ten sources for modeling content.  The most important is probably the clinical statement pattern.  Other important sources are the standards and draft standards in the Care Record domain, and domain specific content in the Clinical Genomics pedigree topic, Orders and Observations, Pharmacy and Medications, and Immunization.  Another important modelling sources is of course the HL7 Continutity of Care Document.  This latter document helps to define the major categories of information that I would expect to appear in the Patient class.  I think the US Federal Healthcare Information Model will help identify some of the neccessary relationships, but it's just at much to detailed a level.

Below is a list of just some of the classes that I've found thus far (and my work is nowhere near complete):

ClassRIM Class TypeSpecialization
Allergy Intollerance
Concern
ActCONC
Allergy Intollerance ListActLIST
AnnotationActOBS
AssessmentComponentActOBS
AssessmentScoreActOBS
AuthorParticipationAUT
CarePlanActPCPR
CausesParticipationCAGNT
ConsumableParticipationCSM
CustodianParticipationCST
DocumentActDOC
FullfillsActRelationshipFLFS
GoalActOBS
GuidelineActPCPR
Healthcare FacilityRoleSDLOC
InformantParticipationINF
Legal AuthenticatorParticipationLA
MedicationRoleADMM
OrganizationEntityORG
PatientRolePAT
PlaceEntityPLC
PreconditionActRelationshipPRCN
ProcedureActPROC
ReactionActOBS
ReasonActRelationshipRSON
Record TargetParticipationRCT
ReferenceRangeActRelationshipREFV
Related PartyRoleROL
Substance AdministrationActSBADM

Some of these will wind up being split (e.g., Substance Administration will eventually show up as Immunization and Medication) in the model), others will be renamed (e.g., Record Target to MedicalRecord or some such).

Once I get the list to a point where I think it is complete, I'll begin developing a set of UML diagrams.  There'll be some interesting effects as I go through this work.  The use of packages and interfaces is not something that's not often been done in the HL7 Version 3 models.  Using the W3C DOM as a model has gotten me thinking about what I know (UML modeling) and the V3 RIM, and applying it.  I've gone from someone who has an outsider's view of HL7 to having a detailed insider's view, and gotten lost in the woods in the process (as I suspect many of us in HL7 have).  Using another standard that I know well like the DOM has given me a new map to work with.

There are quite a number of techniques that the DOM uses in its models that could vastly simplify HL7 Version 3.  The idea that there could be a standard way to interact with the medical record that is consistent across not just serialization, but also dealing with dynamic behaviors is getting to be pretty interesting.  I'm already imagining that there will be a base class that supports XML and Text representations, and other features that support declarations of conformance (templates) and validations, and ...

Packaging will make it easier to separate and scope these different concerns (e.g., conformance and validation).  Having identified the appropriate package for a class or interface will enable use to determine whether different parts of the VMR are in or out of scope for a particular project.

Wednesday, July 14, 2010

Summary of Meaningful Use Incentives Changes

I finished my review of the Meaningful Use Incentives rule. My review was focused specifically on how the measures in that rule are tied to the standards rule (which I reviewed yesterday here), and so I only had to read about 250 of the 864 pages. I specifically did not cover quality measures, or many of the administrative details.  I also do not go into detail on the percentage measure revisions, or into the quality measures.  If you are looking for other details such as these, I recommend that you read the article in the New England Journal of Medicine, John Halamka's summary, Inga (HISTalk's) summary, or many of the other summaries available on the web.
Note that page numbers in the text below are from the PDF on display and will not correspond to the page numbers when these are finally published in the Federal Register:
  • Definitions of Certified EHR Technology and Qualified Electronic Health Record in this rule are the same as, and therefore reference the definitions of those terms in the Standards Rule (see Page 22).
  • You can stop being a meaningful user in the middle, and resume where you left off (see page 24 through 26), up until 2015. After that, all bets are off.
  • Your first reporting period is 90 days long in your first reporting year (page 28), and you start at the Stage 1 criteria for two years, then move to Stage 2 criteria (page 39). After 2014, it isn’t indicated what will be done about getting everyone to the same level of meaningful use, but that is the stated goal.
  • States are not allowed to request more stringent criteria than what can be certified in Stage 1. If you are a vender of an EHR product, you should consider certifying for optional criteria, because states would be allowed to require it for Medicaid users (page 50). Even so, if a hospital is eligible under Medicare, then it is deemed to be Medicaid eligible, even if its EHR technology does not support additional state requirements (also page 50).
  • The rule takes the approach that there are core measures which must be implemented by all, some core measures which must be implemented by all EPs, others which must be implemented by all Hospitals, and then a menu of other requirements of which some number are required to be implemented. Therefore, the incentives are no longer a set of all-or-nothing requirements. From an EHR product perspective, products will probably need to support more of the “menu” requirements because different users of those products will want to select different requirements from the “menu”.
  • Some requirements may not be applicable to a provider. Failure to meet these requirements will not go against the providers eligibility for incentive payments. However, note that the Incentives rule indicates which requirements are permitted to be treated this way (page 61 to 62).
  • The incentive eligibility has been linked to the standards rule in many places. The phrase “We further specify that in order to meet this objective and measure, [EP/Hospital/CAH] must use the capabilities Certified EHR Technology includes as specified and standards at 45 CFR 170.3XX(x).” Basically, this phrase says that to be eligible, you must use the Certified EHR Technology to meet the objective and not some other technology, and that you must do so in the way specified by the standards identified in the certification criteria.
  • Because eligibility and claims are no longer certification criteria in the Standards Final Rule, they are also no longer required to be used to obtain incentive payments.
  • The NPRM required tracking of “Insurance Type”. However, given that there are no established standards to identify types of insurance, the requirement to track this information for patients was removed from the Incentives rule.
  • The NPRM required tracking of Race and Ethnicity. The final incentives rule clarifies that this tracking should be consistent with OMB guidance for gathering information about race and ethnicity. See yesterday’s post in the Standards rule for a link to those guidelines.
  • Hospitals must capture whether or not an advance directive is available for patients over 65. This is a new requirement for the Incentives rule.
  • The use of Clinical Decision Support in the NPRM required implementation of 5 rules. This was reduced to 1 rule so that implementations could focus on good implementation of clinical decision support. The description of clinical decision support has been modified to avoid bad examples.
  • In cases where providers are required to either give patients data, or make it accessible online, the time frames have been altered. Instead of 2 or 4 days, they have been changed to business days (Monday through Friday excluding Federal and State holidays), and in one case, increased from 2 to 3 days (See page 161 and 175). In addition, it was indicated that it is not appropriate to charge patients for clinical summary provided for an office visit (Page 179) since that would be enabled by the Certified EHR Technology and should be of minimal expense to the provider (Hit the print button…)
  • Some measures included a required test (e.g., for reporting information to public health for surveillance, immunizations or lab results; or electronic exchange of data with other providers). For these measures, the test need not include actual patient data, but could use test data. Also, the test need not be “successful”. On this, my advice would be to show appropriate due diligence in your attempts to ensure that the test passes.
Finally, my last comment is simply to reiterate in my own words what I found on page 219.
Meaningful Use will not be cancelled. It is law. The regulation implements what is already required under law. For this, I’m not sorry!
Having plowed through the regulations in two days, I have to say that the final results are much improved over the original regulation text delivered earlier this year. I am pleased with the final results, and proud to have been a participant in this regulatory process. The rules are not perfect, but they are certainly good enough to provide for dramatic improvements in healthcare.


Tuesday, July 13, 2010

Procedure Codes in Standard Final Rule

The Meainingful Use Standards rule went on display today.  In reviewing the rule this morning, I found a small but significant error.

I found what I believe is an error in one of the responses on page 169 of the public display copy to comments on rule text. The document states:

Response. We understand that most current EHR technology already includes the
CPT-4 code-sets, and we believe that this indicates that the licensing costs are not
prohibitive. Regardless, we have adopted an alternative standard to CPT-4, SNOMEDCT
®, which is freely available.

However, my review of the standards selected under that section indicate that SNOMED-CT should be replaced with ICD-9-CM, as indicated by the following:

From the text on display:
Final Rule Text:
§170.306(d)
(1) Enable a user to create an electronic copy of a patient’s
clinical information, including, at a minimum, diagnostic test
results, problem list, medication list, medication allergy list,
and procedures:
(i) In human readable format; and
(ii) On electronic media or through some other electronic
means in accordance with:
(A) The standard (and applicable implementation
specifications) specified in §170.205(a)(1) or §170.205(a)(2);
and
(B) For the following data elements the applicable standard
must be used:
(1) Problems. The standard specified in §170.207(a)(1) or, at a
minimum, the version of the standard specified in
§170.207(a)(2);
(2) Procedures. The standard specified in §170.207(b)(1) or
§170.207(b)(2);
(3) Laboratory test results. At a minimum, the version of the
standard specified in §170.207(c); and
(4) Medications. The standard specified in §170.207(d).
(2) Enable a user to create an electronic copy of a patient’s
discharge summary in human readable format and on
electronic media or through some other electronic means.


§170.207 Vocabulary standards for representing electronic health information.

(b) Procedures. (1) Standard. The code set specified at 45 CFR 162.1002(a)(2).
(2) Standard. The code set specified at 45 CFR 162.1002(a)(5).

And from 45 CFR 162.1002 found at http://cfr.vlex.com/vid/162-1002-medical-data-code-sets-19931702
162.1002 - Medical data code sets.

...
(2) International Classification of Diseases, 9th Edition, Clinical Modification, Volume 3 Procedures (including The Official ICD9CM Guidelines for Coding and Reporting), as maintained and distributed by HHS, for the following procedures or other actions taken for diseases, injuries, and impairments on hospital inpatients reported by hospitals:
(i) Prevention.
(ii) Diagnosis.
(iii) Treatment.
(iv) Management.

...
(5) The combination of Health Care Financing Administration Common Procedure Coding System (HCPCS), as maintained and distributed by HHS, and Current Procedural Terminology, Fourth Edition (CPT4), as maintained and distributed by the American Medical Association, for physician services and other health care services. These services include, but are not limited to, the following:
(i) Physician services.
(ii) Physical and occupational therapy services.
(iii) Radiologic procedures.
(iv) Clinical laboratory tests.
(v) Other medical diagnostic procedures.
(vi) Hearing and vision services.
(vii) Transportation services including ambulance.

Meaningful Use Standards Summary


Click the link for information on Stage 2.

Rarely do I add something to a post after the fact that isn't a correction, but then few posts ever get this much attention so many days later. If you are interested in this post, there are more some more goodies you may want to look at.  I especially recommend the first.

This morning, HHS published the final rule for Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology for public display (see http://www.ofr.gov/OFRUpload/OFRData/2010-17210_PI.pdf).
This is my initial summary of the changes in the rule. John Halamka also published An analysis of the Final Standards Rule (see http://geekdoctor.blogspot.com/2010/07/analysis-of-final-standards-rule.html)
  1. While both CCD and CCR are retained as the standards for patient summaries, HHS requires the use of the HITSP C32 Version 2.5 (the version updated for the IFR) when CCD is used. This made my day, as the work I have been doing for the last 5 years is now incorporated into the final regulation text.
  2. Transport standards (SOAP and REST) have been removed from the Standards Final Rule.
  3. The requirement to use Electronic claims and eligibility transactions has been removed from the final rule, but is expected for 2013.
  4. For immunizations, the final rule now requires the CDC Implementation Guide for HL7 Version 2.3.1, or the new 1.0 guide using HL7 Version 2.5.1.
  5. For public health reporting the HL7 2.5.1 Public Health Information Network implementation guide is required to be used when HL7 2.5.1 is used (2.3.1 is also permitted and does not have a guide [thanks to Hans Buitendijk of Siemens for this catch])
  6. Standards for cross-enterprise user authentication have been removed.
  7. Rather than specifying AES for encryption, the final rule now references approved security functions found in Annex-A of FIPS 140-2. This allows most existing VPN connections and operating system encryption capabilities to continue to be used to meet the certification requirements.
  8. Accounting for disclosures is now an “optional” critieria.
  9. CPOE is no longer required for referrals, only meds, labs, and imaging/diagnostic tests.
  10. Both NCPDP SCRIPT 8.1 and 10.6 are allowed (10.6 was recently allowed under Medicare Part D rules).
  11. OMB guidelines must be followed when reporting race and ethnicity.  These guidelines do not specify code values, only the specific concepts that the codes must be able to roll up to.  The CDC Race and Ethnicity Code set is one such code set that supports this.
  12. Discharge summary requirement retained, but their inclusion in CCD/CCR not required. ONC recognized that they are not supported by the selected standards.
  13. HHS states that SNOMED-CT is allowed to report procedures.  However, this is apparently an error (see the next post), since ICD-9-CM is the alternative for procedures found in the regulation in that section.
  14. The HL7 Version 2.5.1 Electronic Laboratory Reporting implementation guide (the link only works if you are an HL7 member and logged in) is required for submission of laboratory results to public health.  This guide is available for purchase from HL7 for $50 according to Rita Altamore, and HL7 is updating their site to make it more accessible.
  15. A certified Hospital EHR must be able to record the availability of an Advance Directive.
HHS estimates the one-time costs for EHR developers to certify products will range from $750,000 to $4,800,000 depending upon whether the EHR has previously been certified or not. But also, they note that they believe the rule will not create a significant hardship on small business entities that produce EHR systems.

Thanks to Hans J. Buitendijk and David Tao of Siemens, Rob Savage (Northrup Grummund/CDC), Austin Kreisler (SAIC/CDC), Rita Altamore (Washington Deptartment of Health), and Nikolay Lipskiy (CDC) for the links to the various guides and other updates.


ONC EHR Criteria - Stage 1 Final July 2010
Don Sepulvada, Sr. Marketing Manager of GE Healthcare for our Centricity® EMR product line pulled together the following table from the standards rule. This table now includes all certification criteria and requirements for Ambulatory AND Hospital EHR products.  (Nice work Don!)

RuleMeaningful Use Stage 1 ObjectiveMeaningful Use Stage 1 MeasureInterim Final Certification CriterionFinal Certification Criterion
§170.302(a) - Drug-drug, drug-allergy, drug-formulary checksImplement drug-drug and drug-allergy interaction checksThe EP/eligible hospital/CAH has enabled this functionality for the entire EHR reporting periodInterim Final Rule Text:
(1)Alerts. Automatically and electronically generate and indicate in real-time, alerts at the point of care for drug-drug and drug-allergy contraindications based on medication list, medication allergy list, age, and computerized provider order entry (CPOE).
(3)Customization. Provide certain users with administrator rights to deactivate, modify, and add rules for drug-drug and drug-allergy checking.
(4)Alert statistics. Automatically and electronically track, record, and generate reports on the number of alerts responded
Final Rule Text:
§170.302(a)
(1) Notifications. Automatically and electronically generate and indicate in real-time, notifications at the point of care for drug-drug and drug-allergy contraindications based on medication list, medication allergy list, and computerized provider order entry (CPOE).
(2) Adjustments. Provide certain users with the ability to adjust notifications provided for drug-drug and drug-allergy interaction checks.
§170.302(a) - Drug-drug, drug-allergy, drug-formulary checksImplement drug-formulary checksThe EP/eligible hospital/CAH has enabled this functionality and has access to at least one internal or external drug formulary for the entire EHR reporting periodInterim Final Rule Text:
(2)Formulary checks. Enable a user to electronically check if drugs are in a formulary or preferred drug list in accordance with the standard specified in §170.205(b).
Final Rule Text:
§170.302(b)
Drug-formulary checks. Enable a user to electronically check if drugs are in a formulary or preferred drug list.
§170.302(b) - Maintain up-to-date problem listMaintain an up-to-date problem list of current and active diagnosesMore than 80% of all unique patients seen by the EP or admitted to the eligible hospital’s or CAH’s inpatient or emergency department (POS 21 or 23) have at least one entry or an indication that no problems are known for the patient recorded as structured dataInterim Final Rule Text:
Maintain up-to-date problem list. Enable a user to electronically record, modify, and retrieve a patient’s problem list for longitudinal care in accordance with:
(1) The standard specified in §170.205(a)(2)(i)(A); or
(2) At a minimum, the version of the
Final Rule Text:
§170.302(c)
Final rule text remains the same as Interim Final Rule text, except for references to adopted standards, which have been changed.
§170.302(c) - Maintain active medication listMaintain active medication listMore than 80% of all unique patients seen by the EP or admitted to the eligible hospital’s or CAH’s inpatient or emergency department (POS 21 or 23) have at least one entry (or an indication that the patient is not currently prescribed any medication) recorded as structured dataInterim Final Rule Text:
Maintain active medication list. Enable a user to electronically record, modify, and retrieve a patient’s active medication list as well as medication history for longitudinal care in accordance with the standard specified in §170.205(a)(2)(iv).
Final Rule Text:
§170.302(d)
Maintain active medication list. Enable a user to electronically record, modify, and retrieve a patient’s active medication list as well as medication history for longitudinal care.
§170.302(d) - Maintain active medication allergy listMaintain active medication allergy listMore than 80% of all unique patients seen by the EP or admitted to the eligible hospital’s or CAH’s inpatient or emergency department (POS 21or 23) have at least one entry (or an indication that the patient has no known medication allergies) recorded as structured dataInterim Final Rule Text:
Maintain active medication allergy list. Enable a user to electronically record, modify, and retrieve a patient’s active medication allergy list as well as medication allergy history for longitudinal care.
Final Rule Text:
Unchanged
Now §170.302(e)
§170.302(e) - Record and chart vital signsRecord and chart changes in vital signs:
•          Height
•          Weight
•          Blood pressure
•          Calculate and display BMI
•          Plot and display growth charts for children 2-20 years, including BMI
For more than 50% of all unique patients age 2 and over seen by the EP or admitted to eligible hospital’s or CAH’s inpatient or emergency department (POS 21 or 23), height, weight and blood pressure are recorded as structured dataInterim Final Rule Text:
(1)Vital signs. Enable a user to electronically record, modify, and retrieve a patient’s vital signs including, at a minimum, the height, weight, blood pressure, temperature, and pulse.
(2)Calculate body mass index. Automatically calculate and display body mass index (BMI) based on a patient’s height and weight.
(3) Plot and display growth charts. Plot and electronically display, upon request, growth charts for patients 2-20 years old.
Final Rule Text:
§170.302(f)
(1)Vital signs. Enable a user to electronically record, modify, and retrieve a patient’s vital signs including, at a minimum, height, weight, and blood pressure.
(2) Unchanged
(3) Unchanged
§170.302(f) - Smoking statusRecord smoking status for patients 13 years old or olderMore than 50% of all unique patients 13 years old or older seen by the EP or admitted to the eligible hospital’s or CAH’s inpatient or Emergency department (POS 21 or 23) have smoking status recorded as structured dataInterim Final Rule Text:
Smoking status. Enable a user to electronically record, modify, and retrieve the smoking status of a patient. Smoking status types must include: current smoker, former smoker, or never smoked.
Final Rule Text:
§170.302(g)
Smoking status. Enable a user to electronically record, modify, and retrieve the smoking status of a patient. Smoking status types must include: current every day smoker; current some day smoker; former smoker; never smoker; smoker, current status unknown; and unknown if ever smoked
§170.302(g) - Incorporate laboratory test resultsIncorporate clinical lab-test results into
certified EHR technology as structured data
More than 40% of all clinical lab tests
results ordered by the EP or by an authorized provider of the eligible hospital or CAH for patients admitted to its inpatient or emergency department (POS 21 or 23) during the EHR reporting period whose results are eitEHR in a positive/negative or numerical format are incorporated in certified EHR technology as structured data
Interim Final Rule Text:
(1) Receive results. Electronically receive clinical laboratory test results in a structured format and display such results in human eadable format.
(2) Display codes in readable format. Electronically display in human readable format any clinical laboratory tests that have been received with LOINC® codes.
(3) Display test report information. Electronically display all the information for a test report specified at 42 CFR 493.1291(c)(1) through (7).
(4) Update. Enable a user to electronically update a patient’s record based upon received laboratory test results.
Final Rule Text:
§170.302(h)
(1) Unchanged
(2) Display test report information. Electronically display all the information for a test report specified at 42 CFR 493.1291(c)(1) through (7).
(3) Incorporate results. Electronically attribute, associate, or link a laboratory test result to a laboratory order or patient record.
§170.302(h) - Generate patient listsGenerate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research or outreachGenerate at least one report listing patients of the EP, eligible hospital or CAH with a specific conditionInterim Final Rule Text:
Generate patient lists. Enable a user to electronically select, sort, retrieve, and output a list of patients and patients’ clinical information, based on user-defined demographic data, medication list, and specific conditions.
Final Rule Text:
§170.302(i)
Generate patient lists. Enable a user to electronically select, sort, retrieve, and generate lists of patients according to, at a minimum, the data elements included in:
(1) Problem list;
(2) Medication list;
(3) Demographics; and
(4) Laboratory test results.
§170.302(i) - Report quality measuresEligible
Professionals: Report ambulatory clinical quality measures to CMS or the States

Eligible Hospitals and CAHs: Report hospital clinical quality measures to CMS or the States
For 2011, provide aggregate numerator, denominator, and exclusions through attestation as discussed in section II(A)(3) of [the Medicare and Medicaid EHR Incentive Programs final rule]

For 2012, electronically submit the clinical quality measures as discussed in section II(A)(3) of [the Medicare and Medicaid EHR Incentive Programs final rule]
Interim Final Rule Text:
(1) Display. Calculate and electronically display quality measures as specified by CMS or states.
(2) Submission. Enable a user to electronically submit calculated quality measures in accordance with the standard and implementation
specifications specified in §170.205(e).
Final Rule Text:
§170.304(j)
(1) Calculate.
(i) Electronically calculate all of the core clinical measures specified by CMS for eligible professionals.
(ii) Electronically calculate, at a minimum, three clinical quality measures specified by CMS for eligible professionals, in addition to those clinical quality measures specified in paragraph (1)(i).
(2) Submission. Enable a user to electronically submit calculated clinical quality measures in accordance with the standard and implementation specifications specified in §170.205(f).
§170.302(j) - Check insurance eligibility and §170.302(k) - Submit claims§170.302(j) - Check insurance eligibility
Removed from
final rule
Removed from final ruleInterim Final Rule Text:
Enable a user to electronically record and display patients’ insurance eligibility, and submit insurance eligibility queries to public or private payers and receive an eligibility response in accordance with the applicable standards and implementation specifications specified in §170.205(d)(1) or (2).
Final Rule Text:
Removed
§170.302(j) - Check insurance eligibility and §170.302(k) - Submit claimseligibility and §170.302(k) - Submit claims
Removed from
final rule
Removed from final ruleInterim Final Rule Text:
Enable a user to electronically submit claims to public or private payers in accordance with the standard and implementation specifications specified in §170.205(d)(3).
Final Rule Text:
Removed
§170.302(l) - Medication reconciliationThe EP, eligible hospital or CAH who receives a patient from another setting of care or provider of care or believes an encounter is relevant should perform medication reconciliationThe EP, eligible hospital or CAH performs medication reconciliation for more than 50% of transitions of care in which the patient is transitioned into the care of the EP or admitted to the eligible hospital’s or CAH’s inpatient or emergency department (POS 21 or 23)Interim Final Rule Text:
Medication reconciliation. Electronically complete medication reconciliation of two or more medication lists by comparing and merging into a single medication list that can be electronically displayed in real-time.
Final Rule Text:
§170.302(j)
Medication reconciliation. Enable a user to electronically compare two or more medication lists.
§170.302(m) - Submission to immunization registriesCapability to submit electronic data to immunization registries or Immunization Information Systems and actual submission in accordance with applicable law and practicePerformed at least one test of certified EHR technology's capacity to submit electronic data to immunization registries and follow up submission if the test is successful (unless none of the immunization registries to which the EP, eligible hospital or CAH submits such information have the capacity to receive the information electronically)Interim Final Rule Text:
Submission to immunization registries.
Electronically record, retrieve, and transmit immunization information to immunization registries in accordance with:
(1) One of the standards specified in §170.205(h)(1) and, at a minimum, the version of the standard specified in §170.205(h)(2); or
(2) The applicable state-designated standard format.
Final Rule Text:
§170.302(k)
Submission to immunization registries.
Electronically record, modify, retrieve, and submit immunization information in accordance with: (1) The standard (and applicable implementation specifications) specified in §170.205(e)(1) or
§170.205(e)(2); and
(2) At a minimum, the version of the standard specified in §170.207(e).
§170.302(n) - Public health surveillanceCapability to submit electronic syndromic surveillance data to public health agencies and actual submission in accordance with applicable law and practicePerformed at least one test of certified EHR technology's capacity to provide electronic syndromic surveillance data to public health agencies and follow-up submission if the test is successful (unless none of the public health agencies to which an EP, eligible hospital or CAH submits such information have the capacity to receive the information electronically)Interim Final Rule Text:
Public health surveillance. Electronically record, retrieve, and transmit syndrome-based public health surveillance information to public health
agencies in accordance with one of the standards specified in §170.205(g).
Final Rule Text:
§170.302(l)
Public health surveillance. Electronically record, modify, retrieve, and submit syndrome-based public health surveillance information in
accordance with the standard (and applicable implementation specifications) specified in §170.205(d)(1) or §170.205(d)(2).
§170.302(o) - Access controlProtect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilitiesConduct or review a security risk analysis per 45 CFR 164.308 (a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management processInterim Final Rule Text:
Access control. Assign a unique name and/or number for identifying and tracking user identity and establish controls that permit only authorized users to access electronic health information.
Final Rule Text:
§170.302(o)
Unchanged
§170.302(p) - Emergency accessInterim Final Rule Text:
Emergency access. Permit authorized users (who are authorized for emergency situations) to access electronic health information during an emergency.
Final Rule Text:
§170.302(p)
Unchanged
§170.302(q) - Automatic log-offInterim Final Rule Text:
Automatic log-off. Terminate an electronic session after a re-determined time of inactivity.
Final Rule Text:
§170.302(q)
Unchanged
§170.302(r) - Audit logInterim Final Rule Text:
(1) Record actions. Record actions related to electronic health information in accordance with the standard specified in §170.210(b).
(2) Alerts. Provide alerts based on user-defined events.
(3) Display and print. Electronically display and print all or a specified set of recorded information upon request or at a set period of time.
Final Rule Text:
§170.302(r)
(1) Record actions. Record actions related to electronic health information in accordance with the standard specified in §170.210(b).
(2) Generate audit log. Enable a user to generate an audit log for a specific time period and to sort entries in the audit log according to any of the elements specified in the standard at 170.210(b).
§170.302(s) - IntegrityInterim Final Rule Text:
(1)In transit. Verify that electronic health information has not been altered in transit in accordance with the standard specified in §170.210(c).
(2) Detection. Detect the alteration and deletion of electronic health information and audit logs, in accordance with the standard specified in §170.210(c).
Final Rule Text:
§170.302(s)
(1) Create a message digest in accordance with the standard specified in 170.210(c).
(2) Verify in accordance with the standard specified in 170.210(c) upon receipt of electronically exchanged health information that such information has not been altered.
(3) Detection. Detect the alteration of audit logs.
§170.302(t) - AuthenticationInterim Final Rule Text:
(1)Local. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information.
(2)Cross network. Verify that a person or entity seeking access to electronic health information across a network is the one claimed and is authorized to access such information in accordance with the standard specified in §170.210(d).
Final Rule Text:
§170.302(t)
Authentication. Verify that a person or entity seeking access to electronic health information is the one claimed and is authorized to access such information.
§170.302(u) - EncryptionInterim Final Rule Text:
(1) General. Encrypt and decrypt electronic health information according to user-defined preferences in accordance with the standard specified in §170.210(a)(1).
(2) Exchange. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in §170.210(a)(2).
Final Rule Text:
§170.302(u)
General encryption. Encrypt and decrypt electronic health information in accordance with the standard specified in §170.210(a)(1), unless the Secretary determines that the use of such algorithm would pose a significant security risk for Certified EHR Technology.
§170.302(v)
Encryption when exchanging electronic health information. Encrypt and decrypt electronic health information when exchanged in accordance with the standard specified in §170.210(a)(2).
§170.302(v) - Accounting of disclosuresInterim Final Rule Text:
Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in §170.210(e).
Final Rule Text:
§170.302(w)
Certification criterion made optional, while the text of this certification criterion remains unchanged
§170.304(a) - Computerized provider order entryUse CPOE for medication orders directly entered by any licensed healthcare professional who can enter orders into the medical record per state, local and professional guidelinesMore than 30% of unique patients with at least one medication in their medication list seen by the EP or admitted to the eligible hospital’s or CAH’s inpatient or emergency department (POS 21 or 23) have at least one medication order entered using CPOEInterim Final Rule Text:
Enable a user to electronically record, store, retrieve, and manage, at a minimum, the following order types:
(1) Medications;
(2) Laboratory;
(3) Radiology/imaging; and
(4) Provider referrals.
Final Rule Text:
§170.304(a)
Computerized provider order entry. Enable a user to electronically record, store, retrieve, and modify, at a minimum, the following order types:
(1) Medications;
(2) Laboratory; and
(3) Radiology/imaging.
§170.304(b) - Electronically exchange prescription informationGenerate and Transmit permissible prescriptions electronically (eRx)More than 40% of all permissible prescriptions written by the EP are transmitted electronically using certified EHR technologyInterim Final Rule Text:
Enable a user to electronically transmit medication orders (prescriptions) for patients in accordance with the standards specified in §170.205(c).
Final Rule Text:
§170.304(b)
Electronic prescribing. Enable a user to electronically generate and transmit prescriptions and prescription-related information in accordance with:
(1) The standard specified in §170.205(b)(1) or §170.205(b)(2); and
(2) The standard specified in 170.207(d).
§170.304(c) - Record demographicsRecord demographics
• preferred language
• gender
• race
• ethnicity
• date of birth
More than 50% of all unique patients seen by the EP or admitted to the eligible hospital’s or CAH’s inpatient or Emergency department (POS 21 or 23) have Demographics recorded as structured dataInterim Final Rule Text:
Enable a user to electronically record, modify, and retrieve patient demographic data including preferred language, insurance type, gender, race, ethnicity, and date of birth.
Final Rule Text:
§170.304(c)
Record demographics. Enable a user to electronically record, modify, and retrieve patient demographic data including preferred language, gender, race, ethnicity, and date of birth. Enable race and ethnicity to be recorded in accordance with the standard specified at 170.207(f).
§170.304(d) - Generate patient reminder listSend reminders to
patients per patient
preference for
preventive/ follow
up care
More than 20% of
all unique patients
65 years or older or
5 years old or
younger were sent
an appropriate
reminder during
the EHR reporting
period
Interim Final Rule Text:
Electronically generate, upon request, a patient reminder list for preventive or follow-up care according to patient preferences based on demographic data, specific conditions, and/or medication list.
Final Rule Text:
§170.304(d)
Patient reminders. Enable a user to electronically generate a patient reminder list for preventive or follow-up care according to patient preferences based on, at a minimum, the data elements included in:
(1) Problem list;
(2) Medication list;
(3) Medication allergy list;
(4) Demographics; and
(5) Laboratory test results.
§170.304(e) - Clinical decision supportImplement one clinical decision support rule relevant to specialty or high clinical priority along with the ability to track compliance that ruleImplement one clinical decision support ruleInterim Final Rule Text:
(1) Implement rules. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drugallergy contraindication checking) according to specialty or clinical priorities that use demographic data, specific patient diagnoses, conditions, diagnostic test results and/or patient medication list.
(2) Alerts. Automatically and electronically generate and indicate in real-time, alerts and care suggestions based upon clinical decision support rules and evidence grade.
(3) Alert statistics. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user.
Final Rule Text:
§170.304(e)
(1) Implement rules. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drugallergy contraindication checking) based on the data elements included in: problem list; medication list; demographics; and laboratory test results.
(2) Notifications. Automatically and electronically generate and indicate in real-time, notifications and care suggestions based upon clinical decision support rules.
§170.304(f) - Electronic copy of health informationProvide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, medication allergies), upon requestMore than 50% of all patients of the EP or the inpatient or emergency departments of the eligible hospital or CAH (POS 21 or 23) who request an electronic copy of their health information are provided it within 3 business daysInterim Final Rule Text:
Enable a user to create an electronic copy of a patient’s clinical information, including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures in:
(1) Human readable format; and
(2) On electronic media or through some other electronic means in accordance with:
(i) One of the standards specified in §170.205(a)(1);
(ii) The standard specified in §170.205(a)(2)(i)(A), or, at a minimum, the version of the standard specified in §170.205(a)(2)(i)(B);
(iii) One of the standards specified in §170.205(a)(2)(ii);
(iv) At a minimum, the version of the standard specified in §170.205(a)(2)(iii); and
(v) The standard specified in §170.205(a)(2)(iv).
Final Rule Text:
§170.304(f)
Electronic copy of health information. Enable a user to create an electronic copy of a patient’s clinical information,
including, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list in:
(1) Human readable format; and
(2) On electronic media or through some other electronic means in accordance with:
(i) The standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2); and
(ii) For the following data elements the applicable standard must be used:
(A) Problems. The standard specified in §170.207(a)(1) or, at a minimum, the version of the standard specified in §170.207(a)(2);
(B)Laboratory test results. At a minimum, the version of the standard specified in §170.207(c); and
(C) Medications. The standard specified in §170.207(d).
§170.304(g) - Timely accessProvide patients with timely electronic access to their health information (including lab results, problem list, medication lists, medication allergies) within four business days of the information being available to the EPMore than 10% of all unique
patients seen by the EP are
provided timely (available to
the patient within four
business days of being
updated in the certified EHR
technology) electronic access
to their health information
subject to the EP’s discretion
to withhold certain
information
Interim Final Rule Text:
Enable a user to provide patients with online access to their clinical information, including, at a minimum, lab test results, problem list,
medication list, medication allergy list, immunizations, and procedures.
Final Rule Text:
§170.304(g)
Timely access. Enable a user to provide patients with online access to their clinical information, including, at a minimum, lab test results, problem list, medication list, and medication allergy list.
§170.304(h) - Clinical summariesProvide clinical summaries for patients for each office visitClinical summaries provided to patients for more than 50% of all office visits within 3 business daysInterim Final Rule Text:
(1) Provision. Enable a user to provide clinical summaries to patients for each office visit that include, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations and procedures.
(2) Provided electronically. If the clinical summary is provided electronically it must be:
(i) Provided in human readable format; and
(ii) On electronic media or through some other electronic means in accordance with:
(A) One of the standards specified in §170.205(a)(1);
(B) The standard specified in §170.205(a)(2)(i)(A), or, at a minimum, the version of the standard specified in §170.205(a)(2)(i)(B);
(C) One of the standards specified in §170.205(a)(2)(ii);
(D) At a minimum, the version of the standard specified in §170.205(a)(2)(iii); and
(E) The standard specified in §170.205(a)(2)(iv).
Final Rule Text:
§170.304(h)
Clinical summaries. Enable a user to provide clinical summaries to patients for each office visit that include, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list. If the clinical summary is provided electronically it must be:
(1) Provided in human readable format; and
(2) Provided on electronic media or through some other electronic means in accordance with:
(i) The standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2); and
(ii) For the following data elements the applicable standard must be used:
(A) Problems. The standard specified in §170.207(a)(1) or, at a minimum, the version of the standard specified in §170.207(a)(2);
(B)Laboratory test results. At a minimum, the version of the standard specified in §170.207(c); and
(C) Medications. The standard specified in §170.207(d).
§170.304(i) - Exchange clinical information and patient summary recordCapability to exchange key clinical information (for example, problem list, medication list, medication allergies, diagnostic test results), among providers of care and patient authorized entities electronically
-----------------------The EP, eligible hospital or CAH who transitions their patient to another setting of care or provider of care or refers their patient to another provider of care should provide summary of care record for each transition of care or referral
Performed at least one test of certified EHR technology's capacity to electronically exchange key clinical information
----------------------
The EP, eligible hospital or CAH who transitions or refers their patient to another setting of care or provider of care provides a summary of care record for more than 50% of transitions of care and referrals
Interim Final Rule Text:
(1) Electronically receive and display. Electronically receive a patient’s summary record, from other providers and organizations including, at a minimum, diagnostic tests results, problem list, medication list, medication allergy list, immunizations, and procedures in accordance with §170.205(a) and upon receipt of a patient summary record formatted in an alternate standard specified in §170.205(a)(1),
display it in human readable format.
(2) Electronically transmit. Enable a user to electronically transmit a patient summary record to other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures in accordance with:
(i)One of the standards specified in §170.205(a)(1);
(ii)The standard specified in §170.205(a)(2)(i)(A), or, at a minimum, the version of the standard specified in §170.205(a)(2)(i)(B);
(iii)One of the standards specified in §170.205(a)(2)(ii);
(iv)At a minimum, the version of the standard specified in §170.205(a)(2)(iii); and
(v)The standard specified in §170.205(a)(2)(iv).
Final Rule Text:
§170.304(i)
(1) Electronically receive and display. Electronically receive and display a patient’s summary record, from other providers and organizations including, at a minimum, diagnostic tests results, problem list, medication list, and medication allergy list in accordance with the standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2). Upon receipt of a patient summary record formatted according to the alternative standard, display it in human readable format.
(2) Electronically transmit. Enable a user to electronically transmit a patient summary record to other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, and medication allergy list in accordance with:
(i) The standard (and applicable implementation specifications) specified in §170.205(a)(1) or §170.205(a)(2); and
(ii) For the following data elements the applicable standard must be used:
(A) Problems. The standard specified in §170.207(a)(1) or, at a minimum, the version of the standard specified in §170.207(a)(2);
(B) Laboratory test results. At a minimum, the version of the
standard specified in §170.207(c); and
(C) Medications. The standard specified in §170.207(d).
Patient EducationUse certified EHR technology to identify patient-specific education resources and provide those resources to the patient if appropriateMore than 10% of all unique patients seen by the EP or admitted to the eligible hospital’s or CAH’s inpatient or emergency department (POS 21 or 23) are provided patient-specific education
resources
N/AFinal Rule Text:
§170.302(m)
Patient-specific education resources. Enable a user to electronically identify and provide patient-specific education resources according to, at a minimum, the data elements included in the patient’s: problem list; medication list; and laboratory test results; as well as provide such resources to the patient.
Measure CalculationN/AN/AN/AFinal Rule Text:
§170.302(n)
Automated measure calculation. For each meaningful use objective with a percentage-based measure, electronically record the numerator and denominator and generate a report including the numerator, denominator, and resulting percentage associated with each applicable meaningful use measure.
HOSPITAL ONLY CRITERIA
§170.306(a) - Computerized provider order entryUse CPOE for
medication orders
directly entered by
any licensed
healthcare
professional who
can enter orders
into the medical
record per state,
local and
professional
guidelines
More than 30% of
unique patients
with at least one
medication in their
medication list
seen by the EP or
admitted to the
eligible hospital’s
or CAH’s inpatient
or emergency
department (POS
21 or 23) have at
least one
medication order
entered using
CPOE
Interim Final Rule Text:
Enable a user to electronically record, store, retrieve, and
manage, at a minimum, the following order types:
(1) Medications;
(2) Laboratory;
(3) Radiology/imaging;
(4) Blood bank;
(5) Physical therapy;
(6) Occupational therapy;
(7) Respiratory therapy;
(8) Rehabilitation therapy;
(9) Dialysis;
(10) Provider consults; and
(11) Discharge and transfer.
Final Rule Text:
§170.306(a)
Computerized provider order entry. Enable a user to electronically record, store, retrieve, and modify, at a
minimum, the following order types:
(1) Medications;
(2) Laboratory; and
(3) Radiology/imaging.
§170.306(b) - Record demographicsRecord demographics
• preferred language
• gender
• race
• ethnicity
• date of birth
• date and
preliminary cause
of death in the
event of mortality
in the eligible
hospital or CAH
More than 50% of
all unique patients
seen by the EP or
admitted to the
eligible hospital’s
or CAH’s inpatient
or emergency
department (POS
21 or 23) have
demographics
recorded as
structured data
Interim Final Rule Text:
Enable a user to electronically record, modify, and retrieve
patient demographic data including preferred language,
insurance type, gender, race, ethnicity, date of birth, and
date and cause of death in the event of mortality.
Final Rule Text:
§170.306(b)
Record demographics. Enable a user to electronically
record, modify, and retrieve patient demographic data
including preferred language, gender, race, ethnicity, date of
birth, and date and preliminary cause of death in the event
of mortality. Enable race and ethnicity to be recorded in
accordance with the standard specified at §170.207(f).
§170.306(c) - Clinical decision supportImplement one
clinical decision
support rule related
to a high priority
hospital condition
along with the
ability to track
compliance with
that rule
Implement one
clinical decision
support rule
Interim Final Rule Text:
(1) Implement rules. Implement automated, electronic clinical
decision support rules (in addition to drug-drug and drugallergy
contraindication checking) according to a high priority
hospital condition that use demographic data, specific patient
diagnoses, conditions, diagnostic test results and/or patient
medication list.
(2) Alerts. Automatically and electronically generate and
indicate in real-time, alerts and care suggestions based upon
clinical decision support rules and evidence grade.
(3) Alert statistics. Automatically and electronically track,
record, and generate reports on the number of alerts responded
to by a user.
Final Rule Text:
§170.306(c)
(1) Implement rules. Implement automated, electronic clinical
decision support rules (in addition to drug-drug and drugallergy
contraindication checking) based on the data elements
included in: problem list; medication list; demographics; and
laboratory test results.
(2) Notifications. Automatically and electronically generate
and indicate in real-time, notifications and care suggestions
based upon clinical decision support rules.
§170.306(d) - Electronic copy of health informationProvide patients
with an electronic
copy of their health
information
(including
diagnostic test
results, problem
list, medication
lists, medication
allergies, discharge
summary,
procedures), upon
request
More than 50% of
all patients of the
EP or the inpatient
or emergency
departments of the
eligible hospital or
CAH (POS 21 or
23) who request an
electronic copy of
their health
information are
provided it within 3
business days
Interim Final Rule Text:
Enable a user to create an electronic copy of a patient’s
clinical information, including, at a minimum, diagnostic test
results, problem list, medication list, medication allergy list,
immunizations, procedures, and discharge summary in:
(1) Human readable format; and
(2) On electronic media or through some other electronic
means in accordance with:
(i) One of the standards specified in §170.205(a)(1);
(ii) The standard specified in §170.205(a)(2)(i)(A), or, at a
minimum, the version of the standard specified in
§170.205(a)(2)(i)(B);
(iii) One of the standards specified in §170.205(a)(2)(ii);
(iv) At a minimum, the version of the standard specified in §170.205(a)(2)(iii); and
(v) The standard specified in §170.205(a)(2)(iv).
Final Rule Text:
§170.306(d)
(1) Enable a user to create an electronic copy of a patient’s
clinical information, including, at a minimum, diagnostic test
results, problem list, medication list, medication allergy list,
and procedures:
(i) In human readable format; and
(ii) On electronic media or through some other electronic
means in accordance with:
(A) The standard (and applicable implementation
specifications) specified in §170.205(a)(1) or §170.205(a)(2);
and
(B) For the following data elements the applicable standard
must be used:
(1) Problems. The standard specified in §170.207(a)(1) or, at a
minimum, the version of the standard specified in
§170.207(a)(2);
(2) Procedures. The standard specified in §170.207(b)(1) or
§170.207(b)(2);
(3) Laboratory test results. At a minimum, the version of the
standard specified in §170.207(c); and
(4) Medications. The standard specified in §170.207(d).
(2) Enable a user to create an electronic copy of a patient’s
discharge summary in human readable format and on
electronic media or through some other electronic means.
§170.306(e) - Electronic copy of discharge informationProvide patients
with an electronic
copy of their
discharge
instructions at time of discharge, upon
request
More than 50% of
all patients who are
discharged from an
eligible hospital or
CAH’s inpatient department or
emergency
department (POS
21 or 23) and who
request an
electronic copy of
their discharge
instructions are
provided it
Interim Final Rule Text:
Enable a user to create an electronic copy of the discharge
instructions and procedures for a patient, in human readable
format, at the time of discharge on electronic media or
through some other electronic means.
Final Rule Text:
§170.306(e)
Electronic copy of discharge instructions. Enable a user to
create an electronic copy of the discharge instructions for a
patient, in human readable format, at the time of discharge on
electronic media or through some other electronic means.
§170.306(f) - Exchange clinical information and summary record.Capability to
exchange key
clinical information
(for example,
discharge
summary,
procedures,
problem list,
medication list,
medication
allergies, diagnostic
test results), among
providers of care
and patient
authorized entities
electronically
----------------------
The EP, eligible
hospital or CAH
who transitions
their patient to
another setting of
care or provider of
care or refers their
patient to another
provider of care
should provide
summary of care
record for each
transition of care or
referral
Performed at least
one test of certified
EHR technology's
capacity to
electronically
exchange key
clinical information
----------------------
The EP, eligible
hospital or CAH
who transitions or
refers their patient
to another setting
of care or provider
of care provides a
summary of care
record for more
than 50% of
transitions of care
and referrals
Interim Final Rule Text:
(1) Electronically receive and display. Electronically receive a
patient’s summary record from other providers and
organizations including, at a minimum, diagnostic test results,
problem list, medication list, medication allergy list,
immunizations, procedures, and discharge summary in
accordance with §170.205(a) and upon receipt of a patient
summary record formatted in an alternate standard specified in
§170.205(a)(1), display it in human readable format.
(2) Electronically transmit. Enable a user to electronically
transmit a patient’s summary record to other providers and
organizations including, at a minimum, diagnostic results,
problem list, medication list, medication allergy list,
immunizations, procedures, and discharge summary in
accordance with:
(i) One of the standards specified in §170.205(a)(1);
(ii) The standard specified in §170.205(a)(2)(i)(A), or, at a
minimum, the version of the standard specified in
§170.205(a)(2)(i)(B);
(iii) One of the standards specified in §170.205(a)(2)(ii);
(iv) At a minimum, the version of the standard specified in
§170.205(a)(2)(iii); and
(v) The standard specified in §170.205(a)(2)(iv).
Final Rule Text:
§170.306(f)
(1) Electronically receive and display. Electronically receive
and display a patient’s summary record from other providers
and organizations including, at a minimum, diagnostic test
results, problem list, medication list, medication allergy list,
and procedures in accordance with the standard (and
applicable implementation specifications) specified in
§170.205(a)(1) or §170.205(a)(2). Upon receipt of a patient
summary record formatted according to the alternative
standard, display it in human readable format.
(2) Electronically transmit. Enable a user to electronically
transmit a patient’s summary record to other providers and
organizations including, at a minimum, diagnostic results,
problem list, medication list, medication allergy list, and
procedures in accordance with:
(i) The standard (and applicable implementation
specifications) specified in §170.205(a)(1) or §170.205(a)(2);
and
(ii) For the following data elements the applicable standard
must be used:
(A) Problems. The standard specified in §170.207(a)(1) or, at a minimum, the version of the standard specified in
§170.207(a)(2);
(B) Procedures. The standard specified in §170.207(b)(1) or
§170.207(b)(2);
(C) Laboratory test results. At a minimum, the version of the
standard specified in §170.207(c); and
(D) Medications. The standard specified in §170.207(d).
§170.306(g) - Reportable lab resultsCapability to
submit electronic
data on reportable
(as required by
state or local law)
lab results to public
health agencies and
actual submission
in accordance with
applicable law and
practice
Performed at least one test of
certified EHR technology’s
capacity to provide electronic
submission of reportable lab
results to public health agencies
and follow-up submission if the
test is successful (unless none of
the public health agencies to
which eligible hospital or CAH
submits such information have
the capacity to receive the
information electronically)
Interim Final Rule Text:
Electronically record, retrieve, and transmit
reportable clinical lab results to public health
agencies in accordance with the standard
specified in §170.205(f)(1) and, at a minimum,
the version of the standard specified in
§170.205(f)(2).
Final Rule Text:
§170.306(g)
Reportable lab results. Electronically record,
modify, retrieve, and submit reportable clinical
lab results in accordance with the standard (and
applicable implementation specifications)
specified in §170.205(c) and, at a minimum, the
version of the standard specified in
§170.207(c).
Record Advance DirectivesRecord advance
directives for
patients 65 years
old or older
More than 50% of all unique
patients 65 years old or older
admitted to the eligible
hospital’s or CAH’s inpatient
department (POS 21) have an
indication of an advance
directive status recorded
N/AFinal Rule Text:
§170.306(h)
Advance directives. Enable a user to
electronically record whether a patient has an
advance directive.