Department of health and human services
§ 170.315(a)(1) Computerized provider order entry – medications
Yüklə 1,55 Mb.
|
- Bu səhifədəki naviqasiya:
- 2015 Edition Health IT Certification Criterion
| § 170.315(a)(1) Computerized provider order entry – medications
§ 170.315(a)(2) Computerized provider order entry – laboratory § 170.315(a)(3) Computerized provider order entry – diagnostic imaging § 170.315(a)(4) Drug-drug, drug-allergy interaction checks § 170.315(a)(5) Demographics § 170.315(a)(6) Vital signs, BMI, and growth charts § 170.315(a)(7) Problem list § 170.315(a)(8) Medication list § 170.315(a)(9) Medication allergy list § 170.315(a)(10) Clinical decision support § 170.315(a)(18) Electronic medication administration record § 170.315(a)(20) Implantable device list § 170.315(a)(22) Decision support – knowledge artifact § 170.315(a)(23) Decision support – service § 170.315(b)(2) Clinical information reconciliation and incorporation § 170.315(b)(3) Electronic prescribing § 170.315(b)(4) Incorporate laboratory tests/results The continued submission of summative usability test results promotes transparency and can foster health IT developer competition, spur innovation, and enhance patient safety. With this in mind, we also seek comment on whether there are other certification criteria that we omitted from this proposed SED criterion that commenters believe should be included. NISTIR 7742 Submission Requirements In the 2014 Edition final rule, we specified that the information listed below from the NISTIR 7742 “Customized Common Industry Format Template for Electronic Health Record Usability Testing” (NIST 7742)175 was required to be submitted for each and every one of the criteria specified in the 2014 Edition SED criterion (77 FR 54188). For the 2015 Edition SED criterion, we propose to include the information below in the regulation text of the 2015 Edition SED criterion to provide more clarity and specificity for the information requested to be provided to demonstrate compliance with this certification criterion. The findings that would be required to be submitted for each and every one of the criteria specified in the 2015 Edition SED criterion (and become part of the test results publicly available on the Certified Health IT Product List (CHPL)) are:
There are illustrative tables on pages 11 and 20 in NISTIR 7742 that provide examples of the presentation of test participants and test results data. We specify that all of the data elements and sections specified above must be completed, including “major findings” and “areas for improvement.” Pages 18 and 19 of the NISTIR 7742 contain a table with suggested instructions for data scoring specifically noting that for task success, a task is counted as successful if the participant was able to achieve the correct outcome without assistance and within the time allotted on a per task basis. Likewise, for task satisfaction a 5 point Likert scale is recommended with scores ranging from “1 - very difficult” to “5 – very easy.” The NISTIR 7742 includes several sections: Executive Summary, Introduction, Method, and Results. In each of these sections, there are required data elements – and some of these elements call for the reporting of the number of study participants, their level of experience with EHR technology and other pertinent details. We recommend following NISTIR 7804176 “Technical Evaluation, Testing, and Validation of the Usability of Electronic Health Records” for human factors validation testing of the final product to be certified. In accordance with this guidance, we recommend a minimum of 15 representative test participants for each category of anticipated clinical end users who conduct critical tasks where the user interface design could impact patient safety (e.g., physicians, nurse practitioners, physician assistants, nurses, etc.). The cohort of users who are selected as participants will vary with the product and its intended users; however, the cohort should not include employees of the developer company. We specify the submission of demographic characteristics of the test participants comparable to the table on page 11 of NISTIR 7742 because it is important that the test participant characteristics reflect the audience of current and future users. In accordance with NISTIR 7804 (page 8), we recommend that the test scenarios be based upon an analysis of critical use risks for patient safety which can be mitigated or eliminated by improvements to the user interface design. In lieu of simply providing guidance on the number of, and user cohort for, test participants, we request comment on whether we should establish a minimum number(s) and user cohort(s) for test participants for the purposes of testing and certification to the 2015 Edition under the ONC Health IT Certification Program. New Requirements and Compliance Guidance As we noted in the 2014 Edition final rule (77 FR 54188), examples of method(s) that could be employed for UCD include ISO 9241-11, ISO 13407, ISO 16982, ISO/IEC 62366, ISO 9241-210 and NISTIR 7741. The UCD process selected by a health IT developer need not be listed in the examples provided in order to be acceptable. We do, however, strongly advise health IT developers to select an industry standard process because compliance with this certification criterion requires submission of the name, description, and citation (URL and/or publication citation) of the process that was selected. In the event that a health IT developer selects a UCD process that is not an industry standard (that is, not developed by a voluntary consensus standards organization), but is based on one or more industry standard processes, the developer may name the process(es) and provide an outline of the process in addition to a short description as well as an explanation of the reason(s) why use of any of the existing UCD standards was impractical. Health IT developers can perform many iterations of the usability testing, but the submission that is ultimately provided for summative usability testing and certification must be an expression of a final iteration. In addition, we expect the test scenarios used to be submitted as part of the test results. Last, we note that we do not expect developers to include trade secrets or proprietary information in the test results. Request for Comment on Summative Testing 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 lifecycle. We 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 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? Retesting and Certification 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 (§ 170.550(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. We 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 (§ 170.523). Please see section IV.D.6 of this preamble for further discussion of this proposal.
We propose to adopt a 2015 Edition “quality management system” certification criterion that is revised in comparison to the 2014 Edition “quality management system” criterion. We propose to require, for a Health IT Module presented for certification, the identification of the Quality Management System (QMS) used in the development, testing, implementation, and maintenance of capabilities certified under the ONC Health IT Certification Program. The identified QMS must be:
In the 2014 Edition final rule, we stated that the 2014 Edition QMS criterion was a first step that could be built on in an incremental fashion (77 FR 54191). For the 2015 Edition QMS criterion, we are taking that next step by not permitting health IT to be certified that has not been subject to a QMS and also requiring health IT developers to either use a recognized QMS or illustrate how the QMS they used maps to one or more QMS established by the federal government or a standards developing organization(s) (SDOs). As identified in the 2014 Edition final rule (77 FR 54190), QMS established by the federal government and SDOs include FDA’s quality system regulation in 21 CFR part 820, ISO 9001, ISO 14971, ISO 13485, and IEC 62304. We encourage health IT developers to choose an established QMS, but developers are not required to do so, and may use either a modified version of an established QMS, or an entirely ‘‘home grown’’ QMS. In cases where a health IT developer does not use a QMS established by the federal government or an SDO, the health IT developers must illustrate how their QMS maps to one or more QMS established by the federal government or SDO through documentation and explanation that links the components of their QMS to an established QMS and identifies any gaps in their QMS as compared to an established QMS. We clarify that we have no expectation that there will be detailed documentation of historical QMS or their absence. The documentation of the current status of QMS in a health IT development organization would be sufficient. We propose that all Health IT Modules certified to the 2015 Edition would need to be certified to the 2015 Edition QMS criterion. As such, we propose to revise § 170.550 to require ONC-ACBs follow this proposed approach (please see section IV.C.2 of this preamble for this proposal).
We propose to adopt a new 2015 Edition “accessibility technology compatibility” certification criterion that would offer health IT developers that present a Health IT Module for certification to one or more certification criteria listed in proposed § 170.315(a), (b), or (e) the opportunity to have their health IT demonstrate compatibility with at least one accessibility technology for the user-facing capabilities included in the referenced criteria. In response to the Voluntary Edition proposed rule, we received several comments from health IT users with visual impairments or disabilities. These commenters raised concerns about the lack of accessibility in many health IT products certified under the ONC Health IT Certification Program. Commenters suggested a number of ways in which the certification program could be leveraged to ensure that health IT is accessible to visually impaired and disabled individuals. In particular, many commenters strongly recommended that we require as a condition of certification that health IT be compatible with popular text-to-speech (or “screen reader”) applications and other accessibility technologies. Joined by our colleagues in the Administration for Community Living and Aging Policy and the Office for Civil Rights, we believe that health IT should be accessible to users regardless of their visual impairments or disabilities. The lack of accessibility features in health IT, including the lack of compatibility with third-party accessibility technologies, can place a significant burden on health IT users who are visually impaired or disabled. Without these features, some health IT users may be unable to access the health IT capabilities they and their patients need. Other health IT users may be forced to rely on human intermediaries, revert to paper-based processes, or employ other workarounds in order to perform basic clinical tasks and essential aspects of their jobs. Such limitations and workarounds not only impact the autonomy, productivity, and employment opportunities of health IT users, but also jeopardize patient safety, healthcare quality, and efficiency. For example, without the use of appropriate accessibility technology, there may be an increased risk of transcription errors, miscommunication between clinicians, improperly documented patient health information, and untimely retrieval of patient health information. For these reasons, we strongly encourage health IT developers to consider the needs of visually impaired and disabled users when designing their products, and, where feasible, to integrate accessibility features directly into health IT. We also encourage them to seek certification to this proposed certification criterion. We note that a number of text-to-speech applications exist and are widely used by many visually impaired or otherwise disabled individuals in conjunction with a variety of personal computer and mobile applications that lack built-in accessibility features. Text-to-speech applications may also be combined with voice control software and other accessibility technologies and typically provide a scripting language and/or set of APIs that enable third-party developers to leverage the accessibility technology’s accessibility features in their own software applications. We have also observed that some health IT is already compatible with accessibility technology, including the U.S. Department of Veterans Affairs’ Computerized Patient Record System (CPRS). CPRS is compatible with Job Access With Speech (JAWS), a popular text-to-speech application that enables a computer to verbally describe the controls and content of computer applications. Certification to this proposed criterion would be available (not required) for Health IT Modules presented for certification to any of the clinical, care coordination, and patient engagement certification criteria specified at § 170.315(a), (b), and (e), respectively, because the use of capabilities associated with these criteria necessarily requires that a user provide input into, receive feedback from, or otherwise interact with the Health IT Module. To meet this proposed certification criterion, for each such “user-facing” capability included in certification criteria specified at § 170.315(a), (b), and (e), a Health IT Module would need to demonstrate that the capability is compatible with at least one accessibility technology that provides text-to-speech functionality to meet this criterion. Health IT developers would not be required to license or provide such accessibility technology to users in order to meet the criterion. An accessibility technology used to meet this criterion would also not be “relied upon” for purposes of § 170.523(f). However, it would need to be identified in the issued test report and would ultimately be made publicly available as part of the information ONC-ACBs are required to report to ONC for inclusion on the CHPL (in this case, what was used to demonstrate compliance with this certification criterion) so that users would be able to identify the accessibility technology with which the certified Health IT Module demonstrated its compatibility. We note that all recipients of federal financial assistance from HHS are covered by the requirements of Section 504 of the Rehabilitation Act of 1973 (29 U.S.C. 794) for programs and services receiving federal financial assistance. We seek comment on the extent to which certification to this criterion would assist in complying with this and other applicable federal (e.g., Section 508 of the Rehabilitation Act of 1973) and state disability laws. We also seek comment on whether certification to this criterion as proposed would serve as a valuable market distinction for health IT developers and consumers (e.g., “Health IT Module with certified accessibility features”).
Yüklə 1,55 Mb. Dostları ilə paylaş:
|