Presentation is loading. Please wait.

Presentation is loading. Please wait.

Comparison of ONC & LTPAC EHR Functional Criteria AND Testimony to HITPC C/A Workgroup (Summary & Detail Slides) January 10, 2014 (Updated 1/17/2014) Jennie.

Similar presentations


Presentation on theme: "Comparison of ONC & LTPAC EHR Functional Criteria AND Testimony to HITPC C/A Workgroup (Summary & Detail Slides) January 10, 2014 (Updated 1/17/2014) Jennie."— Presentation transcript:

1 Comparison of ONC & LTPAC EHR Functional Criteria AND Testimony to HITPC C/A Workgroup (Summary & Detail Slides) January 10, 2014 (Updated 1/17/2014) Jennie Harvell, HHS/ASPE Sue Mitchell, Independent Consultant

2 Table of Contents Incorporate Laboratory Tests & Values/Results
Slide 34 Clinical Decision Support Slide 36 Advance Care Planning Slide 40 Clinical Quality Measures Slide 44 Public Health Slide 49 Patient-Specific Education Resources Slide 53 LTPAC Setting Specific EHR-S Requirements Slide 55 Privacy and Security Slide 3 Summary Care Record at TOC/Referral Slide 9 Clinical Summary Slide 16 View, Download, Transmit Slide 18 Data Portability Slide 20 Patient Demographics Slide 23 Clinical Health Information Slide 25 Medication Related Criteria Slide 29

3 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Privacy & Security related criteria: Authentication, Access Control & Authorization Auditable Events & Tamper-Resistance Audit Report(s) Amendments Automatic Log-Off Emergency Access End-User Device Encryption Integrity Optional – Accounting of Disclosures

4 Privacy & Security Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (d)(1) Authentication, access control, and authorization. Good match on verifying that a person seeking access to electronic health information is the one claimed Good match on establishing user access based on the unique identifier(s) and the actions the user is permitted to perform with the EHR technology § (d)(2) Auditable events and tamper resistance. Good match on record actions related to electronic health information in accordance with ONC specified standards Poor match on record the audit log status (enabled or disabled) in accordance with ONC specified standards Poor match on record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by EHR No match on EHR system set by default to perform specified audit tasks No match on restricting the ability to disable the audit log to a limited set of users Good match on audit log protection No match on detection of alteration to the audit log GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (d)(2) Auditable events and tamper resistance. Poor match on record the audit log status (enabled or disabled) in accordance with ONC specified standards Neither LTC FP nor CCHIT criteria explicitly require the recording of the audit log status (enabled or disabled). Poor match on record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by EHR Neither LTC FP nor CCHIT criteria explicitly require the recording of the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by EHR. No match on EHR system set by default to perform specified audit tasks Neither LTC FP nor CCHIT criteria explicitly require systems to be set by default to record: actions related to electronic health information (i.e., audit trail); audit log status; and encryption status. No match on restricting the ability to disable the audit log to a limited set of users Neither LTC FP nor CCHIT criteria explicitly require restricting, to a limited set of users, the ability to disable the audit log. No match on detection of alteration to the audit log Neither LTC FP nor CCHIT criteria explicitly address detection of audit log alteration.

5 Privacy & Security Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (d)(3) Audit report(s). Fair match on ability to create an audit report for a specific time period and sort entries in the audit log by specified data elements § (d)(4) Amendments. Poor match for select the record affected by a patient’s request for amendment Good match for append the record for an accepted amendment Poor match for denied patient request for amendment § (d)(5) Automatic log-off. Fair match for automatic log-off. § (d)(6) Emergency access. Good match on permitting identified users to access electronic health information during an emergency § (d)(7) End-user device encryption. No match on encryption of end-user devices after use of EHR technology on those devices stops Fair match on use of encryption algorithms identified in FIPS Pub Annex A No match on default setting to encrypt end-user devices or restriction of users who can configure this feature No match on prevent storage of health info on end-user devices after use of EHR technology on those devices stops GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (d)(3) Audit report(s). Fair match on ability to create an audit report for a specific time period and sort entries in the audit log by specified data elements Neither LTC FP nor CCHIT criteria explicitly requires the ability to sort audit log entries according to ONC specified sections of ASTM E § (d)(4) Amendments. Poor match for select the record affected by a patient’s request for amendment Neither LTC FP nor CCHIT criteria explicitly addresses the ability to select and amend a record affected by a patient’s request for amendment. Poor match for denied patient request for amendment Neither LTC FP nor CCHIT criteria explicitly addresses processes for denied patient requests for amendment § (d)(5) Automatic log-off. Fair match for automatic log-off. The LTC FP criteria do not require automatic log-off. Note: The CCHIT criteria do require automatic log-off. § (d)(7) End-user device encryption. No match on encryption of end-user devices after use of EHR technology on those devices stops Neither LTC FP nor CCHIT criteria explicitly require encryption of end-user devices after use of EHR technology on those devices stops. Fair match on use of encryption algorithms identified in FIPS Pub Annex A The LTC FP criteria do not explicitly require use of encryption algorithms identified in FIPS Pub Annex A. Note: The CCHIT criteria do require use of encryption algorithms identified in FIPS Pub Annex A. No match on default setting to encrypt end-user devices or restriction of users who can configure this feature Neither LTC FP nor CCHIT criteria explicitly require systems to be set by default to encrypt end-user devices or restrict configuration of this feature to a limited set of identified users. No match on prevent storage of health info on end-user devices after use of EHR technology on those devices stops Neither LTC FP nor CCHIT criteria explicitly preclude electronic health information from being locally stored on end-user devices after use of EHR technology on those devices stops.

6 Privacy & Security Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (d)(8) Integrity. No match on create a message digest in accordance with the hashing algorithms specified in FIPS PUB Fair match on verification of received messages in accordance with hashing algorithm specified in FIPS PUB § (d)(9) Optional– Accounting of disclosures. Good match on compliance with HIPAA requirements for accounting of disclosures Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: All LTPAC settings require technology with Privacy, Security and Integrity Features GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (d)(8) Integrity. No match on create a message digest in accordance with the hashing algorithms specified in FIPS PUB Neither LTC FP nor CCHIT criteria explicitly require a message digest in accordance with FIPS Pub as specified by ONC. Fair match on verification of received messages in accordance with hashing algorithm specified in FIPS PUB The LTC FP criteria do not explicitly require verification of received messages in accordance with hashing algorithm specified in FIPS PUB 180-4 The CCHIT criteria requires use of the TP13 “Document Integrity” option if the system uses HITSP TP13 as a document consumer. While the TP13 Document Integrity option validates the SHA-1 hash attribute by the document consumer, the CCHIT criteria do not identify verification requirements if HITSP TP13 has not been implemented.

7 Privacy & Security Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC December 12, 2013 “… I would …attest that we owe the folks that we take care of the same responsibility in taking care of their digital life and their financial well-being. Data can be stolen from many areas and LTPAC software providers today are very, very small and are learning to provide safe, secure, feature rich, scalable systems. There are a few acute software vendors that are entering the [PAC] market that are trying to figure out what [PAC] means and the features and functions are very different than the acute care space. Most LTPAC providers have very small IT departments and do not have the time or skill to evaluate software at the level needed to ensure safe company and patient data. Most recently, I’d like to give a very quick example. Brookdale adopted a software package about two years ago and if my IT department did not evaluate that software—and this was a piece of software used by many of the providers today—I would've implemented a piece of software that, on a daily basis, would have been a HIPAA data breach violation…I pose to you today that many of the [LTC] providers’ IT departments don’t have the capabilities to question these software providers’ functionality. (S. Ranson) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (d)(8) Integrity. No match on create a message digest in accordance with the hashing algorithms specified in FIPS PUB Neither LTC FP nor CCHIT criteria explicitly require a message digest in accordance with FIPS Pub as specified by ONC. Fair match on verification of received messages in accordance with hashing algorithm specified in FIPS PUB The LTC FP criteria do not explicitly require verification of received messages in accordance with hashing algorithm specified in FIPS PUB 180-4 The CCHIT criteria requires use of the TP13 “Document Integrity” option if the system uses HITSP TP13 as a document consumer. While the TP13 Document Integrity option validates the SHA-1 hash attribute by the document consumer, the CCHIT criteria do not identify verification requirements if HITSP TP13 has not been implemented.

8 Privacy & Security Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC December 12, 2013 “Brookdale has had to subsidize some of these certifications just to make sure that our software systems are compliant with HIPAA and the regulations that we need to comply with as a public company.” (S.Ranson) “Certification of software for a [LTC]company should include but not limited to the following categories: Secure regulatory compliance, interoperability which many of you have talked about today, third party device integration, validation—and no one has mentioned this, but validation of trusted sender data quality. We need to know the sender of the data is who they say they are and the data that they are transferring in fact is accurate for determining quality of care; core base functionality by care setting with coding standards.” (S.Ranson) “there should be an overarching standard around security and privacy” (S.Ranson) “One of the most powerful interventions, though, that led to our results of this grant that we have been conducting, of course, is the use of Direct, which is HIPAA compliant …”( B. Yeaman) Surveyors need prompt access to the EHR (K. Tritz) “we must … [ensure]care plans are in each record enabling client access—that’s patient, family, and caregiver” (J. Lynn) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (d)(8) Integrity. No match on create a message digest in accordance with the hashing algorithms specified in FIPS PUB Neither LTC FP nor CCHIT criteria explicitly require a message digest in accordance with FIPS Pub as specified by ONC. Fair match on verification of received messages in accordance with hashing algorithm specified in FIPS PUB The LTC FP criteria do not explicitly require verification of received messages in accordance with hashing algorithm specified in FIPS PUB 180-4 The CCHIT criteria requires use of the TP13 “Document Integrity” option if the system uses HITSP TP13 as a document consumer. While the TP13 Document Integrity option validates the SHA-1 hash attribute by the document consumer, the CCHIT criteria do not identify verification requirements if HITSP TP13 has not been implemented.

9 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Summary Care Record at TOC/Referral Receive, Display, and Incorporate TOC/Referral Summaries Create and Transmit TOC/Referral Summaries

10 Summary Care Record at TOC/Referral Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (b)(1) Transitions of Care (TOC) – Receive, Display, and Incorporate TOC/Referral Summaries Good match on “receive” TOC/referral summaries. No match on “receive” in accordance with specified transport standards Fair match on “display” TOC/referral summaries received and formatted according to HITSP C32/ASTM CCR/Consolidated CDA Good match on “incorporate” upon receipt of a TOC/referral summary (no content exchange standard specified) No match on “incorporate” upon receipt of a TOC/referral summary formatted as a HL7 Consolidated CDA Good match on properly match TOC/referral summary to correct patient Poor match/no match on incorporate medication list/ medication allergy list expressed in RxNorm and problem list expressed in SNOMED Poor match on display each additional section(s) of a TOC/ referral summary formatted as a HL7 Consolidated CDA GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (b)(1) Transitions of Care (TOC) – Receive, Display, and Incorporate TOC/Referral Summaries No match on “receive” in accordance with specified transport standards Neither LTC FP nor CCHIT LTPAC criteria require the ability to receive summary care records in accordance with ONC Applicability Statement for Secure Health Transport Neither LTC FP nor CCHIT LTPAC criteria require the ability to receive summary care records in accordance with ONC Applicability Statement for Secure Health Transport and ONC XDR and XDM for Direct Messaging Specification Note: The LTC FP and CCHIT LTPAC program pre-date the ONC 2014 transport standards. Fair match on “display” TOC/referral summaries received and formatted according to HITSP C32/ATSM CCR/Consolidated CDA The LTC FP does not call out explicit content exchange standards (i.e., HITSP C32, ASTM CCR, or HL7 Consolidated CDA), using instead the more generic statement “standards-based structured, codified data received from an external source” The CCHIT LTPAC criteria do not explicitly require the ability to display summary care records that are received and formatted according to CCR or Consolidated CDA standards. Note: The LTC FP and CCHIT LTPAC program pre-date the HL7 Consolidated CDA standard. No match on “incorporate” upon receipt of a TOC/referral summary formatted as a HL7 Consolidated CDA Neither LTC FP nor CCHIT criteria require the ability to receive transition of care/referral summaries formatted according to the HL7 Consolidated CDA Poor match/no match on incorporate medication list/medication allergy list expressed in RxNorm and problem list expressed in SNOMED The LTC FP does not explicitly require systems to incorporate medication/medication allergy content expressed according to RxNorm. The CCHIT Interoperability Test Guide states that coded terminologies for medications (i.e., RxNorm and NDC) are not required for 2011 LTPAC Certification Neither the LTC FP nor the CCHIT LTPAC program include criteria regarding electronically incorporating problems from external sources expressed in SNOMED CT. Poor match on display each additional section(s) of a TOC /referral summary formatted as a HL7 Consolidated CDA Neither the LTC FP nor the CCHIT LTPAC program explicitly requires the ability to display summary care records that are received and formatted according to Consolidated CDA standards. Note: The LTC FP and CCHIT LTPAC program pre-date the HL7 Consolidated CDA standard

11 Summary Care Record at TOC/Referral Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (b)(2) Transitions of Care (TOC) – Create and Transmit TOC/ Referral Summaries Good match on create a TOC/referral summary No match on summary formatted according to Consolidated CDA Fair match on summary including Common MU Data Set and additional specified items No match on expressing Common MU data set and additional items according to specified vocabulary standards Poor/no match on transmit TOC/referral summary [in accordance with specified transport standards] GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (b)(2) Transitions of Care (TOC) – Create and Transmit TOC/Referral Summaries No match on summary formatted according to Consolidated CDA. Neither LTC FP nor CCHIT LTPAC criteria require the ability to create summary care records formatted according to Consolidated CDA standards. Note: The LTC FP and CCHIT LTPAC program pre-date the ONC 2014 transport standards and the HL7 Consolidated CDA Fair match on summary including Common MU Data Set and additional specified items. LTC FP and CCHIT LTPAC requirements for a summary document do NOT address seven of the 16 elements in the Common MU Data set, including: Preferred Language; Lab Value(s)/result(s); Care Team Members; Smoking Status; Vital Signs; Lab Test(s); Procedures Note: LTC FP/CCHIT criteria for clinical summaries address inclusion of the following items from the Common MU data set - demographics, meds, med allergies, immunizations, problem list, procedures, and diagnostic test results, plan of care, functional status, advance directives LTC FP and CCHIT LTPAC requirements for a summary document do NOT address three of the six ONC data elements specified for summary care records, including: Cognitive Status; Reason for Referral/ Contact Information; Discharge Instructions Note: LTC FP/CCHIT criteria for clinical summaries address inclusion of the following ONC specified data elements – encounter diagnoses, immunizations, and functional status No match on expressing Common MU data set and additional items according to specified vocabulary standards. Neither LTC FP nor CCHIT LTPAC criteria specifies vocabulary standards for referenced data elements that are found in the Common MU Data Set and ONC listing of additional items for the summary care record. Common Meaningful Use Data Set: (4) Race—the standard specified in § (f) [OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity] (5) Ethnicity—the standard specified in § (f) [OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity] (6) Preferred language—the standard specified in § (g) [ISO 639–2 alpha-3 codes] (7) Smoking status—the standard specified in § (h) [SNOMED CT® value set specified at § (h)] (8) Problems—at a minimum, the version of the standard specified in § (a)(3) [SNOMED CT®] (9) Medications—at a minimum, the version of the standard specified in § (d)(2) [RxNorm] (10) Medication allergies—at a minimum, the version of the standard specified in § (d)(2) [RxNorm] (11) Laboratory test(s)—at a minimum, the version of the standard specified in § (c)(2) [LOINC] (15) Procedures— (i) At a minimum, the version of the standard specified in § (a)(3) [SNOMED CT] or § (b)(2) [HCPCS] (ii) Optional. The standard specified at § (b)(3) [CDT] (iii) Optional. The standard specified at § (b)(4) [ICD-10-PCS] Other Specified Data: Encounter diagnoses. The standard specified in § (i) [ICD-10-CM] or, at a minimum, the version of the standard specified § (a)(3) [SNOMED CT]; Immunizations. The standard specified in § (e)(2) [CVX—Vaccines Administered] Poor/no match on transmit TOC/referral summary [in accordance with specified transport standards]. Neither LTC FP nor CCHIT LTPAC criteria require the ability to transmit summary care records in accordance with ONC Applicability Statement for Secure Health Transport Neither LTC FP nor CCHIT LTPAC criteria require the ability to transmit summary care records in accordance with ONC Applicability Statement for Secure Health Transport and ONC XDR and XDM for Direct Messaging Specification Note: The LTC FP and CCHIT LTPAC program pre-date the ONC 2014 transport standards

12 Summary Care Record at TOC/Referral Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility: Create, transmit, receive, incorporate Summary Care Records in all LTPAC settings December 12, 2013 LTPAC providers: “are pressured by receiving EHs for better information” (T. Leonard) and “getting pressure from EHs to be part of the system” (S. Chies) “The focus of [LTPAC EHR] certification should be to support transitions of care” (J. Damgaard, D. DeVore) “standards used in [MU], such as CCDA, SNOMED, LOINC, and RxNorm, can be and are supported within the EHR products to help obtain greater parity in the exchange of information regardless of formal certification” (K. Utterback) “more and more individuals have and will have episodes of acute illness superimposed on chronic conditions, and the result is far more complex care provided in multiple sites by multiple clinicians across longer episodes of care… important for them are really two fundamental…processes… the first is the transition of clinical responsibility from one clinician…to another, and… from site to site or team to team…The second process is the exchange of a longitudinal care plan to align care across these multiple sites and providers and reduce the risks of omissions and duplications. … (T. O’Malley)

13 Summary Care Record at TOC/Referral Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “electronic exchange of standardized, interoperable clinical information between different IT platforms becomes the essential tool for care integration between and among acute and LTPAC providers.” (T. O’Malley) “at a minimum, EHR certification for both eligible providers…and LTPAC sites should include the capacity to send and receive these standardized data elements [in the HL7 CCDA] to support transitions in coordination…” (T. O’Malley) “The [EHR] is critical to improving quality of care …Number one, interoperability. As the patient experiences care transitions, interoperability will lead to efficiencies… we anticipate …saving two hours per admission and facility staff time… This savings will be realized because of the automated entry of… orders … electronically delivered from the discharging hospital into the SNF EHR. … will …decrease keystroke entry errors, which…frequently contribute to patient harm...time saved will allow staff to focus efforts on improved data gathering and evaluation of the patient’s condition which is critical as sicker individuals are admitted (L.Harris). “Supporting effective [ToC] should be the focus of our IT certification efforts… the establishment of a national… certification process focused on care transitions can head off… state level standards.” (J. Damgaard)

14 Summary Care Record at TOC/Referral Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “[Benedictine Health System] is expecting our software vendor to adopt voluntary certification and other certifications…that will allow us to better use our information and…to transmit this information interoperably to other providers, including acute care... One of the visions we have going forward is to create an enterprise wide record that will cut across all …sectors of our delivery system,…from the post-acute payer…to independent living so that we can manage these individuals better.” (S. Chies) “We're already getting …pressure from referring hospitals to exchange health information… Unfortunately, these are usually requests for ad hoc connections and not through a formal HIE…they want our facility associates to log directly into a hospital discharge system to input and receive information. That may be great for the hospital, but then [LTPAC is] left with manual input of the information into our own systems. I would like to see the standards and efforts around formal HIEs to be pushed much harder. Without this push, it’s hard to see successful interoperability any time soon…. . Due to our recent certification… we can now import lab results, submit immunization registries with HL7, submit syndromic surveillance files with HL7, provide clinical summaries in the form of a CCD, and also receive CCD/CCR format from external sources ” (T. Leonard)

15 Summary Care Record at TOC/Referral – LTC FP & CCHIT Requirements NOT in ONC 2014 Edition
ONC requirements for ToC/Summary Care Records do not require or reference the inclusion of some clinical content important to LTPAC providers and included in the LTC FP (see bold text): DC.1.1.4, cc#3: The system SHALL provide the ability to produce a CCD that includes at least the following sections: Advance Directives, Problems, Alerts, and Medications DC.1.1.4, cc#4: The system provide the ability to produce a CCD that includes the following sections: Functional Status, Immunizations, Medical Equipment and Plan of Care. The LTC FP and CCHIT criteria include additional functionality related to receipt, display, incorporation, creation and transmission of summary documents and content that are not included in the ONC standards. These criteria are applicable to EHRs regardless of setting. See the Advance Directive Section of the Powerpoint regarding the relevant advance directive content identified as needed in the LTC FP. The LTC FP function DC describes the CCD “advance directives” section as follows: “The Advance Directives section of the CCD contains data defining the patient’s advance directives and any reference to supporting documentation. The most recent and up-to-date directives are required, if known, and should be listed in as much detail as possible. This section contains data such as the existence of living wills, healthcare proxies, and CPR and resuscitation status. If referenced documents are available, they can be included in the CCD exchange package.” The LTC FP function DC describes the CCD “alerts” section as follows: “The ‘Alerts’ section of the CCD is used to list and describe any allergies, adverse reactions, and alerts that are pertinent to the patient’s current or past medical history. At a minimum, currently active and any relevant historical allergies and adverse reactions should be listed.”

16 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Clinical Summary (Ambulatory setting only)

17 Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC
Clinical Summary Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (e)(2) Clinical Summary (Ambulatory setting only) Good match on create a clinical summary No match on summary formatted according to Consolidated CDA Poor match on Customization of clinical summary Fair match on summary including Common MU Data Set No match on summary including additional specified items Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: Create clinical summary December 12, 2013 LTPAC providers: “are pressured by receiving EHs for better information” (T. Leonard) and “getting pressure from EHs to be part of the system” (S. Chies) “The focus of [LTPAC EHR] certification should be to support transitions of care” (J. Damgaard, D. DeVore) “standards used in meaningful use, such as CCDA, SNOMED, LOINC, and RxNorm, can be and are supported within the EHR products to help obtain greater parity in the exchange of information regardless of formal certification” (K. Utterback) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (e)(2) Clinical Summary (Ambulatory setting only) No match on summary formatted according to Consolidated CDA. Neither LTC FP nor CCHIT LTPAC criteria require the ability to create clinical summaries formatted according to Consolidated CDA standards. Note: The LTC FP and CCHIT LTPAC program pre-date the ONC 2014 transport standards and the HL7 Consolidated CDA Poor match on Customization of clinical summary Neither LTC FP nor CCHIT LTPAC criteria requires the ability to customize data included in the clinical summary. Fair match on summary including Common MU Data Set. LTC FP and CCHIT LTPAC requirements for a summary document do NOT address seven of the 16 elements in the Common MU Data set, including: Preferred Language; Lab Value(s)/result(s); Care Team Members; Smoking Status; Vital Signs; Lab Test(s); Procedures Note: LTC FP/CCHIT criteria for clinical summaries address inclusion of the following items from the Common MU data set - demographics, meds, med allergies, immunizations, problem list, procedures, and diagnostic test results, plan of care, functional status, advance directives No match on summary including additional specified items Neither the LTC FP nor the CCHIT LTPAC program requires the data elements specified at § (e)(2) (iii)(B) be available for inclusion in a clinical summary.

18 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
View, download, and transmit to 3rd party

19 View, Download, and Transmit to 3rd Party Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (e)(1) View, download, and transmit to 3rd party. Neither the LTC FP nor the CCHIT LTPAC program include requirements providing patients with an online means to view, download, and transmit specified data to a 3rd party. Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: Use of patient portals reported across all LTPAC provider types. Add statement December 12, 2013 “With every EHR system, there is a patient system reaction, so as we work towards certification in [LTPAC], it’s important to understand that a patient facing system will interact with that… As we view, download, and transfer, the provider should protect … information, but the patient should continue…to direct it, so the work being done in Blue Button would have a great application in transitions of care and [LTPAC].” (L. Kelly Hall) “we need to figure out what the presentation layer is that is appealing to patients and families, but to have one record that all parties can tap into, upload to, download from, right through to the end of the person’s life…” (J. Lynn)

20 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Data Portability

21 Data Portability Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (b)(7) Data Portability Good match on create a summary No match on summary formatted according to Consolidated CDA Fair match on summary including Common MU Data Set and additional specified items No match on expressing Common MU data set and additional items according to specified vocabulary standards Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: Electronically create a set of export summaries for all patients in EHR technology formatted according to the Consolidated CDA December 12, 2013 LTPAC providers: “are pressured by receiving EHs for better information” (T. Leonard) and “getting pressure from EHs to be part of the system” (S. Chies) “The focus of [LTPAC EHR] certification should be to support transitions of care” (J. Damgaard, D. DeVore) “standards used in meaningful use, such as CCDA, SNOMED, LOINC, and RxNorm, can be and are supported within the EHR products to help obtain greater parity in the exchange of information regardless of formal certification” (K. Utterback) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (b)(7) Data Portability No match on summary formatted according to Consolidated CDA. Neither LTC FP nor CCHIT LTPAC criteria require the ability to create summary records formatted according to Consolidated CDA standards. Note: The LTC FP and CCHIT LTPAC program pre-date the ONC 2014 transport standards and the HL7 Consolidated CDA Fair match on summary including Common MU Data Set and additional specified items. LTC FP and CCHIT LTPAC requirements for a summary document do NOT address seven of the 16 elements in the Common MU Data set, including: Preferred Language; Lab Value(s)/result(s); Care Team Members; Smoking Status; Vital Signs; Lab Test(s); Procedures Note: LTC FP/CCHIT criteria for clinical summaries address inclusion of the following items from the Common MU data set - demographics, meds, med allergies, immunizations, problem list, procedures, and diagnostic test results, plan of care, functional status, advance directives LTC FP and CCHIT LTPAC requirements for a summary document do NOT address three of the six ONC data elements specified for summary care records, including: Cognitive Status; Reason for Referral/ Contact Information; Discharge Instructions Note: LTC FP/CCHIT criteria for clinical summaries address inclusion of the following ONC specified data elements – encounter diagnoses, immunizations, and functional status No match on expressing Common MU data set and additional items according to specified vocabulary standards. Neither LTC FP nor CCHIT LTPAC criteria specifies vocabulary standards for referenced data elements that are found in the Common MU Data Set and ONC listing of additional items for the summary care record. Common Meaningful Use Data Set: (4) Race—the standard specified in § (f) [OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity] (5) Ethnicity—the standard specified in § (f) [OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity] (6) Preferred language—the standard specified in § (g) [ISO 639–2 alpha-3 codes] (7) Smoking status—the standard specified in § (h) [SNOMED CT® value set specified at § (h)] (8) Problems—at a minimum, the version of the standard specified in § (a)(3) [SNOMED CT®] (9) Medications—at a minimum, the version of the standard specified in § (d)(2) [RxNorm] (10) Medication allergies—at a minimum, the version of the standard specified in § (d)(2) [RxNorm] (11) Laboratory test(s)—at a minimum, the version of the standard specified in § (c)(2) [LOINC] (15) Procedures— (i) At a minimum, the version of the standard specified in § (a)(3) [SNOMED CT] or § (b)(2) [HCPCS] (ii) Optional. The standard specified at § (b)(3) [CDT] (iii) Optional. The standard specified at § (b)(4) [ICD-10-PCS] Other Specified Data: Encounter diagnoses. The standard specified in § (i) [ICD-10-CM] or, at a minimum, the version of the standard specified § (a)(3) [SNOMED CT]; Immunizations. The standard specified in § (e)(2) [CVX—Vaccines Administered]

22 Data Portability – LTC FP & CCHIT Requirements NOT in ONC 2014 Edition
ONC requirements for Data Portability do not require or reference the inclusion of some clinical content important to LTPAC providers and included in the LTC FP (see bold text): DC.1.1.4, cc#3: The system SHALL provide the ability to produce a CCD that includes at least the following sections: Advance Directives, Problems, Alerts, and Medications DC.1.1.4, cc#4: The system provide the ability to produce a CCD that includes the following sections: Functional Status, Immunizations, Medical Equipment and Plan of Care. The LTC FP and CCHIT criteria include additional functionality related to receipt, display, incorporation, creation and transmission of summary documents and content that are not included in the ONC standards. These criteria are applicable to EHRs regardless of setting. The LTC FP function DC describes the CCD “advance directives” section as follows: “The Advance Directives section of the CCD contains data defining the patient’s advance directives and any reference to supporting documentation. The most recent and up-to-date directives are required, if known, and should be listed in as much detail as possible. This section contains data such as the existence of living wills, healthcare proxies, and CPR and resuscitation status. If referenced documents are available, they can be included in the CCD exchange package.” See also the Advance Directive Section of this Powerpoint regarding the relevant advance directive content identified as needed in the LTC FP. The LTC FP function DC describes the CCD “alerts” section as follows: “The ‘Alerts’ section of the CCD is used to list and describe any allergies, adverse reactions, and alerts that are pertinent to the patient’s current or past medical history. At a minimum, currently active and any relevant historical allergies and adverse reactions should be listed.”

23 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Demographics

24 Patient Demographics Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (a)(3) Demographics. Fair match on the ability to record, change, and access patient demographic data No match on capture preferred language and race/ethnicity in accordance with ONC specified standard No match on the ability to record, change, and access preliminary cause of death in the event of a mortality. Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: All LTPAC providers need to record demographic data. December 12, 2013 “exchange of demographics and using some of the older ADT standards have been the primary interest…”(D. Devore) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (a)(3) Demographics. Fair match on record, change, and access patient demographic data Neither LTC FP nor CCHIT criteria identify explicit demographic data elements to be captured and maintained. No match on capture preferred language and race/ethnicity in accordance with ONC specified standard Neither LTC FP nor CCHIT criteria require use of the OMB Standard for Race and Ethnicity. Neither LTC FP nor CCHIT criteria require use of the ISO for preferred language. No match on the ability to record, change, and access preliminary cause of death in the event of a mortality. Neither LTC FP nor CCHIT include criteria addressing the ability to record, change, and access preliminary cause of death in the event of a mortality.

25 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Clinical Health Information Problem List Medication List Medication Allergy List Clinical Information Reconciliation

26 Clinical Health Information Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (a)(5) Problem list Good match on electronically record, change, and access problem list Fair match on capturing/accessing content for duration of stay and over multiple encounters Poor match on using specified standard [SNOMED] § (a)(6) Medication list Good match on electronically record, change, and access medication list and medication history § (a)(7) Medication Allergy list Good match on electronically record, change, and access active medication allergy list and medication allergy history § (b)(4) Clinical information reconciliation. Fair match on enable reconciliation of medication list Poor match on enable reconciliation of problem list and medication allergy list Poor match on simultaneous display of data from at least two list sources, create single reconciled list, and review/validate/automatically update problem/med/med allergy list GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (a)(5) Problem List Fair match on capturing/accessing content for duration of stay and over multiple encounters. LTC FP and CCHIT criteria for creation of a single patient record do not explicitly describe the record as covering the duration of an encounter or covering multiple encounters. Poor match on using specified standard [SNOMED]. Neither the LTC FP nor the CCHIT LTPAC program includes criteria that explicitly require the use of SNOMED for diagnoses. § (a)(6) Medication List § (a)(6) Medication Allergy List § (b)(4) Clinical information reconciliation. Fair match on enable reconciliation of medication list. The CCHIT 2011 LTPAC program includes some functionality for medication reconciliation, but does not address reconciliation functionality for problem lists or medication allergy lists. Poor match on enable reconciliation of problem list and medication allergy list. The LTC FP does not include criteria for reconciliation functionality for any of the ONC targeted lists (i.e., medication list, problem list, or medication allergy list) Poor match on simultaneous display of data from at least two list sources, create single reconciled list, and review/validate/automatically update problem/med/med allergy list. Neither the LTC FP nor the CCHIT 2011 LTPAC program include requirements for the simultaneous display of medication, problem, or medication allergy lists that are being reconciled. Neither the LTC FP nor the CCHIT 2011 LTPAC program include requirements for the creation of a single, reconciled list of medications, problems, or medication allergies. Neither the LTC FP nor the CCHIT 2011 LTPAC program include requirements for the review/validation and automatic update of medication, problem, or medication allergy lists.

27 Clinical Health Information Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: Technology in all LTPAC settings would be clinically useful for: Patient Demographics, Health Information, Problem Lists, and Physician Order Entry. All LTPAC provider types use technology for: condition specific documentation and treatment records. Institutional LTPAC provider types (e.g., NHs, LTCHs, and IRFs) use technology for: medication and medication allergy information, Medication records, and exchanging information with Pharmacy and Lab information systems. Home health agencies may require: medication and medication allergy information, and Medication records. December 12, 2013 “…a joint project between NCPDP and HL7 for [C-CDA]…documents to meet CMS documentation requirements of an annual comprehensive med review. This structured document contains the pharmacist provided reconciled active med list, allergy list, indications for each active medication, and special instructions for the patient…can be used by pharmacists and other health care providers in all practice settings including LTPAC and behavioral health.” (S. Spiro)

28 Clinical Health Information Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “ As many as 60% of [NH] residents are prescribed over or equal to 9 chronic medications, which is the CMS definition of polypharmacy. The potential consequences … is the development of an [ADE]…[ADEs] are difficult to predict…approximately half these events are considered preventable, and finally, most, about 80%, are associated with monitoring rather than prescribing errors” (S.Handler) “At least two areas which are priorities [for EHR certification] from a [PH] perspective. They are medication administration data and laboratory data.” (N.Stone) “EHR can be instrumental in reducing preventable re-hospitalizations … In the reduction of medication errors, …prescribers entering orders electronically into the EHR will decrease the chance for errors in the interpretation of prescriber orders. Now, we heard today earlier that monitoring was more important than prescribing; however, …a significant number of orders are changed today verbally or via telephone, which result in SNF staff entering the order into the software rather than the prescriber doing it. Therefore, keystroke errors are frequently identified in our business as contributors to adverse events that result in patient harm.” (L.Harris) The electronic exchange of standardized, interoperable clinical information between different IT platforms becomes the essential tool for care integration between and among acute and LTPAC providers. (T O’Malley) “it’s good to have voluntary certification as a helpful step perhaps, and we could require …some interoperability of at least a small set of data, the medications, diagnoses, care plans, function, mental status, likely course—that would be my list. “ (J. Lynn)

29 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Medication related criteria: CPOE e-MAR e-Rx Drug-Formulary Check

30 Medication Related Criteria Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/A WG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (a)(1) CPOE. Good match on record, change and access each of the order types (i.e., meds, labs, radiology/imaging) § (a)(16) Inpatient setting only — e-MAR…. Good match on verify right patient Fair match on verify right: medication, dose, route, time, and documentation Neither addresses use of assistive technologies nor requires synchronizing system clocks for recording date and time of clinical documentation. § (b)(3) Electronic prescribing. Good match on NCPDP SCRIPT v10.6 Poor match on use of Rx Norm for prescription content § (a)(10) Drug-formulary checks. Good match on automatically and electronically check whether a drug formulary exists for patient or drug GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (a)(16) Inpatient setting only — e-MAR Fair match on verify right: medication, dose, route, time, and documentation Neither the LTC FP nor the CCHIT criteria address use of assistive technologies (e.g., scanning medication bar codes) to verify medication to be administered matches the medication ordered. Neither the LTC FP nor the CCHIT criteria address use of assistive technologies (e.g., scanning medication bar codes) to verify medication dose to be administered matches the medication dose ordered. Neither the LTC FP nor the CCHIT criteria address use of assistive technologies (e.g., scanning medication bar codes) to verify medication form to be administered matches the medication route ordered (e.g., tablet cannot be administered as an IV). Neither the LTC FP nor the CCHIT criteria address use of assistive technologies (e.g., scanning medication bar codes) to verify the time of day when medication is to be administered matches the medication time ordered (e.g., HS medication to be administered during bedtime hours). Neither the LTC FP nor the CCHIT criteria address ONC specified standards for synchronizing system clocks used for recording date and time of clinical documentation. § (b)(3) Electronic prescribing. Poor match on use of Rx Norm for prescription content The LTC FP does not explicitly require systems to express prescription and prescription related content according to RxNorm. The CCHIT Interoperability Test Guide states that coded terminologies for medications (i.e., RxNorm and NDC) are not required for 2011 LTPAC Certification.

31 Medication Related Criteria Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: CPOE, e-MAR, e-Rx: Functionality needed in NHs, LTCHs, IRFs. HHAs may require use of e-MAR. December 12, 2013 “…savings will be realized because of the automated entry of appropriate orders which have been electronically delivered from the discharging hospital into the SNF EHR.” (L. Harris) “…the practice of prescribers entering orders electronically into the EHR will decrease the chance for errors in the interpretation of prescriber orders. …we heard today earlier that monitoring was more important than prescribing; however, in my experience, a significant number of orders are changed today verbally or via telephone, which result in SNF staff entering the order into the software rather than the prescriber doing it. Therefore, keystroke errors are frequently identified in our business as contributors to adverse events that result in patient harm.” (L. Harris) “A [NF] indicated that they would discontinue a specific EMR they …implemented five months earlier as part of a plan of correction … among other problems an individual was given an excess dosage of Coumadin because the [e-MAR] kept all Coumadin orders, even when the dosage was changed. (K. Tritz) we had to build two prescription systems; one for e-prescription outside the [MU] and the other one to be integrated with our internal pharmacy. So once we get to interoperability, some of those barriers, I hope, will fall away for us. (T. Leonard)

32 Medication Related Criteria Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “a 2011 survey report by the [ASCP], the QS/1, pharmacies are continuing to move more into automation… Pharmacies surveyed have been the quickest to embrace e-prescribing automated packaging and electronic medication administration records. … In terms of electronic prescribing... the document noted the inconsistencies in LTPAC prescribing adoptions, stating the lack of direction on the LTPAC e-prescribing standard has led to these inconsistencies, leaving a void of the vendor implementation in this setting. Since the exemption is scheduled to remove November 1st, 2014, the industry is unsure how lifting the exemption will affect the e-prescribing adoption in the LTPAC setting. In addition, LTPAC settings have a higher use of controlled substances as compared to the ambulatory setting. Controlled substances represents further obstacles in the LTPAC e-prescribing adoption.” (S. Spiro) “ As many as 60% of [NH] residents are prescribed over or equal to 9 chronic medications, which is the CMS definition of polypharmacy. The potential consequences … is the development of an [ADE]…[ADEs] are difficult to predict…approximately half these events are considered preventable, and finally, most, about 80%, are associated with monitoring rather than prescribing errors” (S.Handler) “I don’t want to dissuade or discourage the use and development of prescribing decision support, but in the [NH], it’s important to remember to focus on monitoring as well” (S.Handler) “[CDS] at the time of prescribing is one of the most powerful ways to change or influence physician and provider decision making” (N. Stone)

33 Medication Related Criteria Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “In terms of utilization of existing technology pipeline, there are existing standards for lab, including LOINC and medications, NCPDP, and are widely available to support this safety system.” (S. Handler)

34 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Incorporate Laboratory Tests & Values/Results

35 Incorporate Laboratory Tests & Values/Results Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (b)(5) Incorporate Laboratory Tests & Values/Results Good match on receive and incorporate results Good match on display results Poor match on requirement to display all the information, as specified, for a test report Good match on attribute, associate, or link lab test and value/result with laboratory order or patient record Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: All LTPAC settings reported to use/need lab tests/results in practice. December 12, 2013 “The [CDS] systems that we've developed use signals that require the presence of admission, discharge, transfer, lab, and medication data…there are existing standards for lab, including LOINC and medications, NCPDP, and are widely available to support [AD detection and management].” (S. Handler) “Due to our recent certification process, we've built in some key capabilities. We can now import lab results…”(T.Leonard) “Indeed, we find that sharing…lab results and just the exchange of demographics … have been the primary interest.” (D. Devore) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (b)(5)(i) Receive Results. Poor match on display all the information, as specified, for a test report: Neither the LTC FP nor the CCHIT LTPAC criteria explicitly identify the ONC specified lab data components

36 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Clinical Decision Support Evidence-based decision support interventions. Linked referential clinical decision support Clinical decision support configuration Automatically and electronically interact Source attributes Drug-drug, drug-allergy interaction checks

37 Clinical Decision Support Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (a)(8)(i) Evidence-based decision support interventions. Fair match on enable users to select/activate CDS interventions Good match on CDS interventions based on problems, medications, medication allergies, demographics & labs Fair match on CDS interventions based on vital signs § (a)(8)(ii) Linked referential clinical decision support. Fair match on identify Dx and therapeutic reference info No match on use of Infobutton standards for reference info No match on reference info available based on each one and at least one combination of specified data § (a)(8)(iii) Clinical decision support configuration. Fair match on user configuration of interventions and resources Poor match on electronic triggering of CDS interventions based on data incorporated in summaries § (a)(8)(iv) Automatically and electronically interact Fair match on CDS triggers occurring when a user is interacting with EHR technology § (a)(8)(v) Source attributes Poor match on all requirements related to source attributes § (a)(2) Drug-drug, drug-allergy interaction checks. Fair match on presentation of drug-drug and drug-allergy contraindications Fair match on user adjustments to alert severity levels § (a)(8)(i) Evidence-based decision support interventions. Fair match on enable users to select/activate CDS interventions: Neither the LTC FP nor the CCHIT LTPAC program state the explicit content (i.e., problem list, medication list, medication allergy list, demographics, lab tests and values/results, and vital signs) for which users have the ability to select/activate clinical decision support interventions. LTC FP and CCHIT requirements do not explicitly require that configuration of clinical decision support interventions and resources be constrained to a limited set of users. Fair match on CDS interventions based on vital signs The LTC FP only reference clinical decision support for vital signs in the context of medication dosing. Neither the LTC FP nor the CCHIT criteria discuss triggering clinical decision support/alerts based on changes in vital sign values (e.g., elevated BP or pulse). § (a)(8)(ii) Linked referential clinical decision support. Fair match on identify Dx and therapeutic reference info LTC FP and CCHIT requirements address providing “access to” reference information. They do not include requirements for the system to “electronically identify” reference information for a user (which connotes pre-configured resources). Poor match on use of Infobutton standards for reference info Neither the LTC FP not the CCHIT criteria address the use of Infobutton standards Poor match on reference info available based on each one and at least one combination of specified data Neither the LTC FP nor the CCHIT LTPAC program state the explicit content (i.e., problem list, medication list, medication allergy list, demographics, lab tests and values/results, and vital signs) for which users have the ability to access reference information. § (a)(8)(iii) Clinical decision support configuration. Fair match on user configuration of interventions and resources Fair match on triggering CDS interventions based on specified native and incorporated data Neither the LTC FP nor the CCHIT LTPAC criteria explicitly require electronic triggering of CDS interventions for med allergies, demographics or vital signs (CDS criteria for these data elements is stated as “provide the ability to” which indicates some user intervention may be required). Note: The LTC FP and CCHIT program include explicit criteria for electronic triggering of CDS interventions based on problems, medications and lab tests/values/results. § (a)(8)(iv) Automatically and electronically interact Fair match on CDS triggers occurring when a user is interacting with EHR technology LTC FP and CCHIT criteria that require automatic/electronically triggered clinical decision support interventions imply, but do not explicitly state, that the alerts are presented when a user is interacting with the EHR technology. § (a)(2) Drug-drug, drug-allergy interaction checks. Fair match on presentation of drug-drug and drug-allergy contraindications LTC FP and CCHIT requirements do not explicitly require drug-drug and drug-allergy contraindications be presented to the user before a medication order is completed and acted upon. Fair match on user adjustments to alert severity levels LTC FP and CCHIT requirements do not explicitly require that adjustments to severity levels of alerts be constrained to a limited set of users.

38 Clinical Decision Support Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: All LTPAC providers need CDS technology. December 12, 2013 “Our research group has … [worked]… to develop, test, and assess the impact of [CDS] systems to detect and manage [ADEs] in the nursing home setting. The systems …require the presence of admission, discharge, transfer, lab, and medication data… I …support of the base EHR definition… which [requires] clinical decision support as a core requirement… I …use AD detection and management as a use case …but there are many additional examples of how [CDS] rules can benefit residents in ….[NHs]…CDS can greatly improve the detection and management of [adverse consequences] and improve [regulatory compliance] and inclusion of medication specific CDS should provide alignment with and support existing federal and state programs... we should try and link [CDS rules] to those harm related events to try and reduce that ” (S. Handler) “the level of opportunity for using “[CDS] at the time of prescribing can be quite significant. For example, …clear opportunity to optimize the way antibiotics are being used and other antimicrobials—not just in the LTPAC setting, but across all health care settings.” (N.Stone)

39 Clinical Decision Support Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “the question around the need for things such as decision support reporting, medication management within the long term post-acute space—I mean, there’s no doubt whether those pieces are needed…there are some core principles around decision supports that still apply whether that individual is in a[LTC] versus in the hospital, those conditions still require that decision support to be there…” (C.Hertel) “… with respect to clinical decision support, there are core principles and good practices that can be imposed or used as guidelines in all systems, but I don't know that that is a certification issue. I see it as a competitive advantage issue, plain and simple…” (J.Damgaard)

40 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Advance Care Planning

41 Advance Care Planning Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (a)(17) Inpatient setting only – Advance Directives Good match on indicate that advance directives exist for the patient Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: All LTPAC settings reported to use/need advance care planning. December 12, 2013 “…there are three things [that EHR certification needs] to take account of. The first is, you have to make clear that the goal is to enable care plans to move across settings and time for very sick and disabled persons…we could require…interoperability of at least a small set of data, the medications, diagnoses, care plans, function, mental status, likely course…secondly—…we need to put the care plans into the records…We need advanced plans in all records, we need to know who the surrogate is, and not just a yes/no. We need to be able to code the major decisions…We need to make the core elements available to the patient, family, and caregiver. These are the most important [LTCPAC] providers, so they have to be involved in seeing the care plan, the record, the likely goals and the likely course. (J. Lynn) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (a)(17) Inpatient setting only – Advance Directives.

42 Advance Care Planning Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “we need to figure out what the presentation layer is that is appealing to patients and families, but to have one record that all parties can tap into, upload to, download from, right through to the end of the person’s life…” (J. Lynn) need to “include anything about Social Services, …anything about housing, …include things about the capabilities of the caregiver” (J. Lynn) “…it is becoming actually harmful and dangerous to have in the electronic record only a yes/no on an advanced directive. Now, a majority of states accept the POLST—we could readily digitize most of the POLST entries, and we could readily scan and attach to the record a real document” (J. Lynn) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (a)(17) Inpatient setting only – Advance Directives.

43 Advance Care Planning –LTC FP & CCHIT 2011 Requirements Not in ONC 2014 Edition
Indicate the type of advance directives completed (e.g., Living will, DNR) Capture, present, maintain and make available for clinical decisions patient advance directives documents and “DNR” orders Indicate when advanced directives were last reviewed Indicate the name and relationship of the party completing the advance directive for the patient See full listing in notes below DC Name: Manage Patient Advance Directives DC cc#2 The system SHALL provide the ability to indicate the type of advance directives completed for the patient such as living will, durable power of attorney, preferred interventions for known conditions, or the existence of a "Do Not Resuscitate order”. DC cc#3 The system SHALL provide the ability to capture, present, maintain and make available for clinical decisions patient advance directives documents and “Do Not Resuscitate” orders. DC cc#4 The system SHALL conform to function DC (Capture Data and Documentation from External Clinical Sources) and capture patient advance directive documents and “Do Not Resuscitate” orders. DC cc#5 The system SHALL provide the ability to indicate when advanced directives were last reviewed. DC cc#6 The system SHALL provide the ability to indicate the name and relationship of the party completing the advance directive for the patient. DC cc#7 The system SHALL time and date stamp the entry of advance directives information. DC cc#8 The system SHOULD provide the ability to capture the date and/or time a paper advance directives document was signed/completed. DC cc#9 The system SHOULD provide the ability to capture the date and/or time advance directive information was received by the provider. DC cc#10 The system SHALL provide the ability to document the location and or source of any legal documentation regarding advance directives. DC cc#11 The system SHOULD conform to function DC (Support for Patient and Family Preferences).

44 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Clinical Quality Measures Capture and Export Import and Calculate Electronic Submission

45 Clinical Quality Measures Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (c)(1) Clinical Quality Measures – capture and export. Fair match for the generic function of capturing data for quality reporting Poor match for capturing data in accordance with the specified Data Element Catalog Fair match for the generic function of exporting data for quality reporting No match for exporting data in accordance with HL7 QRDA § (c)(2) Clinical Quality Measures – import and calculate. No match for importing data file formatted as HL7 QRDA Fair match for calculating quality measures for which the technology is presented for certification § (c)(3) Clinical Quality Measures - electronic submission No match for creating HL7 QRDA files for reporting quality measures to CMS § (c)(1) Clinical Quality Measures – capture and export. Fair match for the generic function of capturing data for quality reporting AND Poor match for capturing data in accordance with the specified Data Element Catalog Generic criteria are specified by the LTC FP serve as umbrella requirements for quality measure reporting. Neither the LTC FP nor the CCHIT criteria require the ability to capture the data required by the specified Data Element Catalog. Fair match for the generic function of exporting data for quality reporting Poor match for exporting data in accordance with HL7 QRDA A generic criterion specified by the LTC FP serves as umbrella requirements for quality measure reporting. Neither the LTC FP nor the CCHIT criteria require the ability to export clinical quality measures using the HL7 QRDA standard. § (c)(2) Clinical Quality Measures – import and calculate. Poor match for importing data file formatted as HL7 QRDA Neither the LTC FP nor the CCHIT criteria require the ability to import data files formatted in accordance with the HL7 QRDA standard. Poor match for calculating quality measures as specified in ONC 2014 edition LTC FP criteria require the ability to calculate and report Quality Indicators and Quality Measures specific to the LTPAC setting. Neither the LTC FP not the CCHIT criteria require the ability to calculate quality measures as specified in the ONC 2014 edition. § (c)(3) Clinical Quality Measures - electronic submission Poor match for creating HL7 QRDA files for reporting quality measures to CMS Neither the LTC FP nor the CCHIT criteria require the ability to create data files for export formatted in accordance with the HL7 QRDA standard.

46 Clinical Quality Measures Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice : All LTPAC providers need technology to capture and calculate QMs. All LTPAC providers use technology to report patient (assessment) data to CMS and CMS calculates QMs. December 12, 2013 “…e-quality measures….if [EHR]certification requirements for LTPAC… were to include… the ability to exchange…interoperable data elements required for good transitions and …longitudinal coordination of care… this could be a quality metric that could drive some of the adoption of the EHR, [and] fundamentally improve the process of care.”(T. O’Malley) “EHR and EMR systems are critical enablers of …quality process and innovation …; the ability for health care workers to deliver excellent patient outcomes and maximize quality of life …in LTPAC settings depends greatly upon these systems.” (S.Ranson) CMS believes that data uniformity…across settings, is critical to facilitate … transfer of information. It’s also what’s needed…to develop and implement measures that can be harmonized across settings... [Regarding CARE data elements:] a lot of data elements related to function had very high inter-rater and validity scoring…about six [QMs] have been developed related to function…function is very central to… the CMS quality strategy…. what is critical is looking at natural patient care flow and identifying data elements that…are clinically relevant and identifying what you need to help guide the patient care.”(S.Mandl) This quote will go on the P/S slide deck: “Lantana is our named contract that supports our efforts towards standing up a CMS assessment data element library and the data governance support, so that once we are able to incrementally move towards uniformity of data elements, the integrity of those data elements are protected.” (S. Mandl) “[Providers] found …that we needed …specific reporting software …we need to add additional staff to meet the assessment criteria as defined by CMS. We're not able to reuse the information that we actually need to provide care, so while at a macro level the intention was right, in the execution, it’s been highly problematic.” (L. Wolf)

47 Clinical Quality Measures Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “… need to look at this as [a] strategy to get …from point A to point B… this will be an incremental approach similar to …[MU], many … [QMs] needed to be transformed for use within an electronic environment… When and how that takes place,… needs to be assessed … some of these requirements are tied to regulatory requirements… information required for LTPAC [QM] should leverage clinical information recorded in the patient record. LTPAC clinical [QMs] should be derived from the quality data model, a framework that encompasses data from EHRs and other sources to manage measures of health. EHRs can than process these clinical [QMs] to guide the collection and reporting of LTPAC quality data. Decision support rules derived from CQMs will then prompt providers to do the right thing…. The same clinical information must be made available for transitions of care…Public and private pairs should agree on and promote consistent and efficient methods for electronic reporting of quality and health status measures across care settings…LTPAC reporting requirements should be harmonized with clinical data required for patient care. .” (C.Kallem) Lantana [is] working with … stakeholders through HL7 processes to …. develop standards for [QM] expression and transmission formats. A lot of that work is … being used as part of …[MU] stage two …and we're ….working with a variety of stakeholders to support enhancement of those standards for …[MU] stage three. There are …differences in the existing transmission formats used in LTPAC settings, so we'll take some time and effort to help streamline those processes. …initial focus is to … help LTPAC providers get the data flowing first by using structured documents with minimum metadata requirements that …allow the information to get …to frontline clinicians and then eventually identify which of those data requirements should be structured to support …secondary uses such as quality measurement. There also needs to be some alignment and harmonization with the quality data model for those clinical quality measures that are currently used in the LTPAC setting. Certainly the quality data model is designed for use within electronic systems, and that would certainly align with the existing [MU] requirements.

48 Clinical Quality Measures Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “Lantana [is] working with … stakeholders through HL7 processes to …. develop standards for [QM] expression and transmission formats. A lot of that work is … being used as part of …[MU] stage two …and we're ….working with a variety of stakeholders to support enhancement of those standards for …[MU] stage three. There are …differences in the existing transmission formats used in LTPAC settings, so we'll take some time and effort to help streamline those processes. …initial focus is to … help LTPAC providers get the data flowing first by using structured documents with minimum metadata requirements that …allow the information to get …to frontline clinicians and then eventually identify which of those data requirements should be structured to support …secondary uses such as quality measurement. There also needs to be some alignment and harmonization with the quality data model for those clinical quality measures that are currently used in the LTPAC setting. Certainly the quality data model is designed for use within electronic systems, and that would certainly align with the existing [MU] requirements.”(C.Kallem)

49 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Public Health Immunization information Transmission to immunization registries. Transmission to public health agencies – syndromic surveillance Transmission of reportable laboratory tests and values/results (Inpatient Only) Optional—cancer case information (ambulatory setting only) Optional—transmission to cancer registries (ambulatory setting only)

50 Public Health Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC § (f)(1) Immunization information. Good match on record, change, and access immunization information § (f)(2) Transmission to immunization registries. No match on create immunization information for electronic transmission using ONC specified standards § (f)(3) Transmission to public health agencies – syndromic surveillance. No match on create syndrome-based public health surveillance information for electronic transmission using ONC specified standards § (f)(4) Inpatient setting only—transmission of reportable laboratory tests and values/results. No match on create reportable laboratory tests and values/results for electronic transmission using ONC specified standards § (f)(5) Optional—ambulatory setting only—cancer case information. No match on electronically record, change, and access cancer case information § (f)(6) Optional—ambulatory setting only—transmission to cancer registries. No match on create cancer case information for electronic transmission using ONC specified standards GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (f)(2) Transmission to immunization registries. No match on create immunization information for electronic transmission using ONC specified standards Neither the LTC FP nor the CCHIT LTPAC criteria address creating immunization information for transmission using the HL7 v2.51 Immunization Messaging standard or HL7 Standard Code Set CVX – Vaccines Administered. § (f)(3) Transmission to public health agencies – syndromic surveillance. No match on create syndrome-based public health surveillance information for electronic transmission using ONC specified standards Neither the LTC FP nor the CCHIT LTPAC criteria address creating public health surveillance information in accordance with the HL7 v2.51 National Condition Reporting standard or the HL7 v 2.51 PHIN Messaging Guide for Syndromic Surveillance. § (f)(4) Inpatient setting only—transmission of reportable laboratory tests and values/results. No match on create reportable laboratory tests and values/results for electronic transmission using ONC specified standards Neither LTC FP nor CCHIT criteria address providing the ability to create reportable lab tests and values/results for electronic transmission § (f)(5) Optional—ambulatory setting only—cancer case information. No match on electronically record, change, and access cancer case information Neither LTC FP nor CCHIT criteria provide explicit requirements regarding the ability to record, change and access cancer case information.

51 Public Health Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: Some LTPAC providers record immunization data. December 12, 2013 “establishing a common language for recording and sharing clinical data could dramatically improve the flow of information from health care providers…as well as to [PH] entities…In 2012, the HAI reporting program …was extended to [LTCHs] and acute [IRFs], which began reporting data to CDC in January of this year…creating the capacity to identify HAI events within EHR systems and transmit data to CDC using interoperable exchange would reduce the burden of data collection for facilities while standardizing…data submission…for all providers. Clinical data “priorities from a [PH] perspective…are medication administration…and laboratory data …data on immunizations and antimicrobials would support…efforts to prevent …transmission of vaccine preventable diseases and reduced …emergence of antibiotic resistant organisms.” (N.Stone) defining a health IT standard for… influenza vaccine administration… would enable…information…exchanged between… providers as well as … state vaccination registries. This could reduce duplication of immunization …among different…providers caring for the same person, reduce… individual’s risk of receiving multiple vaccinations…, and provide [PH] with reliable information and vaccine coverage within communities. (N.Stone)

52 Public Health Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony
ONC 2014 Edition Comparable Criteria in either HL7 LTC FP or CCHIT LTPAC Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “….clear opportunity to optimize the way antibiotics are…used and other antimicrobials—not just in the LTPAC setting…antibiotic stewardship literature … suggest that [CDS] at the time of prescribing is one of the most powerful ways to…influence … provider decision making. (N.Stone) On transitions of care: CDC has a national infection reporting data system (NHSN) that includes information on “positive laboratory identified [MDROs]; for example, [MRSA] or [VRE] or even C. diff. The presence of… infection…is incredibly important for any receiving facility… so that they can ensure… safest care…delivered to that person.” (N.Stone) “we…have a clinical surveillance system…across all… clinical settings, including…[NH] care… for infection prevention, control, for HAI detection management reporting, and… to exchange information about HAIs or [MDROs]…to the next care setting.” (S.Handler)

53 Comparison: ONC, HL7 Functional Profile and CCHIT LTPAC Criteria
Patient-Specific Education Resources

54 Patient-Specific Education Resources Comparison of ONC and HL7 and CCHIT Criteria and HITPC C/AWG Testimony ONC 2014 Edition Comparable Criteria in either HL7 LTPAC FP or CCHIT LTPAC § (a)(15) Patient-specific education resources. Fair match on electronically identify for a user patient-specific education resources Poor match on use of Infobutton standards Good match on use of processes other than Infobutton Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: Use of patient portals reported across all LTPAC provider types. Patient portals are available across all LTPAC provider types. However, frequency and breadth of use is unknown. December 12, 2013 “…all that health happens at home, that the facilities and licensed health services we've been talking about are extremely important, but 75 percent of [LTC] is provided by families in the home, and by non-licensed personnel and agencies going into the home.” (S. Atkins) “we need to figure out what the presentation layer is that is appealing to patients and families, but to have one record that all parties can tap into, upload to, download from, right through to the end of the person’s life…” (J. Lynn) GAP(S) IN LTC FP AND CCHIT LTPAC EHR CERTIFICATION CRITERIA § (a)(15) Patient-specific education resources. Fair match on electronically identify for a user patient-specific education resources Neither the LTC FP nor the CCHIT LTPAC program explicitly requires identification of education resources based on the patient’s problem list, medication list, and laboratory tests and values/results. Poor match on use of Infobutton standards Neither the LTC FP nor the CCHIT LTPAC program specifies requirements related to use of Infobutton standards.

55 LTPAC Setting Specific EHR-S Requirements

56 Federally Required Assessments
Use in Practice CMS requires LTPAC providers to create, maintain, and transmit (in accordance with CMS requirements) assessment instruments assessment instruments and data sets for LTPAC: MDS 3.0, OASIC-C , IRF-PAI, CARE subset for LTCH. LTPAC providers create and use a variety of clinical assessments for a variety of purposes (patient assessment, care planning, internal quality monitoring/improvement, support transition of care, payment, and quality assurance). EHR Criteria in either HL7 LTPAC FP or CCHIT LTPAC Create Assessments The EHR must allow providers to create and make available the following assessments for clinician use: • user-defined assessments reflecting assessment content and protocols; • standard assessments reflecting assessment content and protocols as per industry and professional standards of practice; Federally-required assessment instruments or assessment data in accordance with CMS requirements. From HL7 LTC EHR-S Functional Profile: Function: DC.1.5 (Management Assessments) Priority: Essential Now Statement: Create and maintain assessments. Description: The EHR-S must be able to provide users with the clinically appropriate and regulatory mandated assessments required to be completed during a patient stay. To support this, the system must allow providers to create, maintain, and make available for clinician use: • user-defined assessments reflecting assessment content and protocols as per facility policy (such as Nursing Admission assessments, Dietary admission assessments, Physical Therapy evaluations, etc.), and • standard assessments reflecting assessment content and protocols as per industry and professional standards of practice (such as the Geriatric Depression Scale, AIMS, Mini-Mental, Falls Risk Assessment, etc.) In addition, the EHR-S must maintain and make available for clinician use any standardized assessment instruments (such as the MDS) that are required by jurisdictional regulation. The EHR-S must provide the ability for clinicians to complete these assessments (user-defined assessments, standard assessments, and standardized assessment instruments) and maintain them as part of the electronic patient record. The EHR-S should provide the ability to capture additional data to augment an assessment as necessary, and should link data from the assessment to the patient’s problem list and care plan. Criteria: 1.     The system SHALL provide the ability to create “user-defined” and standard assessments for clinician use in assessing patient condition. 2.     The system SHALL provide the ability to complete, maintain and transmit standardized assessment instruments (such as the Minimum Data Set) as mandated by jurisdictional regulations. 3.     The system SHALL provide the ability to complete and maintain "user-defined" and standard assessments of resident condition as required by: a) the Conditions of Participation for Medicare and Medicaid (i.e., assessments related to resident risk of dehydration, unintended weight loss, or pressure ulcers), b) jurisdictional regulations, c) professional standards of practice, and d) facility policy. 4.     The system SHOULD provide the ability to capture additional data to augment standard assessments relative to variances in medical conditions. 4.     The system SHOULD provide the ability to link data from an assessment to a problem list. 5.     The system SHOULD provide the ability to link data from an assessment to an individual care plan. 6.     The system MAY provide the ability to link data from external sources, laboratory results, and radiographic results to an assessment. 7.     The system MAY provide the ability to compare documented data against standardized curves and display the trends. 8. The system SHOULD conform to function DC (Support for Standard Assessments). 9. The system SHOULD conform to function DC (Support for Patient Context-Driven Assessments). 10. The system SHALL provide the ability to retrieve prior versions of completed user-defined and standard assessments. 11.   The system SHOULD conform to function IN.1.4 (Patient Access Management). 12.   The system SHALL conform to function IN.2.2 (Auditable Records). 13.   The system SHOULD provide the ability to track and schedule mandated assessments. Function: DC (Capture and Manage the CMS Resident Assessment Instrument) Statement: Capture and manage the Minimum Data Set as per CMS regulations Description: The resident assessment process mandated by the Centers for Medicare & Medicaid Services (CMS) includes a standardized assessment instrument (the MDS), triggers and protocols for further assessment (Resident Assessment Protocols), and utilization guidelines that define the frequency, timeliness, error correction process, and data submission requirements for the Minimum Data Set. In addition, some state agencies impose further, more stringent requirements on MDS processes. The EHR-S must provide the ability to comply with all federal requirements related to the MDS, as well as the additional state level requirements imposed by the jurisdiction in which the system is implemented. Note: References to “version” in this function are referring to prior iterations of the mandated assessment instrument. 1.     The system SHALL provide the ability to capture all data elements as defined in the most recent MDS data specification. 2.     The system SHALL perform Medicare payment calculations from MDS data items in accordance with the most recent algorithms provided by CMS and populate the payment calculation value to the appropriate MDS data element. 3.     The system SHALL perform State Medicaid payment calculations from MDS data items in accordance with the most recent algorithms provided by the state agency of the jurisdiction in which the system is implemented, and populate the payment calculation value to the appropriate data element as required by jurisdictional law or regulation. 4.     The system SHALL perform data consistency edits as defined in the most recent MDS data specification. 5.     The system SHALL calculate triggered Resident Assessment Protocols (RAPs) in accordance with the most recent MDS data specification. 6.     The system SHALL provide the ability to capture the clinician assessment process for triggered Resident Assessment Protocols (RAPs). 7.     The system SHALL create MDS data submission files in accordance with the most recent MDS data specifications. 8.     The system SHALL implement MDS data correction and assessment locking processes as defined in the most recent version of the CMS MDS Correction Policy. 9.     The system SHOULD conform to function S (conformance criteria 9 and 10) (Performance and Accountability Measures). 10.   The system SHALL report Medicare payment calculations in compliance with function S (Automatic Generation of Administrative and Financial Data from Clinical Record). 11.   The system SHOULD provide the ability to link data from the MDS to a problem list. 12.   The system SHOULD provide the ability to link data from the MDS to an individual care plan. 13.   The system SHOULD provide the ability to exchange MDS assessment data in conformance with HL7 CDA release 2 or higher. 14.   The system SHALL provide the ability to export MDS data in formats as required by jurisdictional authority. 15.   The system SHALL provide the ability to access, view, report and display all previously completed MDS assessments. 16.   The system MAY provide the ability to capture all data elements as defined in previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 17.   The system MAY create MDS data submission files in accordance with previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 18.   The system MAY implement MDS data correction and assessment locking processes as defined in prior versions of the CMS MDS Correction Policy for purposes of transitioning paper documentation to electronic format. 19.   The system MAY calculate triggered Resident Assessment Protocols (RAPs) in accordance with previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 20.   The system MAY perform data consistency edits as defined in previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 21.   The system SHOULD comply with IN 5.1 (Interchange Standards) Criteria #9 (The system SHOULD provide the ability to exchange federally mandated assessment instrument data in conformance with Consolidated Health Informatics (CHI) format and content standards.)

57 Federally Required Assessments
Use in Practice EHR Criteria in either HL7 LTPAC FP or CCHIT LTPAC Maintain Assessments The EHR SHALL provide the ability to complete, maintain, and retrieve assessments as required by: Federal, State, and other jurisdictional requirements, professional standards of practice, and c) facility policy. Transmit Assessments The EHR SHALL provide the ability to transmit assessment instruments or assessment data as mandated by jurisdictional regulations Re-use Assessment Content The EHR SHOULD provide the ability to re-use assessment data for: various clinical purposes such as: creating a problem list, an individual care plan, and tracking trends; and administrative purposes such as Medicare and Medicaid payment calculation, quality monitoring and reporting, reporting associated with survey oversight. The EHR SHOULD support: the creation and exchange of an interoperable LTPAC Assessment Summary CDA document in accordance with the HL7 IG for CDAr2: LTPAC Summary Release R.1; or provide the ability to upload source assessment documents to a third party for the creation of a LTPAC Summary CDA document. From HL7 LTC EHR-S Functional Profile: Function: DC.1.5 (Management Assessments) Priority: Essential Now Statement: Create and maintain assessments. Description: The EHR-S must be able to provide users with the clinically appropriate and regulatory mandated assessments required to be completed during a patient stay. To support this, the system must allow providers to create, maintain, and make available for clinician use: • user-defined assessments reflecting assessment content and protocols as per facility policy (such as Nursing Admission assessments, Dietary admission assessments, Physical Therapy evaluations, etc.), and • standard assessments reflecting assessment content and protocols as per industry and professional standards of practice (such as the Geriatric Depression Scale, AIMS, Mini-Mental, Falls Risk Assessment, etc.) In addition, the EHR-S must maintain and make available for clinician use any standardized assessment instruments (such as the MDS) that are required by jurisdictional regulation. The EHR-S must provide the ability for clinicians to complete these assessments (user-defined assessments, standard assessments, and standardized assessment instruments) and maintain them as part of the electronic patient record. The EHR-S should provide the ability to capture additional data to augment an assessment as necessary, and should link data from the assessment to the patient’s problem list and care plan. Criteria: 1.     The system SHALL provide the ability to create “user-defined” and standard assessments for clinician use in assessing patient condition. 2.     The system SHALL provide the ability to complete, maintain and transmit standardized assessment instruments (such as the Minimum Data Set) as mandated by jurisdictional regulations. 3.     The system SHALL provide the ability to complete and maintain "user-defined" and standard assessments of resident condition as required by: a) the Conditions of Participation for Medicare and Medicaid (i.e., assessments related to resident risk of dehydration, unintended weight loss, or pressure ulcers), b) jurisdictional regulations, c) professional standards of practice, and d) facility policy. 4.     The system SHOULD provide the ability to capture additional data to augment standard assessments relative to variances in medical conditions. 4.     The system SHOULD provide the ability to link data from an assessment to a problem list. 5.     The system SHOULD provide the ability to link data from an assessment to an individual care plan. 6.     The system MAY provide the ability to link data from external sources, laboratory results, and radiographic results to an assessment. 7.     The system MAY provide the ability to compare documented data against standardized curves and display the trends. 8. The system SHOULD conform to function DC (Support for Standard Assessments). 9. The system SHOULD conform to function DC (Support for Patient Context-Driven Assessments). 10. The system SHALL provide the ability to retrieve prior versions of completed user-defined and standard assessments. 11.   The system SHOULD conform to function IN.1.4 (Patient Access Management). 12.   The system SHALL conform to function IN.2.2 (Auditable Records). 13.   The system SHOULD provide the ability to track and schedule mandated assessments. Function: DC (Capture and Manage the CMS Resident Assessment Instrument) Statement: Capture and manage the Minimum Data Set as per CMS regulations Description: The resident assessment process mandated by the Centers for Medicare & Medicaid Services (CMS) includes a standardized assessment instrument (the MDS), triggers and protocols for further assessment (Resident Assessment Protocols), and utilization guidelines that define the frequency, timeliness, error correction process, and data submission requirements for the Minimum Data Set. In addition, some state agencies impose further, more stringent requirements on MDS processes. The EHR-S must provide the ability to comply with all federal requirements related to the MDS, as well as the additional state level requirements imposed by the jurisdiction in which the system is implemented. Note: References to “version” in this function are referring to prior iterations of the mandated assessment instrument. 1.     The system SHALL provide the ability to capture all data elements as defined in the most recent MDS data specification. 2.     The system SHALL perform Medicare payment calculations from MDS data items in accordance with the most recent algorithms provided by CMS and populate the payment calculation value to the appropriate MDS data element. 3.     The system SHALL perform State Medicaid payment calculations from MDS data items in accordance with the most recent algorithms provided by the state agency of the jurisdiction in which the system is implemented, and populate the payment calculation value to the appropriate data element as required by jurisdictional law or regulation. 4.     The system SHALL perform data consistency edits as defined in the most recent MDS data specification. 5.     The system SHALL calculate triggered Resident Assessment Protocols (RAPs) in accordance with the most recent MDS data specification. 6.     The system SHALL provide the ability to capture the clinician assessment process for triggered Resident Assessment Protocols (RAPs). 7.     The system SHALL create MDS data submission files in accordance with the most recent MDS data specifications. 8.     The system SHALL implement MDS data correction and assessment locking processes as defined in the most recent version of the CMS MDS Correction Policy. 9.     The system SHOULD conform to function S (conformance criteria 9 and 10) (Performance and Accountability Measures). 10.   The system SHALL report Medicare payment calculations in compliance with function S (Automatic Generation of Administrative and Financial Data from Clinical Record). 11.   The system SHOULD provide the ability to link data from the MDS to a problem list. 12.   The system SHOULD provide the ability to link data from the MDS to an individual care plan. 13.   The system SHOULD provide the ability to exchange MDS assessment data in conformance with HL7 CDA release 2 or higher. 14.   The system SHALL provide the ability to export MDS data in formats as required by jurisdictional authority. 15.   The system SHALL provide the ability to access, view, report and display all previously completed MDS assessments. 16.   The system MAY provide the ability to capture all data elements as defined in previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 17.   The system MAY create MDS data submission files in accordance with previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 18.   The system MAY implement MDS data correction and assessment locking processes as defined in prior versions of the CMS MDS Correction Policy for purposes of transitioning paper documentation to electronic format. 19.   The system MAY calculate triggered Resident Assessment Protocols (RAPs) in accordance with previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 20.   The system MAY perform data consistency edits as defined in previous MDS data specifications for purposes of transitioning paper documentation to electronic format. 21.   The system SHOULD comply with IN 5.1 (Interchange Standards) Criteria #9 (The system SHOULD provide the ability to exchange federally mandated assessment instrument data in conformance with Consolidated Health Informatics (CHI) format and content standards.)

58 Federally Required Assessments
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 2, 2013 Clinical Utility and Use in Practice: All LTPAC providers: (i) must complete and electronically transmit federally required assessments /assessment data; and (ii) complete other patient assessments. Assessment data is reused for various clinical and administrative activities. December 12, 2013 “CARE tool data set comprised from uniform data elements was designed to standardize the assessments of patient medical, functional, cognitive, and social support status across acute and post-acute settings” (S. Mandl) CMS requires “the minimum data set for SNFs and NFs, inpatient rehab facility Patient Assessment Instrument, the IRF PAI for IRFs - inpatient rehab facilities, the Outcome and Assessment Information Set or OASIS for home health, and the Long Term Care Hospital Continuity Assessment Record and Evaluation Data Set or the LTCH CARE data set, and a Hospice Item Set. Data is submitted to CMS electronically by providers …using our submission specifications which we post on our CMS website by provider type setting” (S. Mandl)

59 Federally Required Assessments
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “CMS is…exploring movement and capability towards uniformity… I mean… the use of uniform, consistent data elements in multiple settings to enable consistent [QM] capabilities and … foster and facilitate data uniformity—transfer of data. Lantana is our named contractor that supports our efforts towards … a CMS assessment data element library and the data governance support, so that once we are able to incrementally move towards uniformity of data elements, the integrity of those data elements are protected” (S. Mandl) “There are…differences in the existing transmission formats used in LTPAC settings, so we'll take some time and effort to help streamline those processes…initial focus is to try to help LTPAC providers get the data flowing …using structured documents with minimum metadata requirements that then allow the information to get flowing to frontline clinicians and then eventually identify … those data requirements should be structured to support various secondary uses such as [QM].” (C. Kallem) “The handling of the MDS, … census data, care planning, quality assurance activities, by and large …are primarily used for internal operations of the SNF. There are a number of SNFs that would like to be able to transmit data… but the interoperability structure in the state is not terribly well developed for communicating between hospitals and SNFs, SNFs and home health or home care, assisted living. (D. Shreve)

60 Federally Required Assessments
Health IT Policy Committee Certification and Adoption Workgroup Testimony December 12, 2013 “We have to have our reimbursement piece, the MDS, as part of our electronic health record…. (L. Tubbs) “ the RAI [Resident Assessment Instrument] manual currently has some changes that can affect the electronic medical record system with no turnaround time. …the government pushed out the changes, and then the vendors have to create [the] system to integrate. It doesn’t always happen in a timely manner… recently, the RAI manual was updated in Section G with ADLs. … they wanted the cross referencing of therapy documentation along with some interdisciplinary review and comment during the seven day look back period. This causes a gap because the [EHR] currently doesn’t do a cross matrix for matching of those and the therapy documentation usually is narrative, so there has to be opportunity to change that and pull through. It just becomes cumbersome for the end user, who has to then data mine from two different systems. (L. Tubbs) “there’s a strong need for CMS to adopt a minimum criteria for standardized patient health record information to be utilized across all providers and disciplines.” (L. Tubbs)

61 Survey and Certification Requirements
Use in Practice CMS and States conduct quality assurance and complaint surveys in certain LTPAC providers (e.g., Nursing Homes, Home Health, and Hospice Providers) and certifies providers as meeting program participation requirements. The survey process requires resident/patient and staff interviews, observation of care and services being provided, and review the medical record. EHR Criteria in either HL7 LTPAC FP or CCHIT LTPAC Surveyors need complete access to EHR The EHR shall support prompt surveyor access to the complete EHR, consistent with federal requirements.

62 Survey Requirements Health IT Policy Committee Certification and Adoption Workgroup Testimony Clinical Utility and Use in Practice: Federal and State quality assurance surveys are conducted in certain LTPAC provider settings. December 12, 2013 A NF “indicated that they would discontinue a specific EMR they had implemented five months earlier as part of a plan of correction … because the electronic [MAR] kept all Coumadin orders, even when the dosage was changed. The result was that the nursing staff didn't then trust the system and reverted back to reliance on the paper documentation and contacted the medical director frequently to verify the orders. …raise[s] the broader questions of, to what extent can an EMR certification process include disclosure and follow up of any software problems identified, whether it be through the certification program, CMS, or both.” (K. Tritz) Surveyors need prompt and complete access to the EHR to complete surveys as required. (K. Tritz) “It would be interesting to consider if an EMR certification program could also include certain interoperability with this QIS [Quality Indicator Survey] software.” (K. Tritz) “it [is] imperative for the surveyors …to look across modules of the EMR to understand the timeline of how the different care components fit together.” (K. Tritz)

63 Survey Requirements Health IT Policy Committee Certification and Adoption Workgroup Testimony Clinical Utility and Use in Practice: Federal and State quality assurance surveys are conducted in certain LTPAC provider settings. December 12, 2013 “We have to have [as part of our EHR] a regulatory component that CMS requires us to document and for surveyors to filter through during the survey process, so CMS reports as well that are required and standardized for the surveyors to review “ (L. Tubbs)


Download ppt "Comparison of ONC & LTPAC EHR Functional Criteria AND Testimony to HITPC C/A Workgroup (Summary & Detail Slides) January 10, 2014 (Updated 1/17/2014) Jennie."

Similar presentations


Ads by Google