Standards: Implementation, Certification and Testing Work group Friday, May 8, :00 Pm-1:30 Pm ET.

Transcription

1 Standards: Implementation, Certification and Testing Work group Friday, May 8, :00 Pm-1:30 Pm ET. Agenda Complete Work group Comments- Group 1 Review Group 2 Comments Edition Certification NPRM The ONC Health IT Certification Program And Health IT Module Group 1 Introduction To Rule: Propose Not To Require ONC-Authorized Certification Bodies (ACB's) To Certify All Health IT Modules To The 2015 Edition meaningful Use Measurement Certification Criteria ( (G)(1) automated Numerator Recording And (G)(2) automated Measure Calculation ). Note That CMS Has Proposed To Include The 2015 Edition meaningful Use Measurement Certification Criteria In The CEHRT Definition As A Unique Program Requirement For The EHR Incentive Programs. Comments Proposal To Remove The Automated Numerator And Denominator Calculations Does Not Apply To CQM Reporting, As Those Reporting Requirements Are Covered By Different Standards. Regarding field Surveillance Of A Deployed System, ONC Should Clearly Articulate What Such A Surveillance Would Entail. Positive That It Recognizes The Deployed Versions Of A Lab-Tested System Vary In Performance From Site To Site, Though Variations Are Often A Result Of Site-Specific Configuration Issues. Alterations To The standard Implementation Should Only Require Documentation If Alterations Affect The Achievement Of Mu Or Other Programs. If ONC Does Not Limit With Specificity What Is Meant By The Audit And/Or The Requirement To Document And Report Changes To The standard Deployment Of The lab-tested System, There Will Most Certainly By Undue Burden On The Vendor, The Site, And That May Threaten The Forward Progress Of The Mu Program. Expanding To Other Care Setting And Health Information Technologies (e.g., HIEs) Is A Sensible Goal But Needs To Be Cognizant Of The Different Business And Technical Requirements And Current Baseline Capabilities Of The Various Health Care Delivery Entities. Implementation, Certification & Testing NPRM Group 2 Assignments Base EHR Definitions Retesting And Certification Safety-Enhanced Design Web Content Accessibility Guidelines Design And Performance Request For Comment On Summative Testing Base EHR Definitions Introduction To Rule: We Propose To Adopt A Base EHR Definition Specific To The 2015 Edition (i.e., A 2015 Edition Base EHR Definition) At And Rename The Current Base EHR Definition At As The 2014 Edition Base EHR Definition. For The Proposed 2015 Edition Base EHR Definition, It Would Differ From The 2014 Edition Base EHR Definition In The Following Ways: It Does Not Include Privacy And Security Capabilities And Certification Criteria. It Only Includes The Capability To Record And Export CQM Data ( (C)(1))

2 Recommend Explicitly Including Security Criteria (D)(1)-(8) In The Base EHR Scope As Removal Could Cause Confusion Premature To Include UDI And The Implantable Device List Be Included Based On Observations Market Current State- Implantable Device Information Is Most Often Recorded In Surgical Peri-operative Documentation Or In Other Systems And Not Directly First Recorded Within Direct Patient Care EHR, Thus May Not Be Available. Current Level Of Adoption For Communicating UDI/Implantable Device Information Is Not Sufficient Available Without Redundant Transcription Ability To Make Use Of Manually Transcribed Data Is Problematic At Best Without Specific Guidance For How The Device Data Is To Be Captured In CEHRT Issue Of What To Do About Historic Data About Device Information That Is Still Current But May Be Maintained In Unstructured Forms Is Not Addressed Purpose Would Be Better Served For ONC To Focus On Supporting Reference Implementations And Pilots For Proving Out The Use Cases Support The Inclusion Of Application Access To The CCDS For The Provider To Provider Use Case ONC Should Not Define Any Prescriptive Requirements For The Architecture Or Deployment Of The Application Access For Support Of Provider Access To The CCDS ONC Should Support Assurance To Include Strong Privacy And Security Features For Access Requirements. Consumer Access To The CCDS Should Be Optional Concern That As Proposed The Criterion May Result In An Emphasis On Enabling Data Requests Rather Than Simply Making Data Available To Consumers Some Elements Proposed are Not Collected By All Providers (depending On Practice Specialty) So Should Not Be Required As Part Of CCDS Include (A)(4) Drug-Drug/Drug-Allergy Interaction Checking For CPOE In The Definition Support (H)(2) As An Equivalent Alternative Means To (H)(1): o Pros: Enables HISP Portability Or Modularity For Pairing Without Mandating A Coupling Of The Two o Cons: Will Require More HISPS To Adopt All Protocols Will Only Work If: 1) HISP Is Aware Of The EHR Transport Capabilities And Can Accommodate; And 2) Sender/Receiver EHR Supports Transfer Protocols Beyond Those To Which It Is Certified. Retesting And Certification Introduction To Rule: We' Believe That ONC-ACB Determinations Related To The Ongoing Applicability Of The SED Certification Criterion To Certified Health IT For The Purposes Of Inherited Certified Status ( (H)), Adaptations And Other Updates Would Be Based On The Extent Of Changes To User-Interface Aspects Of One Or More Capabilities To Which UCD Had Previously Been Applied. Believe That ONC-ACBs Should Be Notified When Applicable Changes To User-Interface Aspects Occur. Therefore, We' Include These Types Of Changes In Our Proposal To Address Adaptations And Updates Under The ONC-ACB Principles Of Proper Conduct ( ). We' Support This Proposal ONC Should Adopt Guidance For ONC-ACBs To Use In Evaluating If User Interface Changes Have Been Made In an Apparent Significant

3 Applying Principles Of Passivity And Non-Passivity To The End User Work flow To Judge Materiality Of The Change Distinguishing What Constitutes A Major Change That Should Be-get SED Retesting Determining When Entirely New Work flows Have Been Introduced Should Be Required To Undergo Such Testing Limit SED Testing To Only One Work flow Per Certification Requirement. Much What Is Proposed Under SED Testing Should Be Folded Into Surveillance Activities (i.e., Assurance To Hold Vendors Accountable For Disclosure And SED Testing Requirements) Vs. Specifying Other Potential Retesting Scenarios Or Requirements ONC Should Not Fix A Monthly Update Cycle But Instead Gear This Requirement To Match To A Given Vendor s Typical Release Cycle For Major And Minor Updates ONC Should Normalize How Major And Minor Updates Appear On The ONC CHPL Consistent Guidance To ONC-ACBs For How Major And Minor Updates Are Represented Disclosure Statements Or Reference Within Certification Details Table Or Version Control Section Indicating Version Number And Date Of Grant Of Certified Status Do Not Dictate Version Numbering Conventions To Vendors. Safety Enhanced Design Introduction To Rule: We Propose To Adopt A 2015 Edition safety-enhanced Design (SED) Certification Criterion That Is Revised In Comparison To The 2014 Edition safety-enhanced Design Criterion. We' Propose To Add Certification Criteria To This Criterion That We' Believe Include Capabilities That Pose A Risk For Patient Harm And, Therefore, An Opportunity For Error Prevention. We' Propose To Provide Further Compliance Clarity For The Data Elements Described In NISTIR 7742 [174] That Are Required To Be Submitted As Part Of The Summative Usability Test Results And To Specifically Include These Data Elements As Part Of The Certification Criterion. Some Of The Criteria Proposed Are More Administrative And Therefore Should Not Require Recruitment Of Clinical End Users For Testing Consider Reducing Testing Burden, Especially For Smaller Vendors And Practices Reduce The Number Of Testing Participants From 15 For Each Category To 10 For Clinical Task And 4 For Non-Clinical Tasks The Minimum For Clinical Roles Should Be A Total Number Across All Clinical Roles And Not By Category Of Clinical Role Descriptive Factors (e.g., Sex, Age, Education) Are Not Evidence Of Correct Use And Application Of User Centred Design Procedures Focus On Summary Descriptor Information That Demonstrates The Participants Have Relevant Perspective Such As Occupation/Role And Professional Experience Clarification Is Needed Regarding Task Standard Deviations (%): Is This Portion Of The Rule Defining The Statistical Procedure To Use For Measuring Effectiveness (which Would Not Make Sense In The Context Of Successes Or Failures) Or The Effectiveness Metric (which Is Not Standard Deviations, But Simply Task Deviations)? Recommend Using Industry Standard, Literature Recognized Satisfaction Measures Such As: o Single Ease-Of-Use Question (which Employs A 7-Point Scale) Or; o System Usability Scale, Or Software Usability Measurement Inventory Recommend Against The Proposed User Satisfaction Rating With A Scale Of 1 To 5 As It Is Not Representative Of An Industry Standard Urge That All The ACBS Include The Full Complete Usability Test Report In The Public Test Report

4 Web Content Accessibility Guidelines Introduction To Rule: We' Reaffirm For Stakeholders That The Proposed 2015 Edition VDT Criterion Includes The WCAG 2.0 Level A (Level A) Conformance Requirements For The view Capability. Propose To Modify The Regulatory Text Hierarchy At (A) To Designate This Standard At (A)(1) Instead Of (A). This Would Also Require The 2014 Edition VDT Certification Criterion To Be Revised To Correctly Reference (A)(1). Also Seek Comment On Whether We Should Adopt WCAG 2.0 Level AA (Level Aa) Conformance Requirements For The view Capability Included In The 2015 Edition VDT Criterion (instead Of Level A) Recommend ONC Postpone Raising WCAG Level To 2.0 Level Aa. Rationale 1. Lack Of Quality Compliance Test Tools 2. Need For Clearer Guidance On Mobile Accessibility Which Would Be Valuable Given Increasing Use Of Mobile Technology ONC Should Do The Following: Support Improvement Of Tools Help Develop Guidance For Mobile Accessibility Revisit Decision On Moving To 2.0 Level Aa Design And Performance Introduction To Rule: We Propose To Revise To Add Paragraph (g), Which Would Require ONC-ACBs To Certify Health IT Modules To Certain Proposed Certification Criteria Under (G). We Propose To Require ONC-ACBs To Certify Health IT Modules To (G)(3) (safety-enhanced Design) And (G)(6) (Consolidated CDA Creation Performance) Consistent With The Requirements Included In These Criteria. Paragraph (g) Also Includes A Requirement For ONC-ACBs To Certify All Health IT Modules Presented For Certification To The 2015 Edition To (G)(4) (quality System Management) And (g)(8) (accessibility-cantered Design). Generally Supportive Of This Proposal Recommend Pattern Requirement After The 2014 Edition Quality System Management Which Permits A Response That no Health IT Accessibility Centred Design Standard Or Law Was Applied To All Applicable Capabilities As An Acceptable Means Of Satisfying This Proposed Certification Criterion Rationale: Avoid The Need For Rewriting The Whole User Interface Which Is Not Feasible For Most EHR's In Situations Vendors Have Legacy Systems Which Were Developed When The Standards For Accessibility-Centred Design Were Not As Mature Recommend Requirement Related To, identification Of User-Centred Design Standard(S) Or Laws For Accessibility That Were Applied, Be Limited To Only The 17 Criteria Proposed For user-centric Design In The (g)(3) Safety-Enhanced Design Request For Comments On Summative Testing Introduction To Rule: We Understand That Some Health IT Developers Are Concerned That The Summative Testing Report May Not Adequately Reflect The Design Research That Has Been Performed Throughout A Product's Life cycle. Request Public Comment Regarding Options That We' Might Consider In Addition To Or As Alternatives To Summative Testing. For Example; If Formative Testing Reflects A Thorough Process That Has Tested And Improved The Usability Of A Product, Could A Standardized Report Of The Formative Testing Be

5 Submitted For One Or More Of The 17 Certification Criteria For Which Summative Testing Is Now Required? What Would Be The Requirements For This Formative Testing Report, And How Would Purchasers Evaluate These Reports? Comments Formative Testing Should Not Be A Required Form Of Testing But That At Most It May Be Alternative / Option To Summative Testing Difficult To Achieve Standardization As Approaches Vary Widely And Are Context-Specific, Results May Be Deployment-Specific Purpose (to Id Opportunities For Design Improvement) Is Inconsistent With That Of Certification Testing Results Of Testing In Development Vs. Testing Of The Final Product May Not Be Useful To Buyers Of EHR / Health IT Solutions Would Need Additional Guidance To Properly Constraint And Direct Would Require User Evaluation At Multiple Stages (burden For Smaller Vendors).