Next-generation Interoperability Challenges: Engaging with the IHE Profile Process

I'm giving a presentation this afternoon starting at 2:00 Eastern with that title.  The idea of this presentation is to explain what it takes to engage with IHE to develop a profile.

It's pretty simple actually, and in this 90-minute presentation, we'll actually build a proposal to show you how easy it is. I don't have anything canned for that excercise.  I've done this sort of thing a number of times, and the audience always does a pretty decent job coming up with a proposal.  What is even more fun, is that these proposals often get accepted (often with modifications, but I'll talk about that) in IHE committees.  One time I did this in workshop format, and we wound up getting four submissions.

I'll post the slides and outcomes when after session today.  If you want to sign up, I believe there's still space.

-- Keith

Standards as Innovation

Over on G+, +Margalit Gur-Arie (AKA @margalitgurarie on Twitter) writes on last night's post:

That "lost the distinction between innovation, and standards" is a bit disturbing, don't you think? Particularly when the standards created this way are enforced by governmental regulation before anything was even tried out in practice.

She's got a great point.  The pace of Meaningful Use is frenetic, and the deadlines are insane.  Those deadlines also happen to be law.

But the lost distinction between standards and innovation in healthcare wasn't caused by the HITECH Act.  Instead, it's been something that has been happening since I got my start in standards in the late '90s.

As I think about it:

HTML and XML were standards that were based on technologies that had been proven in the field, prior to being standardized.  XML Schema combines XML and XML Document Type Descriptions in what might perhaps be considered a novel way, but functionally, has all the same capabilities (and just a few more) that DTDs had, but in an XML representation.  The XML and HTML Document Object models standardized what vendors like Netscape and Microsoft had already implemented.  Even CSS harkens back to earlier technology (DSSSL).

In the ideal world with standards, when there are two (or more choices), you should pick the best one, and when there is no "best one", pick one way.  In a a battle between A and B, where there is no clear "best way", C is often better by virtue of the fact that it is new, and everybody will be equally disadvantaged.  Back in the era of the Browser wars, you'd often have two 800-lb Gorilla's having a dominance battle in a room full of Marmosets.  So, the marmosets introduce something new, and the problem is solved.


The pace accelerates.  Real years become Internet Years, and the need for innovation just to survive in this electronic world becomes a necessity.  And one shortcut becomes to make new innovations, the new standards, maybe even before they are ready.  Novelty becomes a way of solving these problems in standards, and avoiding giving away an advantage to one side or another.  This may in fact be one of the reasons why the LRI project developed something new, rather than picking between the existing choices.

On that front, LRI is new. But we've already had a few years experience doing very similar things with the two competing standards.  So, really, it isn't all that new.  It is pretty untested.  But what we do know is that industry is capable of doing it, because they've already done in twice in different but very similar ways.

You also run into situations like HL7 Version 2 experienced.  The standard, over time, got crufty.  There was a need to do something new.  But, because it was a standard, nobody wanted to innovate on their own. So V3 was born.  And because nobody was innovating on their own to help develop a body of experience in which we could base the standards, HL7 introduced quite a number of innovations of its own.

Of course, there were other innovative standards (OpenEHR), but then we get back to the Gorilla problem.  It's taken a while for option C to show up in that long-standing battle, but I think CIMI shows some promise.

Innovation in standards development has become a way of life.  But Margalit is right, what we need to do is ensure that these innovations are tested before they are deployed.  I was very encouraged by the completeness of the development framework that ONC created for the S&I Framework project.  It includes reference implementations and pilots.  I've never been pleased with the schedule.  We all know how rushing to hit a deadline affects quality.  Unfortunately, on the schedule, neither ONC nor CMS are in the driver's seat.  Congress was, and they put those deadlines in the HITECH Act.

It's up to us to meet them.  How do we do that?

There are parallel paths.  Tactics and Strategy.  Short term, and long-term goals.  Don't confuse your strategy for your tactics.  PCAST as short-term tactics sucked.  As a long-term strategy, it's got a couple of good ideas (and some bad ones).  S&I Framework is tactical.  It's about how to get something going quickly with the people and resources that we have on the ground today.

Forwards on ABBI

In this, I'm going to respond to some comments by Alan Viars on use of CCDA in the ABBI Project:

HL7 is fine for HIE, provider-to-provider, and provider-to-payer communication. For Blue Button however, the goal is to break from business as usual.

I was there when ABBI was first brainstormed, I get the vision.  If we really want to talk about breaking from business as usual, well, that's a whole 'nother post.  ABBI is very much like any other S&I Framework project in the last two years.

It seems that his main concern you have is that CCDA is hard for patients (and developers) to manage or deal with.  I won't even argue that point.  FHIR would be much easier.  The reality for me, is that my doctor today, could produce a CCD, and will in the very near future, be able to produce a CCDA, and I even have an App on my iPhone that understands CCD today enough to produce it.  I want it to be able to consume it, and I think they could do it.  And I know HealthVault can deal, and so can others.  There are at least three pieces of open source software available to you today to parse a CCD, and at least one supporting CCDA. There's even a stack you can use to get the content from CCD into JSON.  And all of that is freely available and unencumbered by HL7 licenses.

I understand the intent of the ABBI project is aimed at being something new and something very simple for people to manage their own data. I'm not sure what the answer is just yet, but I'm not of the option that CCDA is a good starting point. I say that because it is a overly-complex, closed standard and is the intellectual property of HL7. Its specification is not in the public domain.

Very few standards are in the public domain, and there are good reasons for organizations who publish them to maintain copyright.  We talked about overly complex, and I agree with that point.  Closed vs. Open is a struggle with definitions.  I think he means open as free of cost and redistributable to others, as he describes below:

I'd define an "open data standard" with the following meaning:
The standard is in the public domain. The specification, in its entirety, is free and public. There is no license or restriction to redistribute the standard's text in whole or in part. Any related schema, such as an XSD, is also open in the same way.

That's not the same thing as open in my book.  Open has to do with access.  Access to the standard is one part of this, but another part is access to governance over it (e.g., voting).  But if you don't assert copyright, you've lost a key tool in governance.  But he may mean public domain in the full sense, which implies that there is no governance over the standard.  If so, we'll have to agree to disagree.

Somewhere along the way, HL7 and many other organizations have lost the distinction between innovation, and standards, and so now we use standards to innovate.  It's kind of funny, because the whole point of standards is to pick one way to do things that everyone does, and has already figured out, and innovation is about picking the best way that nobody else has figured out yet.  But, I diverge.

Nothing wrong with clubs with memberships. I used to have a gym membership. But some people want to go just go to the park instead. It wouldn't be very nice if the people from the gym all got together and tried to prevent folks from opening a park as an alternative. That's kind of what it sounds like when we are at the beginning of a new effort and the tone is "it must be CCDA and DIRECT". 

Battles over content are a HUGE distraction from the real need for ABBI.  Give me My DAMN Data. You can use a CCR, but I'd prefer a CCD.  I wrote that song at the point in time when CCR and CCD were the two options.  I want what providers can give me, with as little work as possible.  That's a CCR or CCD (in fact, both are CCRs), and in the near future that's going to be CCDA.  And hopefully after that, something like FHIR will be available.

One of the missing content pieces that is still important to discuss, is the fact that we don't have financial data accessible in the same way.  I want an EOB statement that can be parsed by an App.  I could actually care less now, but later, well, after a few million of these are available to patients, we can surely do something about the pricing transparency issue.  We don't have ANY content standards for that.

I can see how open source standards groups can work with memberships, but their work products should be open using the definition I gave above. HL7 does not meet the definition. If HTTP was like Hl7, I'd have to join and pay a bunch of money just to know that 404 means "not found" and 200 means "OK". I'd agree W3C and OASIS might not be good models either. I'd offer GeoJSON, as a good example.

I think we agree in principle in this.  We'd all like HL7 to make their IP free.  Open Source isn't an option for their business model.  That's an over beer discussion, but the short version is that open source works for one, but not for many, and HL7 has (Too) MANY standards.

I do not work for a company with HL7-based solutions. My vested interest and/or personal mission is to lower the bar for developers, reduce complexity, and increase market competition. I believe this is the best thing for me and my family as a patient and for the American taxpayer.

For this, I need to ask what else other than IP makes people avoid collaborating with, and helping to fix what is wrong in HL7?  If IP weren't an issue, would you work with someone like Grahame Grieve to help HL7 reduce its own complexity?  Or is it simple a need to compete with HL7?  I've been down both roads with SDOs, and I can tell you that I'd rather work with than against them when I can.

I've already shared my deepest, most personal and most selfish motive with Alan, here it is for the rest of you:

My doctor has a system that can produce a CCD today.  In a year or so, he'll have a system that can produce CCDA.  And it will be able to send it out via Direct, and through the NwHIN Exchange.  I want that data.  Personally. On my own computer.  Updated automatically after every visit.

If we don't use the standards that are mandated now, who will connect me to my doctor using those standards, and what will incent my doctor to use that technology?  That is what ABBI is supposed to about, connecting us to our data.  It's what I want for me and for my kids.  If it was CCR that he was going to have, and not CCDA, then I'd be a little bit upset about the standard being used, but still calling for it.  I'm not a Direct fan-boy by any stretch of the imagination.  But you better believe that if ABBI PUSH doesn't support Direct, I'm going to be hugely upset.  If ABBI doesn't support CCDA, I'm also going to be hugely upset.  Why?  Because doctors will have Direct, and ABBI should make it possible for Doctors to cc: me using it, with very little in-between.  Maybe even nothing.  Wouldn't that be awesome?

I sincerely believe we are on to something with this project.  I think content is mostly a distraction right now.  ABBI should support ANY content Alan, Grahame, myself, or anyone else can dream up.  All we should have to do, ever, is just Ask for it.

-- Keith

P.S. If you liked the short video in that last link the director's cut is a three minute ad for ABBI

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).