Hashtag Soup: Relating QDM, HQMF, eMeasures, QueryHealth, QRDA, SIFramework and MeaningfulUse Stage2

This showed up in my inbox yesterday:

Hello Keith, 

I am trying to figure out how the following abbreviations are connected - NQF's QDM, HQMF, eMeasures, Query Health, QRDA, QDM based QRDAs, others.
Rather than individual definitions, I am a bit in the dark around how each of these are interconnected.

Appreciate your help.

Warm Regards, Shyam 

It's a question worthy of a full post, rather than a brief answer, so here goes.

---

QDM is the National Quality Forum's (NQF) Quality Data Model.  It is an information model representing the essential data needed to generate quality measures.  Because it is an information model, it doesn't necessarily go into the level of detail needed in an implementation, but it certainly describes the high level structures that an implementation needs to compute quality measures.

eMeasures is a term describing the electronic representation of quality measures.  In common use, it often refers to the electronic measures that NQF developed to represent the quality measures required under the ONC & CMS Meaningful Use regulations.  It is also used to refer to the HL7 HQMF.

HQMF stands for Health Quality Measure Format.  This is an HL7 Draft Standard for Trial Use (DSTU).  The DSTU is presently being reballoted by HL7 for a second release.  This is an electronic format for the representation of quality measures.  Release 1 is currently used by NQF to deliver eMeasures for Meaningful Use.  Release 2 was developed in large part based on pilot work being developed by Query Health.

Query Health is an ONC Standards and Interoperability Framework project whose purpose is to develop standards to enable sending the questions to the data.  Its key goal is to enable clinical research.  We used HQMF in query health because the kinds of questions that Quality Measures need answers too are often the same kinds of questions that show up in Clinical Research.  HQMF is a declarative format for expressing those questions.  We revised and prototyped a new schema for HQMF that is simpler, easier to read, and able to be computed in a variety of programming environments.  I've written quite a bit about Query Health on this blog.

QRDA stands for Quality Reporting Data Architecture.  If HQMF/Query Health/eMeasures represent the question, then QRDA represents the answers.  QRDA is an HL7 implementation guide on CDA Release 2 that describes the format for reporting quality data on a single patient (Category I), or aggregate results on multiple patients (Category III).  The former is a DSTU, the latter nearly so.  There is also an implementation guide showing how data modeled using the QDM can be represented in a QRDA.  Both Category I and Category III specifications have been identified as being required standard formats for reporting quality measures under the Meaningful Use 2014 Certification Criteria.

MAT is the Measure Authoring Tool.  This is a tool for creating eMeasures currently being maintained by NQF, but which will be transitioned to a new maintainer in early 2013.

VSAC is the NLM Value Set Authority Center, where value sets used for eMeasures and other standards used in Meaningful Use regulation are published.

If you want a poster-sized PDF of the content, you can get it via Google Drive:

CQM Value Set Challenges in MeaningfulUse Stage2

I cannot take credit for finding this issue.  One of the teams I work with discovered this particular challenge in working with the value sets for clinical quality measures.

It seems that several value sets in the Clinical Quality Measures have been used to identify appropriate medications for treatment, but have also been reused to identify patient allergies.

What is worry-some about this is how it impacts reporting.  Think this through:

• A  patient has been seen by a provider in the last year.  That makes them part of an initial population for a measure.
• They've been diagnosed with a particular disease.  That would make them appear in the denominator.  
• If they've been given a particular medication formulation, they also fall into the numerator.
• The measure makes allowances for patients who are allergic to the treatment regimen.  But in the implementation, the measure exclusion or exception criteria REUSES the medication value set as a value set describing a medication allergy.

This is where the problem shows up, and it has two consequences.

1. In the EHR, the substance that the patient is allergic to is recorded, not a specific medication formulation.  
2. In reporting exceptions / exclusions, the EHR would report the substance, but this wouldn't match what the conformance tools check for, so the EHR would need to implement a work-around.

Formulation vs. Allergen

You cannot go from medication formulations to allergens and still preserve the meaning of the value set.  Unfortunately, the value set for treatment only lists drug formulations.  It doesn't explain which ingredients are relevant for treatment in the quality measure.  

While it is quite possible to go from formulations to active ingredients in RxNORM, and also possible to match medication allergens encoded in RxNORM to drugs that contain that active ingredient, it doesn't help.  All that does is identify one or medications in the treatment value set as being one the patient shouldn't be given.  It doesn't necessarily tell you whether there are other acceptable alternatives, nor whether there is an intention to provide an exception or exclusion if those alternatives are available.

Some formulations have two (or more) active ingredients, one of which could be the reason it is included in a value set for treatment of a particular condition, yet the patient could be allergic to another of the ingredients.  So, you'd avoid that formulation for treatment, but it wouldn't excuse the provider from finding another formulation that did contain the necessary ingredient for treatment, but didn't contain the allergen.

In other cases, related drugs are similar enough that if a patient is intolerant of one, it is sufficient to rule out others (e.g., an allergy to penicillin might also rule out amoxicillin). 

Work-Arounds

There is a work-around, but it isn't pretty.  As I mentioned above, you can determine that a patient has an allergy to an active ingredient in a medication using RxNORM.  So if the treatment value set includes medications A and B, where A contains X, and B contains X + Y, you can make a list of ingredients: X, Y.  Then any patient who is allergic to X or Y can be identified as being allergic to at least one of the medications in the treatment value set.  You can even select an appropriate "proxy" medication, by ensuring that the medication you report an allergy to includes the ingredient that the patient is allergic to.  So if you have two patients, P1 allergic to X, you might report medication A, and P2 allergic to Y, you might report medication B, as being the best proxies for these allergies.

The failure here is that a provider should possibly have considered medication A for the patient, as that might have been an effective treatment.  While it's not possible to figure out what the allergen value sets must be via an algorithm, it is very easy to generate all possible solutions and have someone choose (using clinical judgement) which solution is appropriate in each of the affected cases.

What should be done?

I'm told that most of the data necessary to correct this issue is both readily available, and has been offered to the PTB (powers that be) to resolve this issue.  The challenge is that these value sets are based on measures which have been vetted by measure authorizing bodies (like NQF and Joint Commission), and changing the value sets (perhaps) changes the meanings of the measures (but not the intent).  So, while most technical folks would think (like I do), that the easy answer is to publish the correct value sets, there are some challenges to that solution that impact provenance of the measures.

I've heard a couple of solutions offered to resolve the issue.

1. Address the issue, publish a work-around (in detail), and provide folks with enough time and/or freedom to implement measures appropriately.  "Freedom" here might include loosening some of the validation criteria for conformance tests, so that the measures could be implemented using correct data.
2. Put a push on to fix the value sets in time for Stage 2 implementation.  This is the technically easy, but organizationally difficult solution.

Of course, I'd prefer to do it right the first time, so #2 is my preferred solution.  I've been on the other end of an ONC hurry-up to finish things.  I know it sucks to be on that end of things, and that it's also risky.  But is it better to fix it now, or spend a year gathering quality measure data that won't be comparable to anything else when we finally do fix the problem?

Either way it gets resolved, my hope is that it is fixed and the PTB let us know what the plans are to get a permanent fix together.

 -- Keith

P.S.  This isn't the only problem with value sets, just the most critical one to be solved.

---

Update: December 2, 2012

Apparently, fixes are in the works.  This communication showed up in my inbox over the weekend.

CMS and ONC are working to release a public-facing tool to allow reporting and tracking of potential issues or bugs identified during the implementation process for the 2014 eCQMs released in October 2012. We encourage you to report these to the EHR Incentive Program Information Center at 1-888-734-6433 or email HIT_Quality_Measurement@cms.hhs.gov

Thank you to those who have reported issues to this point; CMS, ONC and NLM are working to resolve and will contact the reporter when a solution is agreed upon.

An update to the Value Set Authority Center (https://vsac.nlm.nih.gov) at NLM is anticipated in the near future which will include removal of the label “provisional” from value sets and codes that have been added to their respective terminologies since the measure release as well as correction of value sets related to medications and allergies. Please look to further communications from CMS, ONC, and NLM as to when this update will be released.

Public Workshop on ONC HIT Certification Program and 2014 Edition Test Methods

Crossed my desk this morning, good to know... wish they'd given a registration link or something so that we'd know where to get the additional details. Oh well.

---

Save the Date: Public Workshop on ONC HIT Certification Program and 2014 Edition Test Methods The Office of the National Coordinator (ONC) will hold a public workshop on the ONC HIT Certification Program and 2014 Edition Test Methods on Tuesday, November 13th, 9AM-4:30PM EST. The topics to be covered include 2014 Test Procedures, Test Tools, Test Data, ONC Timeline, and the Certified Health IT Product List (CHPL). This will be a virtual workshop. Additional details regarding access and agenda are forthcoming.

HL7 Offers Free Webinar Oct 24 on Laboratory Results Interface Implementation Guide Named in MeaningfulUse Stage2

 Health Level Seven® International

For Immediate Release

                                                                               

Contact: Andrea Ribick

+1 (734) 677-7777

andrea@HL7.org

HL7 Offers Free Ambassador Webinar on the S&I Framework Laboratory Results Interface Implementation Guide Named in Meaningful
Use Stage 2, on October 24, 2012

          Ann Arbor, Michigan, USA – October 15, 2012 – Health Level Seven® International (HL7®), the global authority for interoperability and standards in healthcare information technology with members in 55 countries, will present a complimentary Ambassador webinar on the Standards and Interoperability (S&I) Framework’s Laboratory Results Interface Implementation Guide on Wednesday, October 24 from 12:00 pm  - 1:00 pm EDT.

          This webinar will provide a background on the development and need for the Laboratory Results Interface (LRI) Implementation Guide (IG), which was included in the Meaningful Use Stage 2 Standards and Certification Criteria for 2014. The LRI Implementation Guide is based on HL7’s Version 2.5.1 and provides guidance for electronic reporting of laboratory test to ambulatory care providers in the U.S. This guide was developed within the S&I Framework supported by the Office of the National Coordinator of Healthcare Information Technology (ONC) and balloted through HL7. This session will give an explanation of why the guide is important, its benefits, and how it can handle multiple settings of the EHR from Ambulatory, Acute Care and Public Health through the use of profiles.  The LRI IG uses profiles to further refine the IG. The refinement can occur through the use of identifers, fields or other critical items that help define the information necessary to support the EHR and the Laboratory based on business requirements and the healthcare setting. In addition, this flexibility allows implementers to expand their use of the guide as they gain more functionality in their systems through the selection of more complex profiles.

The webinar will be presented by Ken McCaslin, Director of Healthcare Standards at Quest Diagnostics. Mr. McCaslin is an HL7 Fellow and Ambassador and serves as the co-chair of the HL7 Orders and Observations Work Group. In addition, he is also the co-chair of the S&I Framework LRI and LOI (Laboratory Order Interface) Implementation Guide Work Groups.

          This webinar is free and open to anyone interested in healthcare IT or standards development. To register for this free webinar, please visit http://www.hl7.org/events/ambassador20121024/.

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

About Health Level Seven International (HL7)

Founded in 1987, Health Level Seven International is the global authority for healthcare Information interoperability and standards with affiliates established in more than 30 countries. HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s more than 2,300 members represent approximately 700 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; Centers for Disease Control and Prevention; Duke Translational Medicine Institute; Epic; European Medicines Agency; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; IBM; Intel Corporation; InterSystems Corporation; Kaiser Permanente; Lockheed Martin; McKesson Provider Technology; Microsoft Corporation; NICTIZ National Healthcare; Novartis; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; Quest Diagnostics Inc.; Siemens Healthcare; Thomson Reuters; the U.S. Department of Defense, Military Health System; and the U.S. Department of Veterans Affairs.

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

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

# # #

MeaningfulUse Stage2 Wave 4 Test Methods Released

The next and final wave will be out October 17 according to what I've been hearing. Then there's supposed to be a three day technical workshop on the certification test methods on November 13-15 and the final test methods are scheduled for release in med December, with certification to begin on the first business day of the new year.

   -- Keith

---

2014 Draft Test Methods: Wave Four Released for Public Review and Comment The Office of the National Coordinator for Health IT (ONC) is pleased to announce the release of the fourth set of 2014 Edition draft Test Methods (test procedures, tools, and applicable test data and files). All Test Methods will undergo public review and comment before being finalized and approved by ONC for use in testing and certification. The final set of Test Methods is expected to be available for use in early 2013. Comments and suggestions should be submitted to ONC.Certification@hhs.gov. All submissions should include "2014 Test Methods" in the subject line. Please be as specific as possible in your comment submission. For additional information, and to access the 2014 Edition draft Test Methods, please visit the 2014 Edition Draft Test Procedures webpage.

Wave 3 of MeaningfulUse Stage2 Tests

I'm behind on evaluating Wave 3, and if they are following the same schedule, Wave 4 will show up tonight (although it may not, I heard something about there being a delay for the next wave).

I'm only going to be looking at two of the test procedures, because only two of them address the need to use interoperability standards per se, and I'm stretching on one of them.

Clinical Information Reconciliation

The first of the test procedures is Clinical Information Reconciliation.  I say this is a stretch because except for the IHE Reconciliation profile and the HL7 EHR Functional Model, there are few "standards" out there that address this.

This is a pretty decent set of tests.  Basically it verifies the EHR's capabilities to display in two separate lists the information to be reconciled, with attribution of the data source, and relevant dates.  There are three separate tests performed for each of the three data categories (problems, medications and allergies).

Display Test

• The Vendor creates a patient record in their EHR and populates that patient’s record  with ONC supplied medication test data in the medication list
• The Vendor creates at least one additional medication list for this patient using ONC-supplied medication test data in the(se) medication list(s)
• The Tester displays the two or more medication lists simultaneously in a single view
• The Tester verifies that each of the medication lists displays the source of the medication list and the last date each medication was documented, ordered, prescribed, refilled, or edited

The one thing that I think it is missing is ensuring that the two records used in the test are for the same patient.  You can imagine situations where all you have are patient demographics to go on here (e.g., patient transmits a recent record from provider A to another provider B using VDT, and provider B needs to reconcile his/her list with that provided by provider A).

This is something that the IHE Reconciliation profile mandates:

1. It SHALL present the demographics used to identify the patient provided by each separate source of clinical information to the end user.

Creation Test

Although appearing to be somewhat mislabeled, the point of this test it to ensure that a single unified list can be created, with corrections.

• The Tester merges the two or more medication lists from the Display test into a single reconciled medication list
• The Tester consolidates identical medications from these medication lists into one representation of those medications on the single reconciled medication list
• The Tester removes a medication from the single reconciled medication list

What IHE has to say is a bit more direct:

2. It SHALL highlight inconsistencies found during the automated reconciliation process and provide the clinician with mechanisms to adjust or correct the input.
3. It SHALL provide a mechanism for a clinician to add new information to the reconciled results.

Removal is simply one mechanism to adjust or correct.  IHE notes that you could also add new data to the results.

Review, Validate, Confirm, and Submit

This step is about saving the results.

• The Tester displays the single reconciled medication list generated in the Merge test
• The Tester reviews the reconciled medication list and validates that the data contained in the list are accurate and complete
• The Tester confirms and submits the reconciled medication list to the patient’s record in the EHR
• The Tester views the patient’s active medication list and verifies that it includes all of the reconciled medications and that these medications are accurate and complete

Again, IHE is a bit more direct about some things:

4. It SHALL authenticate the clinician prior to storage of the reconciled data (this step may be combined with other authentication steps used to finalize the record).
5. It SHALL store the resulting data for future use by other actors as described below.

Tests for the other information categories are fairly similar.

Ambulatory setting only – clinical summary

This is the big one... creating Consolidated CDA Conforming Documents.  They are using MDHT to do this testing, and given recent results reported at the HL7 Working Group Meeting, this is going to be much better than Schematron (you may recall that Dave Carlson is a Harley Award winner for his work on MDHT).

There's a lot of functional details in this test that finally address one of my favorite issues, relevant and pertinent.  You have to be able to demonstrate the provider's ability to select the relevant data in this test.

I'll have to spend more time with the testing tool to see how it works.  One of the nice features of this tool is that eventually, it will support the specified transports, to test that as well.

It looks like the put my buddy from NIST, Bill Majurski, in charge of this tool, and he's used the testing framework that NIST has been supplying IHE with to deploy this test.   I'm sure he'll be thrilled with all the e-mail this tool is going to be generating for him, especially since they put his e-mail address in the test procedure.  Good luck Bill!

  -- Keith

Happy Friday: Time for Wave 3

Just in case you had nothing better to do this weekend...

---

2014 Draft Test Methods: Wave Three Released for Public Review and Comment The Office of the National Coordinator for Health IT (ONC) is pleased to announce the release of the third set of 2014 Edition draft Test Methods (test procedures, tools, and applicable test data and files). All Test Methods will undergo public review and comment before being finalized and approved by ONC for use in testing and certification. The final set of Test Methods is expected to be available for use in early 2013. Comments and suggestions should be submitted to ONC.Certification@hhs.gov. All submissions should include "2014 Test Methods" in the subject line. Please be as specific as possible in your comment submission. For additional information, and to access the 2014 Edition draft Test Methods, please visit the 2014 Edition Draft Test Procedures webpage. .

MeaningfulUse Stage2 Wave 2 Test Procedures

Wave 2 of the Meaningful Use Stage 2 test methods were released last Friday.  Just to repeat, I'm only covering those that address interoperability standards, not other functional requirements.

I missed a test procedure released as part of wave 1 when I reviewed them a week ago (since it was released a couple of days late).  That is also included below:

Wave 1: Immunization Transmission

This one uses the NIST HL7 Version 2 Conformance testing tools.  It identifies seven separate test cases, and provides test data for each:

1. Admin for Child
2. Admin for Adult
3. Historical for Child
4. Consented Child
5. Refused Toddler
6. Varicella History Child
7. Complete Record 

What is interesting here is that they include a good cross section of test cases, testing new administrations (1 & 2), recording of historical immunizations (3), recording consent (using PD1-12) in (4), recording refusal (using RXA-18) in (5), recording a case where a prior history of disease (e.g., varicella) occured (6),  and lastly, a case where both a historical and new administration are reported (7).

These test cases raise the bar for immunization reporting from prior test procedures.  

1. You must be able to show that you can record consent in (PDI-12).
2. You must be able to show that you can record a refusal to immunize (RXA-18)
3. You must be able to record prior history of an immunizable disease (using an OBX segment).

This is in part as a result of dropping to one guide, and thus being able to provide more thorough testing.  Trying to test these three cases above using either the 2.3.1 or 2.5.1 guides would have been very challenging.  But also, I believe that the intent has been to raise the bar on interoperability between stages.  So, while the immunization requirement has not disappeared, and in fact, no new guide has been introduced, the capabilities that the EHR must be able to demonstrate are higher for Stage 2.

Wave 2: Demographics

On this test, it principally verifies that race, ethnicity, gender, and preferred language can be recorded, uses appropriate categories, allows MORE THAN ONE race to be recorded, and allows information about race, ethnicity and preferred language to be recorded as "declined to specify", representing the voluntary nature of this recording.  A lot of systems will need to look out for how to correctly handle more than one race (you need more than one row in your table, or field in your record, as "multiracial" is not an acceptable response), and ensure that "declined to specify" is one of the choices.

Family History

I was really looking forward to seeing this test procedure, because I hoped it would clarify ONC's intent for Family History, given the muddy distinction between selection of an exchange standard (The HL7 Clinical Genomics Pedigree Model), and a vocabulary standard (SNOMED CT).  I'm still clueless as to how they would test this.  

The functional requirement here is for record, change and access, for which the CG Pedigree model doesn't really apply, or only applies to the degree that the "model" and/or interactions are somehow represented within the EHR.  There's never any inspection as to whether the information is ever exchanged using the CG Pedigree Interactions or Messages.

CCDA Supports exchange of Family History information using SNOMED CT, but once again, exchange isn't part of the requirements, simply record, change and access.

The test data is "vendor supplied."  I'd be a bit more concrete, requiring demonstration of the following relationships: Mother, Father, Sister, Brother, Son, Daughter, and specify specific conditions, e.g., Breast Cancer, Stroke, CHF, Diabetes, et cetera, with different relationships.

Cancer Reporting

Despite assertions (see page 2 of the test procedure) that Cancer Registry Implementation Guide was "harmonized with the Consolidated CDA", the guide still uses templates that were antecedents to C-CDA, rather than the newer Consolidated CDA templates.  It's a shame, because this could have been fixed by replacing the old templates using the map in Consolidated CDA appendix in a matter of hours.  The test procedure is basically to run the document through the NIST CDA Validator with a specific rule set.  No real issues with this test, but I think we'll see it being little used because it's an optional criteria, and is incompatible with C-CDA (which is required).

More of Robin's Eggs

Robin's at it again.  This time, she's got a whiteboard sized poster and a pocket-sized guide.  You'll have to identify yourself to get the content.

Meaningful Use – The Whiteboard Story - www.advisory.com/MUwhiteboard

Quick Guide Comparison―Stage 1 to Stage 2 Objectives and Measures www.advisory.com/MUpocketguide

Bookmark versions of the Final Rules www.advisory.com/MUbookmarkCMS and www.advisory.com/MUbookmarkONC

The Magical Little BlueButton

John Moore over at Chilmark Research writes on "The Promise of a Little Blue Button" yesterday.  I wish I could have been in Washington, DC to help him interpret what is going on (we know each other pretty well).  I understand why he was disappointed; ONC isn't always the greatest communicator.

Anyone who knows how Blue Button started [like John], and what the VA current implementation is, would certainly be disappointed to see ONC perpetuate the distribution of ASCII text files to patients.  It used to be I wouldn't wear a Blue Button, because I had already worked on providing doctors and their patients with access to a much richer data set.  ePatientDave was so disappointed with me when I refused the Blue Button he offered me at HIMSS12.  But, I understand John's confusion.

I proudly wear a Blue Button now.  That was the day that ONC announced to a rather select group that Blue Button was no longer a noun (the ASCII Text File), but rather a verb, representing access to data.  And detailed data, just like providers have.  At that meeting, I asked Dave for the Blue Button he had offered me before, and put it on my Jacket.

The Blue Button I will use, and my daughter will use, will be a nicely formatted, quite usable [204(a)], Consolidated CDA Document [205(a)(3)] when we view [314(e)(1)(i)(A)] it.  When we download [314(e)(1)(i)(B)] it, I expect we'll have a couple of options.  We could get the Woolly Mammoth Era ASCII Text file.  We could also get the decently formatted HTML.  But, we will also be able to download to our personal devices, the detailed clinical data that appears in a HL7 Consolidated CDA document [see reference to 205(a)(3)] .  That's what we'll use.

I know of PHR vendors that will be able to import that data on apps we can (or do) use on our i* devices.  And every provider with a Meaningful Use Certified EHR will be able to support View and Download, and unless they have the broadband exception, will be able to support it for at least 5% of patients.  I'll be able get it on my iPad, and my daughter on her iPhone, and others, on their Android, or home computer.

Those same portals and apps will enable us to make available, via the transmit [314(e)(1)(i)(C)] capability, that same data to other providers we've been referred to. Their EHRs will support receipt of that data, if they are Meaningful Use Stage 2 Certified.  They'll get nicely laid out report containing meds, problems, allergies, and results (Images will likely come in Stage 3), and more.

They will contain, at the very minimum [314(e)(2)(i)], the MU Common Data Set [102], comprised of the following data elements:
1) Patient name.

2) Sex.
3) Date of birth.
4) Race
5) Ethnicity
6) Preferred language
7) Smoking status
8) Problems
9) Medications
10) Medication allergies
11) Laboratory test(s)
12) Laboratory result(s)
13) Vital signs
14) Care plan field(s), including Goals
15) Procedures
16) Care Team Member(s)

Beyond that it will also include [314(e)(2)(iii)]: 

• Reason for Visit, 
• Encounter Diagnosis, 
• Immunizations, 
• Pending Tests, 
• Clinical Instructions, 
• Future Appointments, 
• Referrals to Other Providers, 
• Future Scheduled Tests, and 
• Recommended Patient Decision Aids.

That's a pretty complete record, by any stretch of the imagination.  Printed on paper, it could go for three pages or more.

This isn't some futuristic dream, but it almost surely sounds magical.  Trust me on this one John, it's in the rules, and it's in #ABBI.

First Wave of MeaningfulUse Stage2 Test Procedures Reviewed

The Meaningful Use Stage 2 test procedures are starting to roll out as promised by ONC.  John Moerhke already reviewed several this evening.  I looked at a couple before the plane ride to Baltimore as well.

I'm going to focus on the test procedures focusing on standards-based interoperability, rather than those covering specific EHR functionality.

The first tests that I'm going to look is maintenance of the problem list and that's because it has a vocabulary standard associated with it:

§170.314(a)(5) Problem list

The relevant content from the test appear below:

IN170.314.a.5 – 4.02:  Tester shall verify that the patient problem list data entered during the test are associated with the required standard terminology. Verification methods include, but are not limited to: 

• verifying that the appropriate terminology code is displayed along with the patient problem description when the user is recording patient problems; or

• verifying that the EHR includes the capability to cross-reference (map) the user-displayed problem descriptions to the appropriate vocabulary codes; or

• verifying that the patient problem list data stored in the EHR contains the appropriate vocabulary codes

It's going to be critical for folks to be able to show that they either record the SNOMED CT code, or can map to it.  I'd like to see an additional verification method included that says something like:

• verifying that the problem list in a CCDA document produced by the EHR contains the appropriate problem descriptions and codes.  

This is something that could be automated with a conformance test tool.  You'll note that this procedure has no tools listed.

The next two procedures (Medication, and Medication Allergy List) are quite similar to the problem list test, save that they do not include vocabulary tests (because the rule doesn't require direct support of the RxNORM vocabulary terms in the EHR, even though it is likely a good idea).

I skip also the Drug Formulary test, because you are no longer required to use a specific standard in a Certified EHR.  Note, however, that providers conforming to Medicare Part D will still need that capability, it just won't be tested for the 2014 criteria.

Next up is the test procedure for smoking status:
§170.314(a)(11) Smoking status


IN170.314.a.11 – 1.02:  Tester shall verify that the patient smoking status data and the SNOMED CT®
codes are captured and stored in the patient’s record ...

This one is interesting, because they've not taken the same approach here as they did for problem list.  In this case, they ask for the specific SNOMED CT code to be recorded, and don't mention verification using the display, mapping or storage.  I'd make the two consistent, following the problem list approach (which could include a CCDA verification test procedure).

Next we get to Patient Education Resources

§170.314(a)(15) Patient-specific education resources

This one is wrong on several levels.

1. Two InfoButton guides are named with two different styles of messaging being used, but there is no verification procedure showing that the messages are being sent in any way.
2. Their are no test tools to verify the message content.  Come on, we've got an XML Schema for one guide, and a RESTful interface for the other one.  There ought to be simple one-page JSP files that validate the message structure and coded content of the outbound query.
3. It allows "manual re-entry" of EHR data.  See below for details:

Here's the relevant portion of the rule [emphasis mine]:

EHR technology must be able to electronically identify for a user patient-specific education resources based on data included in the patient's problem list, medication list, and laboratory tests and values/results

Here's the relevant portion of the test [emphasis also mine]:

The Tester electronically identifies patient-specific education resources using the HL7 Context-Aware Knowledge Retrieval Standard (with the applicable implementation guide) and at least one other vendor identified EHR function for two or more patients based on, at a minimum, the data included in the patients’ problem lists, medication lists, and laboratory tests and values/results (these queries do not need to be derived automatically from the patient data stored in the EHR; these queries may be accomplished by the Tester entering the patient data stored in the EHR into an education resources module that is accessed by the Tester through the EHR).

Say what?!  Queries do not need to be derived "automatically" from patient data, but may be accomplished by (re)entering the data in another module?

Somewhere this isn't right.  I don't think that's what the rule intended when it referenced "data included in the patient's ...", because if the patient's chart wasn't used to get the data, then they could have just said: education resources based on problems, medications, laboratory tests and/or results.  But they didn't say that.  They said "the patient's ... "

No provider should EVER have to reenter data in this fashion.  At the very least, it's a huge usability issue and could even be a patient safety issue (hypotension vs hypertension is an easy spelling error).  At the very most, providers might be asked to identify the relevant data in the chart which can be used in the InfoButton query.

Another sad point is that the guides mentioned in the rule, and the rule itself does not specify any requirement for coded content in the InfoButton messages.  That's a loss to be addressed in the 2016 criteria.  Of course, by then, my hope is that everyone will be using the IHE Retrieve Clinical Knowledge profile of InfoButton, and they can name that guide the next time around.

Stage2 Final Rule Crosswalk from MeaningfulUse Objectives to Standards

Last time around, I put together a crosswalk from Objectives to Certification, and from Certification to Standards.  This time, it's all in one spreadsheet.  Sorry for the tiny type, it's quite a bit of data, but note:

a) Most of you reading this can zoom your browsers to your four-page monitor, and
b) You can get access to the full spreadsheet in Google Docs here.  That includes bonus content, including measures, exclusions, and a crosswalk from the MU Common Data Set to the standards.

Provider Objectives	Hospital Objectives	EHR Certification Criteria	Standards
42 CFR §495.6	42 CFR §495.6	45 CFR §170.314	45 CFR §170
(j) Stage 2 core criteria for EPs.	(l) Stage 2 core criteria for eligible hospitals or CAHs
(1)(i)  Objective. Use computerized provider order entry for medication, laboratory, and radiology orders directly entered by any licensed healthcare professional who can enter orders into the medical record per State, local, and professional guidelines.	(1)(i)  Objective. Use computerized provider order entry for medication, laboratory, and radiology orders directly entered by any licensed healthcare professional who can enter orders into the medical record per State, local, and professional guidelines.	(a) Clinical. (1) Computerized provider order entry. Enable a user to electronically record, change, and access the following order types, at a minimum:   (i) Medications;   (ii) Laboratory; and   (iii) Radiology/imaging.
(2)(i)  Objective. Generate and transmit permissible prescriptions electronically (eRx).		(a) (10) Drug-formulary checks. EHR technology must automatically and electronically check whether a drug formulary (or preferred drug list) exists for a given patient and medication. (b)(3) Electronic prescribing. Enable a user to electronically create prescriptions and prescription-related information for electronic transmission in accordance with:   (i) The standard specified in § 170.205(b)(2); and   (ii) At a minimum, the version of the standard specified in § 170.207(d)(2).	205(b)(2)Standard. NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 (incorporated by reference in §170.299). 207(d)(2) Standard. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, August 6, 2012 Release (incorporated by reference in § 170.299).
(3)(i)  Objective. Record all of the following demographics:   (A) Preferred language.   (B) Sex.   (C) Race.   (D) Ethnicity.   (E) Date of birth.	(2)(i)  Objective. Record all of the following demographics:   (A) Preferred language.   (B) Sex.   (C) Race.   (D) Ethnicity.   (E) Date of birth.   (F) Date and preliminary cause of death in the event of mortality in the eligible hospital or CAH.	(a) (3) Demographics. (i) Enable a user to electronically record, change, and access patient demographic data including preferred language, sex, race, ethnicity, and date of birth.    (A) Enable race and ethnicity to be recorded in accordance with the standard specified in § 170.207(f) and whether a patient declines to specify race and/or ethnicity.   (B) Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g) and whether a patient declines to specify a preferred language.	207 (f) Race and Ethnicity. Standard. The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 (see “Revisions to the Standards for the Classification of Federal Data on Race and Ethnicity,” available at  http://www.whitehouse.gov/omb/fedreg_1997standards). 207(g) Preferred language. Standard. As specified by the Library of Congress, ISO 639-2 alpha-3 codes limited to those that also have a corresponding alpha-2 code in ISO 639-1. (incorporated by reference in § 170.299).
(4)(i)  Objective. Record and chart changes in the following vital signs:    (A) Height/Length.   (B) Weight.   (C) Blood pressure (ages 3 and over).   (D) Calculate and display body mass index (BMI).   (E) Plot and display growth charts for patients 0 - 20 years, including body mass index.	(3)(i)  Objective. Record and chart changes in the following vital signs:    (A) Height/Length.   (B) Weight.   (C) Blood pressure (ages 3 and over).   (D) Calculate and display body mass index (BMI).   (E) Plot and display growth charts for patients 0 - 20 years, including body mass index.	(a) (4) Vital signs, body mass index, and growth charts. (i) Vital signs. Enable a user to electronically record, change, and access, at a minimum, a patient’s height/length, weight, and blood pressure. Height/length, weight, and blood pressure must be recorded in numerical values only. (ii) Calculate body mass index. Automatically calculate and electronically display body mass index based on a patient’s height and weight. (iii) Optional—Plot and display growth charts. Plot and electronically display, upon request, growth charts for patients.
(5)(i)  Objective. Record smoking status for patients 13 years old or older.	(4)(i)  Objective. Record smoking status for patients 13 years old or older.	(a) (11) Smoking status. Enable a user to electronically record, change, and access the smoking status of a patient in accordance with the standard specified at § 170.207(h).	(h) Smoking status. Standard. Smoking status must be coded in one of the following SNOMED CT® codes:   (1) Current every day smoker. 449868002   (2) Current some day smoker. 428041000124106   (3) Former smoker. 8517006   (4) Never smoker. 266919005   (5) Smoker, current status unknown. 77176002   (6) Unknown if ever smoked. 266927001   (7) Heavy tobacco smoker. 428071000124103   (8) Light tobacco smoker. 428061000124105
(6)(i)  Objective. Use clinical decision support to improve performance on high priority health conditions.	(5)(i)  Objective. Use clinical decision support to improve performance on high priority health conditions.	(a) (2) Drug-drug, drug-allergy interaction checks. (i) Interventions. Before a medication order is completed and acted upon during computerized provider order entry (CPOE), interventions must automatically and electronically indicate to a user drug-drug and drug-allergy contraindications based on a patient’s medication list and medication allergy list.   (ii) Adjustments. (A) Enable the severity level of interventions provided for drug-drug interaction checks to be adjusted.   (B) Limit the ability to adjust severity levels to an identified set of users or available as a system administrative function. (a) (8) Clinical decision support. (i) Evidence-based decision support interventions. Enable a limited set of identified users to select (i.e., activate) one or more electronic clinical decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) based on each one and at least one combination of the following data:   (A) Problem list;    (B) Medication list;    (C) Medication allergy list;   (D) Demographics;   (E) Laboratory tests and values/results; and   (F) Vital signs.   (ii) Linked referential clinical decision support. (A) EHR technology must be able to:   (1) Electronically identify for a user diagnostic and therapeutic reference information; or    (2) Electronically identify for a user diagnostic and therapeutic reference information in accordance with the standard specified at § 170.204(b) and the implementation specifications at § 170.204 (b)(1) or (2).   (B) For paragraph (a)(8)(ii)(A) of this section, EHR technology must be able to electronically identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the following data referenced in paragraphs (a)(8)(i)(A) through (F) of this section: (iii) Clinical decision support configuration. (A) Enable interventions and reference resources specified in paragraphs (a)(8)(i) and (ii) of this section to be configured by a limited set of identified users (e.g., system administrator) based on a user’s role.   (B) EHR technology must enable interventions to be electronically triggered:   (1) Based on the data referenced in paragraphs (a)(8)(i)(A) through (F) of this section.   (2) When a patient’s medications, medication allergies, and problems are incorporated from a transition of care/referral summary received pursuant to paragraph (b)(1)(iii) of this section.   (3) Ambulatory setting only.  When a patient’s laboratory tests and values/results are incorporated pursuant to paragraph (b)(5)(i)(A)(1) of this section.   (iv) Automatically and electronically interact. Interventions triggered in accordance with paragraphs (a)(8)(i) through (iii) of this section must automatically and electronically occur when a user is interacting with EHR technology.   (v) Source attributes. Enable a user to review the attributes as indicated for all clinical decision support resources:   (A) For evidence-based decision support interventions under paragraph (a)(8)(i) of this section:   (1) Bibliographic citation of the intervention (clinical research/guideline);   (2) Developer of the intervention (translation from clinical research/guideline);   (3) Funding source of the intervention development technical implementation; and   (4) Release and, if applicable, revision date(s) of the intervention or reference source.   (B) For linked referential clinical decision support in paragraph (a)(8)(ii) of this section and drug-drug, drug-allergy interaction checks in paragraph(a)(2) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline).
(7)(i)  Objective. Incorporate clinical lab test results into Certified EHR Technology as structured data.	(6)(i)  Objective. Incorporate clinical lab test results into Certified EHR Technology as structured data.	(b)(5) Incorporate laboratory tests and values/results. (i) Receive results. (A) Ambulatory setting only. (1) Electronically receive and incorporate clinical laboratory tests and values/results in accordance with the standard specified in § 170.205(j) and, at a minimum, the version of the standard specified in § 170.207(c)(2).   (2) Electronically display the tests and values/results received in human readable format.   (B) Inpatient setting only. Electronically receive clinical laboratory tests and values/results in a structured format and electronically display such tests and values/results in human readable format.   (ii) Electronically display all the information for a test report specified at 42 CFR 493.1291(c)(1) through (7).   (iii) Electronically attribute, associate, or link a laboratory test and value/result with a laboratory order or patient record.	205(j) Electronic incorporation and transmission of lab results. Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, (incorporated by reference in § 170.299). 297(c)(2) Standard. Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.40, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. (incorporated by reference in § 170.299). 42 CFR §493.1291 (c) The test report must indicate the following: (1) For positive patient identification, either the patient's name and identification number, or a unique patient identifier and identification number. (2) The name and address of the laboratory location where the test was performed. (3) The test report date. (4) The test performed. (5) Specimen source, when appropriate. (6) The test result and, if applicable, the units of measurement or interpretation, or both. (7) Any information regarding the condition and disposition of specimens that do not meet the laboratory's criteria for acceptability.
(8)(i)  Objective. Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, or outreach.	(7)(i)  Objective. Generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research or outreach.	(a)(14) Patient list creation. Enable a user to electronically and dynamically select, sort, access, and create patient lists by: date and time; and based on each one and at least one combination of the following data:   (i) Problems;    (ii) Medications;   (iii) Medication allergies;   (iv) Demographics;    (v) Laboratory tests and values/results; and   (vi) Ambulatory setting only. Patient communication preferences.
(9)(i)  Objective. Use clinically relevant information to identify patients who should receive reminders for preventive/follow-up care and send these patients the reminder, per patient preference.		(a)(14) Patient list creation. Enable a user to electronically and dynamically select, sort, access, and create patient lists by: date and time; and based on each one and at least one combination of the following data:   (i) Problems;    (ii) Medications;   (iii) Medication allergies;   (iv) Demographics;    (v) Laboratory tests and values/results; and   (vi) Ambulatory setting only. Patient communication preferences.
(10)(i)  Objective. Provide patients the ability to view online, download, and transmit their health information within 4 business days of the information being available to the EP.	(8)(i)  Objective. Provide patients the ability to view online, download, and transmit information about a hospital admission.	(e) Patient engagement. (1) View, download, and transmit to 3rd party. (i) EHR technology must provide patients (and their authorized representatives) with an online means to view, download, and transmit to a 3rd party the data specified below. Access to these capabilities must be through a secure channel that ensures all content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f).   (A) View. Electronically view in accordance with the standard adopted at § 170.204(a), at a minimum, the following data:   (1) The Common MU Data Set (which should be in their English (i.e., non-coded) representation if they associate with a vocabulary/code set).   (2) Ambulatory setting only. Provider’s name and office contact information.   (3) Inpatient setting only. Admission and discharge dates and locations; discharge instructions; and reason(s) for hospitalization.   (B) Download. (1) Electronically download an ambulatory summary or inpatient summary (as applicable to the EHR technology setting for which certification is requested) in human readable format or formatted according to the standard adopted at § 170.205(a)(3) that includes, at a minimum, the following data (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set):   (i) Ambulatory setting only. All of the data specified in paragraph (e)(1)(i)(A)(1) and   (2) of this section.   (ii) Inpatient setting only. All of the data specified in paragraphs (e)(1)(i)(A)(1) and (3) of this section.   (2) Inpatient setting only. Electronically download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the certification criterion adopted at paragraph (b)(2) of this section).    (C) Transmit to third party. (1) Electronically transmit the ambulatory summary or inpatient summary (as applicable to the EHR technology setting for which certification is requested) created in paragraph (e)(1)(i)(B)(1) of this section in accordance with the standard specified in § 170.202(a).   (2) Inpatient setting only. Electronically transmit transition of care/referral summaries (as a result of a transition of care/referral) selected by the patient (or their authorized representative) in accordance with the standard specified in § 170.202(a).   (ii) Activity history log. (A) When electronic health information is viewed, downloaded, or transmitted to a third-party using the capabilities included in paragraphs (e)(1)(i)(A) through   (C) of this section, the following information must be recorded and made accessible to the patient:   (1) The action(s) (i.e., view, download, transmission) that occurred;   (2) The date and time each action occurred in accordance with the standard specified at § 170.210(g); and   (3) The user who took the action.   (B) EHR technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of this section if it is also certified to the certification criterion adopted at § 170.314(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) is accessible by the patient.	210 (f) Encryption and hashing of electronic health information. Any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the FIPS Publication 140-2 (incorporated by reference in § 170.299). 204(a) Accessibility. Standard. Web Content Accessibility Guidelines (WCAG) 2.0, Level A Conformance (incorporated by reference in § 170.299). 205(a)(3) Standard. HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, (incorporated by reference in § 170.299). The use of the “unstructured document” document-level template is prohibited.  202(a) Standard. ONC Applicability Statement for Secure Health Transport (incorporated by reference in § 170.299). 210(g) Synchronized clocks. The date and time recorded utilize a system clock that has been synchronized following (RFC 1305) Network Time Protocol, (incorporated by reference in § 170.299) or (RFC 5905) Network Time Protocol Version 4, (incorporated by reference in § 170.299).
(11)(i)  Objective. Provide clinical summaries for patients for each office visit.		(e) (2) Ambulatory setting only – clinical summary. (i) Create. Enable a user to create a clinical summary for a patient in human readable format and formatted according to the standards adopted at § 170.205(a)(3).   (ii) Customization. Enable a user to customize the data included in the clinical summary.   (iii) Minimum data from which to select.  EHR technology must permit a user to select, at a minimum, the following data when creating a clinical summary:   (A) Common MU Data Set (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set)   (B) The provider’s name and office contact information; date and location of visit; reason for visit; immunizations and/or medications administered during the visit; diagnostic tests pending; clinical instructions; future appointments; referrals to other providers; future scheduled tests; and recommended patient decision aids.	205(a)(3) Standard. HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, (incorporated by reference in § 170.299). The use of the “unstructured document” document-level template is prohibited.
(12)(i)  Objective. Use clinically relevant information from Certified EHR Technology to identify patient-specific education resources and provide those resources to the patient.	(9)(i)  Objective. Use clinically relevant information from Certified EHR Technology to identify patient-specific education resources and provide those resources to the patient.	(a)(15) Patient-specific education resources. EHR technology must be able to electronically identify for a user patient-specific education resources based on data included in the patient's problem list, medication list, and laboratory tests and values/results:   (i) In accordance with the standard specified at § 170.204(b) and the implementation specifications at § 170.204(b)(1) or (2); and    (ii) By any means other than the method specified in paragraph (a)(15)(i) of this section.	204(b) Reference source. Standard. HL7 Version 3 Standard: Context-Aware Retrieval Application (Infobutton) (incorporated by reference in § 170.299).  (1) Implementation specifications. HL7 Version 3 Implementation Guide: URL-Based Implementations of the Context-Aware Information Retrieval (Infobutton) Domain, (incorporated by reference in § 170.299).   (2) Implementation specifications. HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton) Service-Oriented Architecture Implementation Guide, (incorporated by reference in § 170.299).   (c) Clinical quality measure-by-measure data. Data Element Catalog, (incorporated by reference in § 170.299).
(13)(i)  Objective. The EP who receives a patient from another setting of care or provider of care or believes an encounter is relevant should perform medication reconciliation.	(10)(i)  Objective. The eligible hospital or CAH that receives a patient from another setting of care or provider of care or believes an encounter is relevant should perform medication reconciliation.	(b) Care coordination. (1) Transitions of care – receive, display, and incorporate transition of care/referral summaries. (i) Receive. EHR technology must be able to electronically receive transition of care/referral summaries in accordance with:   (A) The standard specified in § 170.202(a).   (B) Optional. The standards specified in § 170.202(a) and (b).   (C) Optional. The standards specified in § 170.202(b) and (c).   (ii) Display. EHR technology must be able to electronically display in human readable format the data included in transition of care/referral summaries received and formatted according to any of the following standards (and applicable implementation specifications) specified in: § 170.205(a)(1), § 170.205(a)(2), and § 170.205(a)(3). (iii) Incorporate. Upon receipt of a transition of care/referral summary formatted according to the standard adopted at § 170.205(a)(3), EHR technology must be able to:   (A) Correct patient. Demonstrate that the transition of care/referral summary received is or can be properly matched to the correct patient.      (B) Data incorporation. Electronically incorporate the following data expressed according to the specified standard(s):   (1) Medications. At a minimum, the version of the standard specified in § 170.207(d)(2);   (2) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3);   (3) Medication allergies. At a minimum, the version of the standard specified in § 170.207(d)(2).   (C) Section views. Extract and allow for individual display each additional section or sections (and the accompanying document header information) that were included in a transition of care/referral summary received and formatted in accordance with the standard adopted at § 170.205(a)(3). (b)(4) Clinical information reconciliation. Enable a user to electronically reconcile the data that represent a patient’s active medication, problem, and medication allergy list as follows. For each list type:   (i) Electronically and simultaneously display (i.e., in a single view) the data from at least two list sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date.   (ii) Enable a user to create a single reconciled list of medications, medication allergies, or problems.   (iii) Enable a user to review and validate the accuracy of a final set of data and, upon a user’s confirmation, automatically update the list.	§ 170.202 Transport standards. The Secretary adopts the following transport standards:   (a) Standard. ONC Applicability Statement for Secure Health Transport (incorporated by reference in § 170.299).   (b) Standard. ONC XDR and XDM for Direct Messaging Specification (incorporated by reference in § 170.299).   (c) Standard. ONC Transport and Security Specification (incorporated by reference in § 170.299). 205 (a) Patient summary record —(1) Standard. Health Level Seven Clinical Document Architecture (CDA) Release 2, Continuity of Care Document (CCD) (incorporated by reference in §170.299). Implementation specifications. The Healthcare Information Technology Standards Panel (HITSP) Summary Documents Using HL7 CCD Component HITSP/C32 (incorporated by reference in §170.299). (2) Standard. ASTM E2369 Standard Specification for Continuity of Care Record and Adjunct to ASTM E2369 (incorporated by reference in §170.299). (3) Standard. HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, (incorporated by reference in § 170.299). The use of the “unstructured document” document-level template is prohibited.  207(a)(3)Standard. IHTSDO SNOMED CT® International Release July 2012 (incorporated by reference in § 170.299) and US Extension to SNOMED CT® March 2012 Release (incorporated by reference in § 170.299). 207(d) (2) Standard. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, August 6, 2012 Release (incorporated by reference in § 170.299).
(14)(i)  Objective. The EP who transitions their patient to another setting of care or provider of care or refers their patient to another provider of care provides a summary care record for each transition of care or referral.	(11)(i)  Objective. The eligible hospital or CAH that transitions their patient to another setting of care or provider of care or refers their patient to another provider of care provides a summary care record for each transition of care or referral.	(b)(2) Transitions of care – create and transmit transition of care/referral summaries. (i) Create. Enable a user to electronically create a transition of care/referral summary formatted according to the standard adopted at § 170.205(a)(3) that includes, at a minimum, the Common MU Data Set and the following data expressed, where applicable, according to the specified standard(s):   (A) Encounter diagnoses. The standard specified in § 170.207(i) or, at a minimum, the version of the standard specified § 170.207(a)(3);   (B) Immunizations. The standard specified in § 170.207(e)(2);   (C) Cognitive status;   (D) Functional status; and   (E) Ambulatory setting only. The reason for referral; and referring or transitioning provider’s name and office contact information.   (F) Inpatient setting only. Discharge instructions.   (ii) Transmit. Enable a user to electronically transmit the transition of care/referral summary created in paragraph (b)(2)(i) of this section in accordance with:    (A) The standard specified in § 170.202(a).   (B) Optional. The standards specified in § 170.202(a) and (b).   (C) Optional. The standards specified in § 170.202(b) and (c).	207 (i) Encounter diagnoses. Standard. The code set specified at 45 CFR 162.1002(c)(2) for the  indicated conditions. 45 CFR 162.1002(c)(2)  International Classification of Diseases, 10th Revision, Clinical Modification (ICD–10–CM) (including The Official ICD–10–CM Guidelines for Coding and Reporting), as maintained and distributed by HHS, for the following conditions: (i) Diseases. (ii) Injuries. (iii) Impairments. (iv) Other health problems and their manifestations. (v) Causes of injury, disease, impairment, or other health problems. 207(a)(3) Standard. IHTSDO SNOMED CT® International Release July 2012 (incorporated by reference in § 170.299) and US Extension to SNOMED CT® March 2012 Release (incorporated by reference in § 170.299). 207(e)(2) Standard. HL7 Standard Code Set CVX -- Vaccines Administered, updates through July 11, 2012 (incorporated by reference in § 170.299). § 170.202 Transport standards. The Secretary adopts the following transport standards:   (a) Standard. ONC Applicability Statement for Secure Health Transport (incorporated by reference in § 170.299).   (b) Standard. ONC XDR and XDM for Direct Messaging Specification (incorporated by reference in § 170.299).   (c) Standard. ONC Transport and Security Specification (incorporated by reference in § 170.299).
(15)(i)  Objective. Capability to submit electronic data to immunization registries or immunization information systems except where prohibited, and in accordance with applicable law and practice.	(12)(i)  Objective. Capability to submit electronic data to immunization registries or immunization information systems except where prohibited, and in accordance with applicable law and practice.	(f) Public health. (1) Immunization information. Enable a user to electronically record, change, and access immunization information.   (2) Transmission to immunization registries. EHR technology must be able to electronically create immunization information for electronic transmission in accordance with:   (i) The standard and applicable implementation specifications specified in § 170.205(e)(3); and   (ii) At a minimum, the version of the standard specified in § 170.207(e)(2).	205(e)(3)Standard. HL7 2.5.1 (incorporated by reference in § 170.299). Implementation specifications. HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.4, (incorporated by reference in § 170.299). 207(e)(2) Standard. HL7 Standard Code Set CVX -- Vaccines Administered, updates through July 11, 2012 (incorporated by reference in § 170.299).
(16)(i)  Objective. Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities.	(13)(i)  Objective. Capability to submit electronic reportable laboratory results to public health agencies, where except where prohibited, and in accordance with applicable law and practice.	(d) Privacy and security. (1) Authentication, access control, and authorization. (i) Verify against a unique identifier(s) (e.g., username or number) that a person seeking access to electronic health information is the one claimed; and   (ii) Establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided in paragraph (d)(1)(i) of this section, and the actions the user is permitted to perform with the EHR technology. (2) Auditable events and tamper-resistance. (i) Record actions. EHR technology must be able to:   (A) Record actions related to electronic health information in accordance with the standard specified in § 170.210(e)(1);   (B) Record the audit log status (enabled or disabled) in accordance with the standard specified in § 170.210(e)(2) unless it cannot be disabled by any user; and   (C) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by EHR technology in accordance with the standard specified in § 170.210(e)(3) unless the EHR technology prevents electronic health information from being locally stored on end-user devices (see 170.314(d)(7) of this section).   (ii) Default setting. EHR technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraphs (d)(2)(i)(B) or (C), or both paragraphs (d)(2)(i)(B) and (C).   (iii) When disabling the audit log is permitted.  For each capability specified in paragraphs (d)(2)(i)(A) through (C) of this section that EHR technology permits to be disabled, the ability to do so must be restricted to a limited set of identified users.   (iv) Audit log protection. Actions and statuses recorded in accordance with paragraph (d)(2)(i) of this section must not be capable of being changed, overwritten, or deleted by the EHR technology.   (v) Detection. EHR technology must be able to detect whether the audit log has been altered. (3) Audit report(s). Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the data specified in the standards at § 170.210(e).	210(e) Record actions related to electronic health information, audit log status, and encryption of end-user devices. (1)(i) The audit log must record the information specified in sections 7.2 through 7.4, 7.6, and 7.7 of the standard specified at § 170.210(h) when EHR technology is in use. (ii) The date and time must be recorded in accordance with the standard specified at § 170.210(g). (2)(i) The audit log must record the information specified in sections 7.2 and 7.4 of the standard specified at § 170.210(h) when the audit log status is changed.     (ii) The date and time each action occurs in accordance with the standard specified at § 170.210(g).   (3) The audit log must record the information specified in sections 7.2 and 7.4 of the standard specified at § 170.210(h) when the encryption status of electronic health information locally stored by EHR technology on end-user devices is changed. The date and time each action occurs in accordance with the standard specified at § 170.210(g). 210(g) Synchronized clocks. The date and time recorded utilize a system clock that has been synchronized following (RFC 1305) Network Time Protocol, (incorporated by reference in § 170.299) or (RFC 5905) Network Time Protocol Version 4, (incorporated by reference in § 170.299). 210(h) Audit log content. ASTM E2147-01(Reapproved 2009), (incorporated by reference in § 170.299)
(17)(i)  Objective. Use secure electronic messaging to communicate with patients on relevant health information.		(e)(3) Ambulatory setting only—secure messaging. Enable a user to electronically send messages to, and receive messages from, a patient in a manner that ensures:   (i) Both the patient (or authorized representative) and EHR technology user are authenticated; and   (ii) The message content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at § 170.210(f).	210 (f) Encryption and hashing of electronic health information. Any encryption and hashing algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the FIPS Publication 140-2 (incorporated by reference in § 170.299). Essentially TLS with RSA/SHA and Triple-DES or AES Encryption.  Might as well just apply IHE ATNA.
	(14)(i)  Objective. Capability to submit electronic syndromic surveillance data to public health agencies, except where prohibited, and in accordance with applicable law and practice.	(f)(3) Transmission to public health agencies – syndromic surveillance. EHR technology must be able to electronically create syndrome-based public health surveillance information for electronic transmission in accordance with:   (i) Ambulatory setting only. (A) The standard specified in § 170.205(d)(2).   (B) Optional. The standard (and applicable implementation specifications) specified in § 170.205(d)(3).   (ii) Inpatient setting only. The standard (and applicable implementation specifications) specified in § 170.205(d)(3).	205(d)(2) Standard. HL7 2.5.1 (incorporated by reference in §170.299). 205(d)(3) Standard. HL7 2.5.1 (incorporated by reference in § 170.299). Implementation specifications. PHIN Messaging Guide for Syndromic Surveillance (incorporated by reference in § 170.299) and Conformance Clarification for EHR Certification of Electronic Syndromic Surveillance, Addendum to PHIN Messaging Guide for Syndromic Surveillance (incorporated by reference in § 170.299).
	(15)(i)  Objective. Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities.	(a) (12) Image results. Electronically indicate to a user the availability of a patient’s images and narrative interpretations (relating to the radiographic or other diagnostic test(s)) and enable electronic access to such images and narrative interpretations.
	(16)(i)  Objective. Automatically track medications from order to administration using assistive technologies in conjunction with an electronic medication administration record (eMAR).
(k) Stage 2 menu set criteria for EPs.	(m)  Stage 2 menu set criteria for eligible hospitals or CAHs.
	(1)(i)  Objective. Record whether a patient 65 years old or older has an advance directive.	(a)(17) Inpatient setting only—advance directives. Enable a user to electronically record whether a patient has an advance directive.
(1)(i)  Objective. Imaging results consisting of the image itself and any explanation or other accompanying information are accessible through Certified EHR Technology.	(2)(i)  Objective. Imaging results consisting of the image itself and any explanation or other accompanying information are accessible through Certified EHR Technology.	(a)(12) Image results. Electronically indicate to a user the availability of a patient’s images and narrative interpretations (relating to the radiographic or other diagnostic test(s)) and enable electronic access to such images and narrative interpretations.
(2)(i)  Objective. Record patient family health history as structured data.	(3)(i)  Objective. Record patient family health history as structured data.	(a) (13) Family health history. Enable a user to electronically record, change, and access a patient’s family health history according to:   (i) At a minimum, the version of the standard specified in § 170.207(a)(3); or   (ii) The standard specified in § 170.207(j).	207(a)(3) Standard. IHTSDO SNOMED CT® International Release July 2012 (incorporated by reference in § 170.299) and US Extension to SNOMED CT® March 2012 Release (incorporated by reference in § 170.299). 207(j) Family health history. HL7 Version 3 Standard: Clinical Genomics; Pedigree, (incorporated by reference in § 170.299). 207(j) Family health history. HL7 Version 3 Standard: Clinical Genomics; Pedigree, (incorporated by reference in § 170.299).
	(4)(i)  Objective. Generate and transmit permissible discharge prescriptions electronically (eRx).	(a) (10) Drug-formulary checks. EHR technology must automatically and electronically check whether a drug formulary (or preferred drug list) exists for a given patient and medication. (b)(3) Electronic prescribing. Enable a user to electronically create prescriptions and prescription-related information for electronic transmission in accordance with:   (i) The standard specified in § 170.205(b)(2); and   (ii) At a minimum, the version of the standard specified in § 170.207(d)(2).	205(b)(2)Standard. NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 (incorporated by reference in §170.299). 207(d)(2) Standard. RxNorm, a standardized nomenclature for clinical drugs produced by the United States National Library of Medicine, August 6, 2012 Release (incorporated by reference in § 170.299).
(3)(i)  Objective. Capability to submit electronic syndromic surveillance data to public health agencies, except where prohibited, and in accordance with applicable law and practice.		(f)(3) Transmission to public health agencies – syndromic surveillance. EHR technology must be able to electronically create syndrome-based public health surveillance information for electronic transmission in accordance with:   (i) Ambulatory setting only. (A) The standard specified in § 170.205(d)(2).   (B) Optional. The standard (and applicable implementation specifications) specified in § 170.205(d)(3).   (ii) Inpatient setting only. The standard (and applicable implementation specifications) specified in § 170.205(d)(3).	205(d)(2) Standard. HL7 2.5.1 (incorporated by reference in §170.299). 205(d)(3) Standard. HL7 2.5.1 (incorporated by reference in § 170.299). Implementation specifications. PHIN Messaging Guide for Syndromic Surveillance (incorporated by reference in § 170.299) and Conformance Clarification for EHR Certification of Electronic Syndromic Surveillance, Addendum to PHIN Messaging Guide for Syndromic Surveillance (incorporated by reference in § 170.299).
(4)(i)  Objective. Capability to identify and report cancer cases to a public health central cancer registry, except where prohibited, and in accordance with applicable law and practice.		(f)(5) Optional—ambulatory setting only—cancer case information. Enable a user to electronically record, change, and access cancer case information. (f)(6) Optional—ambulatory setting only—transmission to cancer registries. EHR technology must be able to electronically create cancer case information for electronic transmission in accordance with:   (i) The standard (and applicable implementation specifications) specified in § 170.205(i); and   (ii) At a minimum, the versions of the standards specified in § 170.207(a)(3) and (c)(2).	205(i) Cancer information. Standard. HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in § 170.299). Implementation specifications. Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer   Registries, HL7 Clinical Document Architecture (CDA), (incorporated by reference in § 170.299). 207(a)(3) Standard. IHTSDO SNOMED CT® International Release July 2012 (incorporated by reference in § 170.299) and US Extension to SNOMED CT® March 2012 Release (incorporated by reference in § 170.299). 207(j) Family health history. HL7 Version 3 Standard: Clinical Genomics; Pedigree, (incorporated by reference in § 170.299). 207(c)(2) Standard. Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.40, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. (incorporated by reference in § 170.299).
(5)(i)  Objective.  Capability to identify and report specific cases to a specialized registry (other than a cancer registry), except where prohibited, and in accordance with applicable law and practice.
(6)(i)  Objective.  Record electronic notes in patient records.	(5)(i)  Objective. Record electronic notes in patient records.	(a)(9) Electronic notes. Enable a user to electronically record, change, access, and search electronic notes.
	(6)(i)  Objective. Provide structured electronic lab results to ambulatory providers.	(b)(6) Inpatient setting only – transmission of electronic laboratory tests and values/results to ambulatory providers. EHR technology must be able to electronically create laboratory test reports for electronic transmission in accordance with the standard specified in § 170.205(j) and with laboratory tests expressed in accordance with, at a minimum, the version of the standard specified in § 170.207(c)(2).	205(j) Electronic incorporation and transmission of lab results. Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, (incorporated by reference in § 170.299). 207(c)(2) Standard. Logical Observation Identifiers Names and Codes (LOINC®) Database version 2.40, a universal code system for identifying laboratory and clinical observations produced by the Regenstrief Institute, Inc. (incorporated by reference in § 170.299).