May 29, Submitted electronically via

Transcription

1 May 29, 2015 Karen DeSalvo, MD, MPH, MSc Department of Health and Human Services Office of the National Coordinator for Health IT Hubert H. Humphrey Building Suite 729D 200 Independence Ave SW Washington, DC Submitted electronically via Re: 0991-AB93; Proposed 2015 Edition Electronic Health Record (EHR) Certification Criteria, 2015 Edition Base EHR Definition, and ONC Health IT Certification Program Modifications Dear Dr. DeSalvo, athenahealth, Inc. ( athenahealth ) appreciates the opportunity to provide comments on the Proposed 2015 Edition Electronic Health Record (EHR) Certification Criteria, 2015 Edition Base EHR Definition, and ONC Health IT Certification Program Modifications Proposed Rule ( Proposed Rule ). As you know athenahealth provides electronic health record ( EHR ), practice management, care coordination, patient communication, data analytics, and related services to physician practices, working with a network of more than 60,000 healthcare professionals who serve over 60 million patients in all 50 states. We envision and work to establish a nationwide health information backbone that makes healthcare work as it should by connecting patients and care providers with the information they need to seek and provide high-quality, cost-effective, efficient care. All of our providers access our services on the same instance of continuously-updated, cloud-based software. Our clients successes, exemplified by a Meaningful Use ( MU ) attestation rate more than double the national average, underscore the very real potential of health IT to improve care delivery and patient outcomes while increasing efficiency and reducing systemic costs. General Remarks We have significant concerns about the Proposed Rule. Our specific suggestions and criticisms are set forth in detail below, but many of our observations can be boiled down thematically to the refrain that has been heard from across the stakeholder spectrum as the MU program has progressed slowly through its stages: As it has evolved from the initial, paradigm-shifting adoption of digital technologies that it created initially into progressively more granular and bureaucratic stages of implementation, the program has failed to produce truly meaningful improvements in patient care. Although we have enabled our clients to succeed at the MU game to a degree far beyond the industry norm, those same clients routinely report that the requirements of the program have turned them into professional boxcheckers, distracted from patient care by MU requirements that improve neither care nor efficiency and too often adversely impact both. As you know, we have in the past vociferously disagreed with Page 1 of 53

2 others in our industry as they called for slower implementation timelines and lower performance bars. We continue to oppose such efforts and believe that federal policy should force vendors and providers to reach higher but in ways that leverage modern information technology to measurably improve patient care. We agree with much of our industry, however, on the assertion that the MU program forces our developers to devote a disproportionate share of time and resources to compliance with the ONC Health IT Certification Program rather than development to meet client requests and improve patient care. The Center for Medicare and Medicaid Services ( CMS ) made progress towards addressing those criticisms in its Electronic Health Record Incentive Program Stage 3 Proposed Rule. The result was a simplified proposed rule that will enable providers and their vendors to focus resources on a few key areas of CEHRT use that will have the greatest benefit to patient care. We urge the Office of the National Coordinator for Health IT ( ONC ) to follow suit. Certification criteria that are not linked to an MU measure should not be included in the final Rule. ONC s role should be to designate the functionality that CEHRT must have to enable a provider to meet the requirements of the MU program. Respectfully, ONC should not be in the business of designing an EHR through regulation. We suggest that ONC focus its attention on the certification criteria that are needed to promote interoperable exchange of health information and meaningful use of CEHRT, as defined by CMS. Functionality that is not explicitly tied to either of those objectives should be left to EHR vendors to retain and/or develop based on the needs of and in consultation with their provider customers. We appreciate that ONC attempted to align with CMS in incorporating greater flexibility in the Proposed Rule. A less prescriptive Certification Program one that focuses on outcomes and lets the market determine means will foster greater innovation in health IT. ONC has done a wonderful job over the years in partnering with and listening to stakeholders. We hope that the agency returns to that approach to produce a more focused final Rule. Vendor and provider resources are limited; certification criteria should promote high-priority areas that will transform the MU program into a foundational element for the successful reform of our healthcare system. Specific Comments With the above context in mind, we provide the following specific comments on the proposed Stage 3 certification criteria: Page 2 of 53

3 A. Provisions of the Proposed Rule affecting Standards, Implementation Specifications, Certification Criteria, and Definitions (a)(1) Computerized provider order entry medications Yes, as an alternative to (a)(2) or (3) Use computerized provider order entry (CPOE) for medication, laboratory, and diagnostic imaging orders directly entered by any licensed healthcare professional, credentialed medical assistant, or a medical staff member credentialed to and performing the equivalent duties of a credentialed medical assistant; who can enter orders into the medical record per state, local, and professional guidelines. (1) Computerized provider order entry medications. Technology must enable a user to record, change, and access medication orders. Preamble FR Citation: 80 FR We the support the retention of this criterion, and the intention of leaving it unchanged from the previous edition (a)(2) Computerized provider order entry laboratory Yes, as an alternative to (a)(1) or (3) Use computerized provider order entry (CPOE) for medication, laboratory, and diagnostic imaging orders directly entered by any licensed healthcare professional, credentialed medical assistant, or a medical staff member credentialed to and performing the equivalent duties of a credentialed medical assistant; who can enter orders into the medical record per state, local, and professional guidelines. (2) Computerized provider order entry laboratory. (i) Technology must enable a user to record, change, and access laboratory orders. (ii) Technology must be able to receive and incorporate a new or updated laboratory order compendium in accordance with the standard specified in (l)(2) and, at a minimum, the version of the standard in (c)(3). (iii) Ambulatory setting only. Technology must enable a user to create laboratory orders for electronic transmission in accordance with the standard specified in (l)(1) and, at a minimum, the version of the standard in (c)(3). Preamble FR Citation: 80 FR Page 3 of 53

4 (a)(2) Computerized provider order entry laboratory Although we believe the longer term adoption of the S&I Framework Laboratory Orders (LOI) Release 2 is a positive step for the industry, we have concerns over requiring this standard in its current state. Release 1 has now been out for two years though no one other than the pilot program uses it. The proposed rule would mandate the use of Release 2 of LOI specification that has not come out yet and may not be market-ready for industry-wide adoption. We agree with the direction of using standards-based data exchange across the industry, but we caution ONC about its implementation where EHRs are held to the official standard but that official standard is not enforced on other side of the transaction (as was the case with the NCPDP standard for electronic prescribing) which resulted in EHRs having to build separate copy of the standard for the purposes of certification only. Consistency across the industry is paramount for true interoperation (a)(3) Computerized provider order entry diagnostic imaging Yes, as an alternative to (a)(1) or (2) Use computerized provider order entry (CPOE) for medication, laboratory, and diagnostic imaging orders directly entered by any licensed healthcare professional, credentialed medical assistant, or a medical staff member credentialed to and performing the equivalent duties of a credentialed medical assistant; who can enter orders into the medical record per state, local, and professional guidelines. (3) Computerized provider order entry diagnostic imaging. Technology must enable a user to record, change, and access diagnostic imaging orders. Preamble FR Citation: 80 FR (also see 80 FR 16814) We support the retention of this criterion, as well as the intention of leaving it unchanged from the previous edition (a)(4) Drug-drug, drug-allergy interaction checks for CPOE Implement clinical decision support (CDS) interventions focused on improving performance on high-priority health conditions. Page 4 of 53

5 (a)(4) Drug-drug, drug-allergy interaction checks for CPOE (4) Drug-drug, drug-allergy interaction checks for CPOE. (i) Interventions. Before a medication order is completed and acted upon during computerized provider order entry (CPOE), interventions must automatically 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. (iii) Interaction check response documentation. (A) Technology must be able to record at least one action taken and by whom in response to drug-drug or drugallergy interaction checks. (B) Technology must be able to generate either a human readable display or human readable report of actions taken and by whom in response to drug-drug or drug-allergy interaction checks. Preamble FR Citation: 80 FR The drug-drug, drug-allergy interaction checks for CPOE are simultaneously overly-prescriptive and not well-defined. We recommend the following changes to avoid unnecessary burden on providers and lack of clarity in the regulations. (1) While it is clear that these interaction checks should be fired during CPOE, we caution against trying to be overly prescriptive in the workflow by requiring extra clicks solely for the purposes of audit tracking. The categories declined, ignored and overrode mean the same thing when trying to capture the user s action. It is important to simplify these areas, especially when an EHR is incapable of making a distinction and would have to revert to requiring clinicians to interrupt their workflow to record these distinctions. We are not concerned with the burden to develop this functionality, but are concerned with burden placed on clinical users which does not benefit patient care and only helps in the auditing process. (2) In recording user actions for drug-drug, drug-allergy interactions, we suggest limiting this to severe interactions as it will otherwise impact the user experience and contribute to alert fatigue. It is important to note that many EHRs will be dependent on drug database vendors to provide the severity of a particular interaction. Severe should also be the only category that is auditable. (3) If any comment field is added, we suggest making it optional as in most EHRs there is already another field used for this purpose. Making this field optional would allow providers to avoid extra work that does not benefit patient care, but only helps in the auditing process. (4) The proposed rule also solicited feedback on whether an EHR should be able to track when an adverse event occurs. Often there is no way for the EHR to capture this as adverse events frequently occur outside of the patient-provider experience in the ambulatory setting (a)(5) Demographics Yes Page 5 of 53

6 (a)(5) Demographics (5) Demographics. (i) Enable a user to record, change, and access patient demographic data including preferred language, sex, race, ethnicity, and date of birth. (A) Race and ethnicity. (1) Enable each one of a patient s races to be recorded in accordance with, at a minimum, the standard specified in (f)(2) and whether a patient declines to specify race. (2) Enable each one of a patient s ethnicities to be recorded in accordance with, at a minimum, the standard specified in (f)(2) and whether a patient declines to specify ethnicity. (3) Aggregate each one of the patient s races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(a)(1) and (2) of this section to the categories in the standard specified in (f)(1). (B) Enable preferred language to be recorded in accordance with the standard specified in (g)(2) and whether a patient declines to specify a preferred language. (C) Enable sex to be recorded in accordance with the standard specified in (n)(1). (ii) Inpatient setting only. Enable a user to record, change, and access the preliminary cause of death and date of death in the event of a mortality. Preamble FR Citation: 80 FR We support the changes in demographics criteria though we caution against changing preferred language standards again and remind ONC that each change in a standard requires a significant time and infrastructure investment as well as data backfills to meet the new standard. We request that the value in changing such categories always be weighed against the time and infrastructure investments expended in updating them (a)(6) Vital signs, body mass index, and growth charts Page 6 of 53

7 (a)(6) Vital signs, body mass index, and growth charts (6) Vital signs, body mass index, and growth charts. (i) Vital signs. Enable a user to record, change, and access, at a minimum, a patient's height, weight, diastolic blood pressure, systolic blood pressure, heart rate, respiratory rate, temperature, oxygen saturation in arterial blood by pulse oximetry, body mass index [ratio], and mean blood pressure in accordance with the following (The patient s height/length, weight, diastolic blood pressure, systolic blood pressure, heart rate, respiratory rate, temperature, oxygen saturation in arterial blood by pulse oximetry, body mass index [ratio], and mean blood pressure must be recorded in numerical values only.): (A) The standard specified in (k)(1) and with the associated applicable unit of measure for the vital sign in the standard specified in (m)(1); (B) Metadata. For each vital sign in paragraph (a)(6)(i) of this section, the technology must also record the following: (1) Date and time of vital sign measurement or end time of vital sign measurement; (2) The measuring- or authoring-type source of the vital sign measurement; and (3) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in (g); and (C) Metadata for oxygen saturation in arterial blood by pulse oximetry. For the oxygen saturation in arterial blood by pulse oximetry, the technology must enable a user to record, change, and access the patient s inhaled oxygen concentration identified, at a minimum, with the version of the standard adopt in (c)(3) and attributed with LOINC code Page 7 of 53

8 (a)(6) Vital signs, body mass index, and growth charts, (a)(6) Vital signs, body mass index, and growth charts, continued (ii) Optional Body mass index percentile per age and sex. Enable a user to record, change, and access a patient s body mass index [percentile] per age and sex for patients two to twenty years of age in accordance with the following (The patient s body mass index [percentile] per age and sex must be recorded in numerical values only.): (A) Identified, at a minimum, with the version of the standard adopt in (c)(3) and attributed with LOINC code and with the associated applicable unit of measure in the standard specified in (m)(1); and (B) Metadata. The technology must also record the following: (1) Date and time of vital sign measurement or end time of vital sign measurement; (2) The measuring or authoring-type source of the vital sign measurement; (3) The patient s date of birth; (4) The patient s sex in accordance with the standard specified in (n)(1); and (5) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in (g). (iii) Optional Weight for length per age and sex. Enable a user to record, change, and access a patient s weight for length per age and sex for patients less than three years of age in accordance with the following (The patient s weight for length per age and sex must be recorded in numerical values only.): (A) Identified, at a minimum, with the version of the standard adopt in (c)(3) and attributed with the LOINC code and with the associated applicable unit of measure in the standard specified in (m)(1); and (B) Metadata. The technology must record the following: (1) Date and time of vital sign measurement or end time of vital sign measurement; (2) The measuring- or authoring-type source of the vital sign measurement; (3) The patient s date of birth; (4) The patient s sex in accordance with the standard specified in (n)(1); and (5) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in (g). (iv) Optional Head occipital-frontal circumference. Enable a user to record, change, and access a patient s head occipital-frontal circumference for patients less than three years of age in accordance with the following (The patient s head occipital-frontal circumference must be recorded in numerical values only.): (A) Identified, at a minimum, with the version of the standard adopt in (c)(3) and attributed with LOINC code and with the associated applicable unit of measure in the standard specified in (m)(1); and (B) Metadata. The technology must also record the following: (1) Date and time of vital sign measurement or end time of vital sign measurement; (2) The measuring or authoring-type source of the vital sign measurement; (3) The patient s date of birth; (4) The patient s age in accordance with the standard specified in (n)(1); and (5) Optional. Date and time of vital sign measurement or end time of vital sign measurement in accordance with the standard in (g). (v) Optional Calculate body mass index. Automatically calculate and display body mass index based on a patient's height and weight. (vi) Optional Plot and display growth charts. Plot and display, upon request, growth charts for patients. Preamble FR Citation: 80 FR Page 8 of 53

9 (a)(6) Vital signs, body mass index, and growth charts We support the uniform standard for entering and exchanging LOINC values and accompanying metadata, but we recommend that ONC not dictate how health IT platforms store the data. We also support the criterion on vitals in UCUM measure conversion, but again reiterate that health IT platforms should be able to store the data in their own way while still meeting these standards for the purposes of data exchange (a)(7) Problem list Yes (7) Problem list. Enable a user to record, change, and access a patient's active problem list: (i) Ambulatory setting. Over multiple encounters in accordance with, at a minimum, the version of the standard specified in (a)(4); or (ii) Inpatient setting. For the duration of an entire hospitalization in accordance with, at a minimum, the version of the standard specified in (a)(4). Preamble FR Citation: 80 FR We support the retention of this criterion, as well as the intention of leaving it unchanged from the previous edition (a)(8) Medication list Yes (8) Medication list. Enable a user to record, change, and access a patient's active medication list as well as medication history: (i) Ambulatory setting. Over multiple encounters; or (ii) Inpatient setting. For the duration of an entire hospitalization. Preamble FR Citation: 80 FR We support the retention of this criterion, as well as the intention of leaving it unchanged from the previous edition (a)(9) Medication allergy list Yes Page 9 of 53

10 (a)(9) Medication allergy list (9) Medication allergy list. Enable a user to record, change, and access a patient's active medication allergy list as well as medication allergy history: (i) Ambulatory setting. Over multiple encounters; or (ii) Inpatient setting. For the duration of an entire hospitalization. Preamble FR Citation: 80 FR We support the retention of this criterion, as well as the intention of leaving it unchanged from the previous edition (a)(10) Clinical decision support Yes Implement clinical decision support (CDS) interventions focused on improving performance on high-priority health conditions. Page 10 of 53

11 (a)(10) Clinical decision support (10) 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) At least one demographic specified in paragraph (a)(5)(i) of this section; (E) Laboratory tests; and (F) Vital signs. (ii) Linked referential clinical decision support. (A) Technology must be able to identify for a user diagnostic and therapeutic reference information in accordance with the standard and implementation specifications at (b)(3) or (4). (B) For paragraph (a)(10)(ii)(a) of this section, technology must be able to identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the data referenced in paragraphs (a)(10)(i)(a), (B), and (D) of this section. (iii) Clinical decision support configuration. (A) Enable interventions and reference resources specified in paragraphs (a)(10)(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) Technology must enable interventions to be: (1) Based on the data referenced in paragraphs (a)(10)(i)(a) through (F) of this section. (2) When a patient's medications, medication allergies, problems, and laboratory tests and values/results are incorporated from a transition of care/referral summary received and pursuant to paragraph (b)(2)(iii)(d) of this section. (3) Ambulatory setting only. When a patient's laboratory tests and values/results are incorporated pursuant to paragraph (b)(4) of this section. (iv) CDS intervention interaction. Interventions provided to a user in paragraphs (a)(10)(i) through (iii) of this section must occur when a user is interacting with 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)(10)(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)(10)(ii) of this section and drug-drug, drugallergy interaction checks in paragraph (a)(4) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline). (vi) Intervention response documentation. (A) Technology must be able to record at least one action taken and by whom in response to clinical decision support interventions. (B) Technology must be able to generate either a human readable display or human readable report of actions taken and by whom in response to clinical decision support interventions. Preamble FR Citation: 80 FR Page 11 of 53

12 (a)(10) Clinical decision support We applaud ONC s efforts to promote evidence-based clinical guidance. Though as with many of our comments, we want to ensure flexibility in the regulations to achieve the stated aims of the criterion. We recommend that health IT platforms be permitted to use tools other than Infobutton as different CDS may accomplish the same goals. For example, we already have integrations with other CDS through FHIR and don't want to be constrained by Infobutton (a)(11) Drug-formulary and preferred drug list checks EPs must generate and transmit permissible prescriptions electronically, and eligible hospitals and CAHs must generate and transmit permissible discharge prescriptions electronically (erx). (11) Drug-formulary and preferred drug list checks. Technology must either meet paragraph (a)(11)(i) or (ii) of this section. (i) Drug formulary checks. (A) Automatically check whether a drug formulary exists for a given patient and medication. (B) Indicate for a user the last update of the drug formulary; and (C) Receive and incorporate a formulary and benefit file in accordance with the standard specified in (n)(1). (ii) Preferred drug list checks. (A) Automatically check whether a preferred drug list exists for a given patient and medication. (B) Indicate for a user the last update of the preferred drug list. Preamble FR Citation: 80 FR We support the required use of NCPDP Formulary and Benefit Standard v3.0 but agree that version 4.0 is still too unstable We also recommend use of the NCPDP TELECOM standard which allows us to do a patient level formulary checking. This would be a new standard for CPOE, but it is a well-established standard in the pharmacy world (a)(12) Smoking status Yes (12) Smoking status. Enable a user to record, change, and access the smoking status of a patient in accordance with, at a minimum, the version of the standard specified in (a)(4). Preamble FR Citation: 80 FR We support the retention of this criterion, as well as the intention of leaving it unchanged from the previous edition Page 12 of 53

13 (a)(13) Image results (13) Image results. 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. Preamble FR Citation: 80 FR We support the retention of this criterion, as well as the intention of leaving it unchanged from the previous edition (a)(14) Family health history, but proposed for the EHR Incentive Programs CEHRT definition (14) Family health history. Enable a user to record, change, and access a patient's family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the standard in (a)(4). Preamble FR Citation: 80 FR We urge ONC to continue to use the SNOMED standard for both criteria without mandating a transition to HL7 Pedigree for the creation and incorporation of a patient s family health history as the transitional costs would not outweigh the value in care quality (a)(15) Family health history pedigree, but proposed for the EHR Incentive Programs CEHRT definition as an alternative to (a)(14). (15) Family health history pedigree. Technology must be able to create and incorporate a patient's family health history in accordance with the standard and implementation specification specified in (m)(1). Preamble FR Citation: 80 FR We reiterate our comments from the previous section (a)(14) Family health history (a)(16) Patient list creation Page 13 of 53

14 (a)(16) Patient list creation (16) Patient list creation. Enable a user to 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) At least one demographic specified in paragraph (a)(5)(i) of this section; (v) Laboratory tests and values/results; and (vi) Ambulatory setting only. Patient communication preferences. Preamble FR Citation: 80 FR We support the retention of this criterion, as well as the intention of leaving it unchanged from the previous edition (a)(17) Patient-specific education resources The EP, eligible hospital, or CAH provides access for patients to view online, download, and transmit their health information, or retrieve their health information through an API, within 24 hours of its availability. (17) Patient-specific education resources. Technology must be able to: (i) Identify patient-specific education resources based on data included in the patient's problem list and medication list in accordance with the standard (and implementation specifications) specified in (b)(3) or (4); and (ii) Request that patient-specific education resources be identified in accordance with the standard in (g)(2). Preamble FR Citation: 80 FR Although the InfoButton is a tremendous tool for patient-specific education resources, EHRs have included patient education for quite some time. We and other vendors have designed user-friendly and effective workflows for our providers to provide education. Mandating this standard will only cause confusion and challenges for the provider. We support displaying information for the patient using InfoButton, but requiring only InfoButton for a provider to satisfy meaningful use is overly prescriptive without a benefit to care. Furthermore, if we were to implement this requirement, InfoButton only lets someone see information. There is no way to convert this information into a format that we can present to a patient on the portal. Page 14 of 53

15 (a)(18) Electronic medication administration record (18) Electronic medication administration record. (i) In combination with an assistive technology that provides automated information on the rights specified in paragraphs (a)(18)(i)(a) through (E) of this section, enable a user to verify the following before administering medication(s): (A) Right patient. The patient to whom the medication is to be administered matches the medication to be administered. (B) Right medication. The medication to be administered matches the medication ordered for the patient. (C) Right dose. The dose of the medication to be administered matches the dose of the medication ordered for the patient. (D) Right route. The route of medication delivery matches the route specified in the medication order. (E) Right time. The time that the medication was ordered to be administered compared to the current time. (ii) Right documentation. Record the time and date in accordance with the standard specified in (g), and user identification when a medication is administered. Preamble FR Citation: 80 FR We support the retention of this criterion, as well as the intention of leaving it unchanged from the previous edition (a)(19) Patient health information capture, but proposed for the EHR Incentive Programs CEHRT definition Use communications functions of certified EHR technology to engage with patients or their authorized representatives about the patient's care. (19) Patient health information capture. Technology must be able to enable a user to: (i) Identify, record, and access patient health information documents; (ii) Reference and link to patient health information documents; and (iii) Record and access information directly shared by a patient. Preamble FR Citation: 80 FR We support the new proposed criterion for patient health information capture via safe formats (e.g., pdf) (a)(20) Implantable device list Yes Page 15 of 53

16 (a)(20) Implantable device list (20) Implantable device list. (i) Enable a user to record, change, and access, a list of Unique Device Identifiers associated with a patient s Implantable Device(s). (ii) Parse the following data elements from a Unique Device Identifier: (A) Device Identifier; (B) Batch/lot number; (C) Expiration date; (D) Production date; and (E) Serial number. (iii) Retrieve the Device Description attribute associated with a Unique Device Identifier in the Global Unique Device Identification Database. (iv) For each Unique Device Identifier in a patient s list of implantable devices, enable a user to access the following: (A) The parsed data elements specified under paragraph (a)(20)(ii) of this section that are associated with the UDI; and (B) The retrieved data element specified under paragraph (a)(20)(iii) of this section. Preamble FR Citation: 80 FR We support the new proposed criterion for an implantable device list (a)(21) Social, psychological, and behavioral data Page 16 of 53

17 (a)(21) Social, psychological, and behavioral data (21) Social, psychological, and behavioral data. Enable a user to record, change, and access, at a minimum, one of the following patient social, psychological, and behavioral data. (i) Sexual orientation. Enable sexual orientation to be recorded in accordance with the standard specified in (o)(1) and whether a patient declines to specify sexual orientation. (ii) Gender identity. Enable gender identity to be recorded in accordance with the standard specified in (o)(2) and whether a patient declines to specify gender identity. (iii) Financial resource strain. Enable financial resource strain to be recorded in accordance with the standard specified in (o)(3) and whether a patient declines to specify financial resource strain. (iv) Education. Enable education to be recorded in accordance with the standard specified in (o)(4) and whether a patient declines to specify education. (v) Stress. Enable stress to be recorded in accordance with the standard specified in (o)(5) and whether a patient declines to specify stress. (vi) Depression. Enable depression to be recorded in accordance with the standard specified in (o)(6) and whether a patient declines to specify stress. (vii) Physical activity. Enable physical activity to be recorded in accordance with the standard specified in (o)(7) and whether a patient declines to specify physical activity. (viii) Alcohol use. Enable alcohol use to be recorded in accordance with the standard specified in (o)(8) and whether a patient declines to specify alcohol use. (ix) Social connection and isolation. Enable social connection and isolation to be recorded in accordance the standard specified in (o)(9) and whether a patient declines to specify social connection and isolation. (x) Exposure to violence (intimate partner violence). Enable exposure to violence (intimate partner violence) to be recorded in accordance with the standard specified in (o)(10) and whether a patient declines to specify exposure to violence (intimate partner violence). Preamble FR Citation: 80 FR 16826, and also see requests for comment on work information (industry/occupation) data and U.S.uniformed/military service data We support the new criteria for social, psychological and behavioral data on sexual orientation and gender identity. However, we recommend that ONC not mandate changes for work information, industry and occupational data as the value of this information will be limited and only adds administrative work for the providers to collect research data points that, while interesting, do not benefit care quality (a)(22) Decision support knowledge artifact (22) Decision support knowledge artifact. Enable a user to send and receive clinical decision support knowledge artifacts in accordance with the standard specified in (d)(1). Preamble FR Citation: 80 FR Page 17 of 53

18 (a)(22) Decision support knowledge artifact We are concerned with the requirement to use one standard for the sending and receiving of clinical decision support knowledge artifacts as this mandate limits flexibility to achieve the end goal without a clear purpose (a)(23) Decision support service (23) Decision support service. Enable a user to send and receive electronic clinical guidance in accordance with the standard specified in (e)(1). Preamble FR Citation: 80 FR Although the HeD standard would enable tremendous sending and extracting of data across platforms, this task creates considerable work. Unless CDS vendors are building this functionality now, we recommend that EHR vendors not be required to build this simply to achieve certification. This measure should focus on supporting the use of CDS, not the specific transmission transaction (b)(1) Transitions of care Yes The EP, eligible hospital, or CAH provides a summary of care record when transitioning or referring their patient to another setting of care, retrieves a summary of care record upon the first patient encounter with a new patient, and incorporates summary of care information from other providers into their EHR using the functions of certified EHR technology. (1) Transitions of care. (i) Send and receive via edge protocol. Technology must be able to: (A) Send transitions of care/referral summaries through a method that conforms to the standard specified at (d); and (B) Receive transitions of care/referral summaries through a method that conforms to the standard specified at (d) from a service that has implemented the standard specified in (a). (C) XDM processing. Receive and make available the contents of a XDM package formatted in accordance with the standard adopted in (p)(1) if the technology is also being certified using an SMTP-based edge protocol. (ii) Validate and display. (A) Validate C-CDA conformance system performance. Technology must demonstrate its ability to detect valid and invalid transition of care/referral summaries received and formatted in accordance with both of the standards specified in (a)(3) and (4) This includes the ability to: (1) Parse each of the document types formatted according to the following document templates: CCD; Page 18 of 53

19 (b)(1) Transitions of care Consultation te; History and Physical; Progress te; Care Plan; Transfer Summary; Referral te, and Discharge Summary. (2) Detect errors in corresponding document-templates, section-templates, and entry-templates, including invalid vocabulary standards and codes not specified in either of the standards adopted in (a)(3) and (4); (3) Identify valid document-templates and process the data elements required in the corresponding section-templates and entry-templates from either of the standards adopted in (a)(3) and (4); (4) Correctly interpret empty sections and null combinations; and (5) Record errors encountered and allow for a user to be notified of or review the errors produced. (B) Technology must be able to display in human readable format the data included in transition of care/referral summaries received and formatted according to the standards specified in (a)(3) and (4). (C) Section views. 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 either of the standards adopted in (a)(3) and (4). (b)(1) Transitions of care, continued (iii) Create. (A) Enable a user to create a transition of care/referral summary: (1) Formatted according to the standards adopted in (a)(3); (2) Formatted according to the standards adopted in (a)(4); and (3) Includes, at a minimum, the Common Clinical Data Set and the following data expressed, where applicable, according to the specified standard(s): (i) Encounter diagnoses. The standard specified in (i) or, at a minimum, the version of the standard specified (a)(4); (ii) Cognitive status; (iii) Functional status; (iv) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information; and (v) Inpatient setting only. Discharge instructions. (B) Patient matching data quality. Technology must be capable of creating a transition of care/referral summary that includes the following data and, where applicable, represent such data according to the additional constraints specified below: (1) Data. first name, last name, maiden name, middle name (including middle initial), suffix, date of birth, place of birth, current address, historical address, phone number, and sex. (2) Constraint. Represent last/family name according to the CAQH Phase II Core 258: Eligibility and Benefits 270/271 rmalizing Patient Last Name Rule version (3) Constraint. Represent suffix according to the CAQH Phase II Core 258: Eligibility and Benefits 270/271 rmalizing Patient Last Name Rule version (JR, SR, I, II, III, IV, V, RN, MD, PHD, ESQ). If no suffix exists, the field should be entered as null. (4) Constraint. Represent the year, month and date of birth are required fields while hour, minute and second should be optional fields. If hour, minute and second are provided then either time zone offset should be included unless place of birth (city, region, country) is provided; in latter local time is assumed. If date of birth is unknown, the field should be marked as null. (5) Constraint. Represent phone number (home, business, cell) in the ITU format specified in ITU-T E.123 and ITU-T E.164. If multiple phone numbers are present, all should be included. (6) Constraint. Represent sex in accordance with the standard adopted at (n)(1). Preamble FR Citation: 80 FR Page 19 of 53

20 (b)(1) Transitions of care Echoing previous points in our comments, we recommend that ONC add clarity and flexibility to the transitions of care criterion. We suggest the following: (1) It is both burdensome and unnecessary for vendors to be able to create both versions of the CCDA. Supporting two versions with different code set requirements will lead to confusion and obstacles to interoperability. Instead we recommend the certification criterion require that we generate either version (but not both), but have the ability to receive both versions as it is the receiving side that may encounter either version. (2) More clarity is needed around error handling: ONC should either decide to be less prescriptive in this measure or should provide more specific error scenarios and standard messages so that everyone handles the same errors in a consistent manner. (3) We suggest that the extraction of metadata from the XDM message creates unnecessary burden and this data instead be taken from the CCDA, which provides more consistency when there is only a CCDA inside the XDM. (4) To provide more clarity, we recommend that for DOBs, if the time is provided, the time zone should also be required as issues may arise in inferring the time zone from a city name, state or zip code (b)(2) Clinical information reconciliation and incorporation The EP, eligible hospital, or CAH provides a summary of care record when transitioning or referring their patient to another setting of care, retrieves a summary of care record upon the first patient encounter with a new patient, and incorporates summary of care information from other providers into their EHR using the functions of certified EHR technology. Page 20 of 53

21 (b)(2) Clinical information reconciliation and incorporation (2) Clinical information reconciliation and incorporation. (i) General requirements. Paragraphs (b)(2)(ii) and (iii) of this section must be completed based on the receipt of a transition of care/referral summary formatted in accordance with the standard adopted in (a)(3) as well as separately to the standard adopted in (a)(4) using the Continuity of Care Document, Discharge Summary Document and Referral Summary document templates. (ii) Correct patient. Upon receipt of a transition of care/referral summary formatted according to either of the standards adopted at (a)(3) or (4), technology must be able to demonstrate that the transition of care/referral summary received is or can be properly matched to the correct patient. (iii) Reconciliation. Enable a user to reconcile the data that represent a patient's active medication list, medication allergy list, and problem list as follows. For each list type: (A) Simultaneously display (i.e., in a single view) the data from at least two 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; (B) Enable a user to create a single reconciled list of medications, medication allergies, or problems; (C) Enable a user to review and validate the accuracy of a final set of data; and (D) Upon a user's confirmation, automatically update the list, and incorporate the following data expressed according to the specified standard(s): (1) Medications. At a minimum, the version of the standard specified in (d)(3); (2) Medication allergies. At a minimum, the version of the standard specified in (d)(3); and (3) Problems. At a minimum, the version of the standard specified in (a)(4). (iv) System verification. Based on the data reconciled and incorporated, the technology must be able to create a file formatted according to the standard adopted at (a)(4) using the Continuity of Care Document document template. Preamble FR Citation: 80 FR We would support this criterion if it remains unchanged. However, in response to the proposed changes, we note that it is not a valid testing technique to incorporate/reconcile the information into the chart and then require the EHR to create an outgoing CCDA with the same information. For medication mappings there is not always one-to-one mapping between the Rxrm code and an EHR drug database vendor s medication ID concept. So if the Rxrm is reconciled into the EHR, it is not guaranteed that the same Rxrm code would be generated back out as the first choice based on the drug database vendor s medication ID mapping to Rxrm (b)(3) Electronic prescribing EPs must generate and transmit permissible prescriptions electronically, and eligible hospitals and CAHs must generate and transmit permissible discharge prescriptions electronically (erx). Page 21 of 53

22 (b)(3) Electronic prescribing (3) Electronic prescribing. (i) Enable a user to prescribe, send, and respond to prescription-related transactions for electronic transmission in accordance with the standard specified at (b)(2), and, at a minimum, the version of the standard specified in (d)(3), as follows: (A) Create new prescriptions (NEWRX); (B) Change prescriptions (RXCHG, CHGRES); (C) Cancel prescriptions (CANRX, CANRES); (D) Refill prescriptions (REFREQ, REFRES); (E) Receive fill status notifications (RXFILL); and (F) Request and receive medication history information (RXHREQ, RXHRES). (ii) Enable a user to enter, receive, and transmit structured and codified prescribing instructions for the transactions listed in paragraph (b)(3)(i) of this section for electronic transmission in accordance with the standard specified at (b)(2) and, at a minimum, for at least the following component composites: (A) Repeating Sig; (B) Code System; (C) Sig Free Text String; (D) Dose; (E) Dose Calculation; (F) Vehicle; (G) Route of Administration; (H) Site of Administration; (I) Sig Timing; (J) Duration; (K) Maximum Dose Restriction; (L) Indication; and (M) Stop. (iii) Technology must limit a user s ability to prescribe all medications in only the metric standard. (iv) Technology must always insert leading zeroes before the decimal point for amounts less than one and must not allow trailing zeroes after a decimal point when a user prescribes medications. Preamble FR Citation: 80 FR Page 22 of 53

23 (b)(3) Electronic prescribing We are very supportive of many of the changes in the electronic prescribing section, particularly from patient safety and medical adherence perspectives. (i) We also agree that the new message types could greatly benefit care. However, while the RXFILL transactions exist today, pharmacies do not send messages. Once again EHRs are forced to certify the capability even when pharmacies are not sending anything. (ii) We agree with the direction of adopting the Structured and Codified SIG. We recommend that the additional components and attributes be optional as they would not be necessary for the majority of prescribing use cases. (iii) We recommend that ONC not mandate metric units for data entry as we try to give our providers the flexibility to prescribe how they want with the system doing the conversion to metric if necessary. While metric units for volumetric dosing are best practices according to patient safety literature, we note that occasionally, our users want to dose in other units and can do so with unstructured sigs. Furthermore, we get our options for units from FDB and they seem to limit most options for metric units. They are not under the regulation of CMS or ONC, and it would be ill-advised for us to attempt to create metric conversion mappings for these cases on our own. (iv) We are supportive if this change is limited to display in the user interface and on transmission but it should not be mandated to store it that way in the database (b)(4) Incorporate laboratory tests and values/results (4) Incorporate laboratory tests and values/results. (i) Receive results. (A) Ambulatory setting only. (1) Receive and incorporate clinical laboratory tests and values/results in accordance with the standard specified in (j)(2); and, at a minimum, the version of the standard specified in (c)(3). (2) Display the tests and values/results received in human readable format. (B) Inpatient setting only. Receive clinical laboratory tests and values/results in a structured format and display such tests and values/results in human readable format. (ii) Display the test report information: (A) Specified in 42 CFR (a)(1) through (3) and (c)(1) through (7); (B) Related to reference intervals or normal values as specified in 42 CFR (d); (C) For alerts and delays as specified in 42 CFR (g) and (h); and (D) For corrected reports as specified in 42 CFR (k)(2). (iii) Attribute, associate, or link a laboratory test and value/result with a laboratory order or patient record. Preamble FR Citation: 80 FR Page 23 of 53

Use CPOE 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.

Meaningful Use Criteria for Eligible and Eligible Professionals (EPs) Under the Electronic Health Record (EHR) meaningful use final rules established by the Centers for Medicare and Medicaid Services (CMS),

AAP Meaningful Use: Certified EHR Technology Criteria On July 13, 2010, the US Centers for Medicare and Medicaid Services (CMS) released a Final Rule establishing the criteria with which eligible pediatricians,

Putting the Meaningful in Meaningful Use Meeting current criteria while preparing for the future The Centers for Medicare & Medicaid Services designed Meaningful Use (MU) requirements to encourage healthcare

Meaningful Use Objectives The purpose of the electronic health records (EHR) incentive program is not so much the adoption of health information technology (HIT), but rather how HIT can further the goals

Community Center Readiness Guide Additional Resource #13 Meaningful Use Implementation Tracking Tool (Template) MEANINGFUL USE HITECH s goal is not adoption alone but meaningful use of EHRs that is, their

Meaningful Use and Lab Related Requirements ONC State HIE / NILA Workgroup August 20, 2013 What is an EHR? Electronic Health Record Information system used by healthcare providers to store and manage patient

EMR Name/Model Amazing Charts Version 5 EMR Vendor Amazing Charts Please note: All of our answers refer to use for an Eligible Professional. Amazing Charts is not Stage 1 objectives Use CPOE Use of CPOE

Meaningful Use Qualification Plan Overview Certified EHR technology used in a meaningful way is one piece of a broader Health Information Technology infrastructure intended to reform the health care system

Medicaid EHR Incentive Program Focus on Stage 2 Kim Davis-Allen, Outreach Coordinator Kim.davis@ahca.myflorida.com Understanding Participation Program Year Program Year January 1 st - December 31st. Year

s Preparing for Meaningful Use in 2014 MEDITECH (Updated December 2013) Professionals please see the document: MEDITECH Prepares You for Stage 2 of Meaningful Use: Professionals. Congratulations to our

Meaningful Use Updates Stage 2 and 3 Julia Moore, Business Analyst SMC Partners, LLC July 8, 2015 Stage 2 Requirements 2015 EPs beyond 1st year of MU must report on a full year of data EPs in 1 st year

Meaningful Use Stage 3 Rule: What it Means for Hospitals, Physicians & Health IT Developers Vernessa T. Pollard and Nicole Liffrig Molife April 2015 With the publication of the Stage 3 Meaningful Use Rule

E Z BIS ELECTRONIC HEALTH RECORDS CERTIFICATION AND THE HITECH INCENTIVE PROGRAM The Incentives On July 13, 2010, the U.S. Department of Health and Human Services finalized the Electronic Health Record

Meaningful Use - The Basics Presented by PaperFree Florida 1 Topics Meaningful Use Stage 1 Meaningful Use Barriers: Observations from the field Help and Questions 2 What is Meaningful Use Meaningful Use

Chapter 1 Where to Begin? Auditing the Current EHR System After implementation, allow for a period of stabilization, so physicians and employees can gain more comfort using the electronic health record

Stage 3 Meaningful Use In October 2015, CMS released the Medicare and Medicaid Programs: Electronic Health Record Incentive Program Stage 3 and Modifications to Meaningful Use in 2015 through 2017 final

This chart reflects the applicability and potential achievability of MU requirements for an anesthesiologist who: - Provides surgical anesthesia and writes fewer than 100 outpatient prescriptions per year

2013 Meaningful Use Dashboard Calculation Guide Learn how to use Practice Fusion s Meaningful Use Dashboard to help you achieve Meaningful Use. For more information, visit the Meaningful Use Center. General

MEANINGFUL USE STAGE 2 REQUIREMENTS FOR ELIGIBLE PROVIDERS USING CERTIFIED EMR TECHNOLOGY On August 24, the Centers for Medicare & Medicaid Services (CMS) posted the much anticipated final rule for Stage

1 EP EH CPOE: Use CPOE 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

Meaningful Use Cheat Sheet CORE MEASURES: ALL REQUIRED # Measure Exclusions How to Meet in WEBeDoctor 1 CPOE (Computerized Physician Order Entry) More than 30 percent of all unique patients with at least

EHR Incentive Programs A program administered by the Centers for Medicare & Medicaid Services (CMS) Eligible Professional s Guide to STAGE 2 of the EHR Incentive Programs September 2013 TABLE OF CONTENTS...

Incentives to Accelerate EHR Adoption The passage of the American Recovery and Reinvestment Act (ARRA) of 2009 provides incentives for eligible professionals (EPs) to adopt and use electronic health records