May 29, 2015
Steven Posnack, Director
Office of Standards and Technology
Office of the National Coordinator for Health Information Technology
U.S. Department of Health and Human Services
200 Independence Avenue SW
Washington, DC 20201
Re: RIN 0991-AB93
Dear Mr. Posnack:
This letter outlines the response of the National Federation of the Blind (NFB) to the Notice of Proposed Rulemaking (NPRM) published on March 30, 2015, introducing a new edition of the 2015 Edition health IT certification criteria. We thank the Office of the National Coordinator for Health Information Technology (ONC) for seeking public feedback on this rulemaking.
More specifically, we thank ONC for taking action to address the inaccessibility of health IT as it impacts people with disabilities in the health care industry. Last year, ONC released an NPRM proposing the first edition of this criteria, and we were troubled to see that access for people with disabilities was only considered in the context of blind people as patients; there was no proposed accessibility requirement to ensure equal access for users with disabilities, meaning no assumption was made that blind people might serve as doctors, therapists, receptionists, and other provider roles that need to interact with health IT. NFB and several other blind people responded to that NPRM, pointing out that the proliferation of inaccessible technology in the health care industry and other employment settings has created profound barriers to success for people with disabilities, and ONC should use this certification program as a vehicle to stimulate change and curb the effects of this discrimination. We urged ONC to incorporate accessibility requirements into the rest of the criteria, and it appears our recommendations were internalized. We applaud ONC for taking action.
However, we do have additional concerns and feel that ONC’s approach has not gone far enough. In this letter, we will elaborate in our response to ONC’s proposals regarding accessibility, as well as answer other questions posed in the NPRM.
WCAG 2.0 Level AA for VDT
In the first NPRM and again with this new proposed edition, ONC proposes modifying the regulatory text for the “view” capability in the View, Download, and Transmit (VDT) criterion. If a technology is to be certified for this criterion, it must have the capability for patients to view, download, and transmit their own health care information. The 2014 Edition VDT criterion calls for this functionality to be accessible to patients with disabilities by requiring developers make this piece conformant with the Web Content Accessibility Guidelines (WCAG) 2.0 Level A; ONC proposes updating this for the 2015 Edition and requiring conformance with WCAG 2.0 Level AA.
We affirm our support of this change and strongly urge adoption of WCAG 2.0 Level AA conformance requirements for the “view” capability. While ONC reports that some health IT developers opposed the change, citing the cost and burden to reach Level AA, we contest that feedback. WCAG 2.0 has been available to developers since 2008; it is hardly new, costly, or overly-innovative in its approach to accessibility. Rather, the guidelines are flexible and technology agnostic, so much so that the federal government has already begun to recognize WCAG as a robust metric and adopt Level AA for mandated accessibility. In 2013, the Department of Transportation issued a final rule extending the Air Carrier Access Act regulations to air carrier and travel agent websites, requiring conformance with WCAG 2.0 Level AA. In February of this year, the Access Board released an NPRM proposing to update the accessibility standards for information and communication technology developed, procured, maintained, or used by the federal government under Section 508 of the Rehabilitation Act to align with WCAG. In fact, the Access Board has proposed incorporating WCAG 2.0 Level AA by reference as the official Section 508 standards. Moreover, the Department of Justice in recent settlement agreements to resolve Americans with Disabilities Act enforcement actions has used WCAG 2.0 Level AA conformance as the measure of IT accessibility.
In the NPRM, it cites reports from health IT developers that WCAG conformance tools are somewhat sparse and that they have had difficulty finding viable tools. We disagree with the characterization. A simple Google search for general accessibility tools yields many results, and there are multiple WCAG-specific tools available for web-based applications: Deque’s WorldSpace, SSB’s Accessibility Management Platform (known as “AMP”), Tenon, Compliance Sheriff (although NFB does not recommend this tool), Functional Accessibility Evaluator and AInspector (tools that are not out of beta yet). We suggest ONC point health IT developers to these tools, if the recommendations would facilitate better reception of, and success with, the change.
We also question why ONC is only proposing to move to Level AA for certification of the “view” capability and not the “download” and “transmit” pieces of the 2015 Edition VDT certification criterion. Although the actual downloads and transmissions are mostly “behind the scenes” functions, meaning they fall under the data interchange piece, the option to initiate and authorize such functions still requires interaction and are thus “user-facing.” We recommend ONC extend the WCAG 2.0 Level AA requirement to all of the VDT criterion.
ONC is again requesting public comment on what, if any, challenges exist or have been encountered when applying the WCAG 2.0 standards to a “non-web” application. Should there be reported challenges, we urge ONC to consider that the principles in the underlying success criterion of WCAG are broader accessibility principles that are not limited to just web-based content. There is no reason that the core principles, and the majority of the success criteria concepts, cannot be applied to non-web content. As ONC rightly pointed out, there are not separate guidelines for “mobile accessibility” as the guidelines are applicable to many different kinds of content, web and non-web based, and that in September 2013, the World Wide Web Consortium published “Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies.”
We believe WCAG Level AA is the appropriate metric for all of the functionality and/or content included in the VDT criterion: view, download, transmit, non-web, mobile, etc.
“Accessibility Technology Compatibility” to Address Accessibility for the Blind
ONC proposes adding a new certification criterion, Accessibility Technology Compatibility, or § 170.315(g)(5), in response to the aforementioned concerns regarding discrimination caused by inaccessible health IT. 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 assistive technology that provides text-to-speech functionality.
First, as stated above, we applaud ONC for taking steps to address our concerns. The language in the NPRM accurately reflects the importance of accessibility:
“…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…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 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.”
ONC is documenting the detrimental effects of inaccessible technology in the health care setting, and leveraging this vehicle to stimulate change. We hope this language will carry over into future editions, particularly the next set of mandatory criteria.
Second, while we are happy with some of this language, we are concerned that the requirements of this criterion do not go far enough. § 170.315(g)(5) only requires compatibility with screen readersno other forms of assistive technology are considered. This certification should be based on a measurable technical standard, which we suggest to be WCAG 2.0 Level AA, not reliance upon a fact-based user standard with a single text-to-speech product. Many additional compatibilities and different embedded supports are required in a measurable accessibility metric, so we find it alarming that ONC’s approach is so limited.
For example, Braille capability is just as important as text-to-speech. Many blind people prefer, and most deaf-blind people need, to use refreshable Braille displays to take notes, read notes, or perform a number of other interactive functions. Similarly, contrast and zoom are critical accessibility features for low vision users that do not rely exclusively on screen readers to get access to content. Yet another example is captioning for video and audio, an embedded support found in many technologies to make those applications accessible to the deaf. By focusing on just screen readers, ONC is putting employers in a position where they will continue to rely on ad-hoc testing, accommodations, and retrofitting for countless occasions involving a blind or otherwise disabled employee needing to use a piece of assistive technology that is not compatible with health IT. As written, the requirement is a sound place to start, but it needs to be expanded in order to capture the intended goal of expanding the circle of participation and making accessibility a facet of mainstream health IT. The best way to build upon what ONC has started is to call for conformance with WCAG 2.0 Level AA, or at the least, another robust accessibility metric.
Third, § 170.315(g)(5) is limited to capabilities involved in certification criteria specified at § 170.315(a), (b), and (e). ONC explains that this criterion is limited to § 170.315(a), (b), and (e), 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. This approach is reasonable and the proposal is well-intentioned, but § 170.315(c) and (d) do require user interaction and thus must be part of the criterion. For example, § 170.315(c), Clinical Quality Measures, includes the capacity to capture and query information relevant to health care quality, including recording and exporting clinical quality data. While most of this capability is “behind the scenes” functionality that does not require a lot of interaction, the ability for an administrator to get into the program and run a report is indeed interactive. This is likely to be performed by a quality assurance officer, which very well could be a blind person. Similarly, § 170.315(d) includes the ability to run audit reports, set automatic access time-out, designate who can attain emergency access, and other interactive functions. Granted, this interaction might not be performed by a blind health care provider, but rather a blind administrator who happens to be employed at a health care provider setting, but equal access is just as important. Blind people do work in the IT industry, and blind people need access to the administrator side of the programs to configure and deploy the application. § 170.315(g)(5) must be expanded to also include criteria (d) and (c); at any point when a user can put data in or get data out, consideration for accessibility must be applied. While we concede that § 170.315(f), (g), and (h) are “back-end” functions that do not require input or output, we suggest ONC review their approach to accessibility with a new lens, giving consideration for blind people as administrators needing access to even the most hidden functions.
Section 504 Requires Accessibility
ONC is seeking comment on the extent to which certification to this criterion would assist in complying with this and other applicable federal and state disability laws, and whether certification to this criterion as proposed would serve as a valuable market distinction for health IT developers and consumers. The use of inaccessible health IT, particularly when its use leads to reimbursements from the Center for Medicare and Medicaid Services, is a violation of Section 504; 504 prohibits the use of federal funds to discriminate, and the use of technology that is unusable to an entire population of people is undoubtedly discrimination. Therefore, we urge ONC to adopt the aforementioned changes, and make this criterion mandatory for certification. As a result, the certification criteria will have a significant impact on successful compliance with Section 504 of the Rehabilitation Act, as well as employer compliance with Title I of the Americans with Disabilities Act, federal agency compliance with 508 of the Rehabilitation Act, and the landscape of accessibility in the marketplace in general. Because of the potential violations of 504, the liability of providers and employers under Section 504 will be jeopardized if ONC does not take an aggressive position on accessibility in the health IT realm. Additionally, some states are providing matching incentive payments based on ONC certification, which will trigger additional liability for healthcare providers based on receipt of state funds. The need for ONC to require accessibility is significant. Even with other federal laws, such as Section 508, there is increased exposure to liability for agencies and their contractors when there is no mandatory requirement that vendors meet a clear measure of accessibility. Simply put, accessibility is a fundamental component of compliance with civil rights laws, and ONC must require accessibility in order to facilitate this compliance. Technology has been a game changer, transforming the way our society functions and offering the possibility of expanding the circle of participation. But, because widely-available accessibility solutions are not considered and embraced, people with disabilities are excluded in ways they never were before. And the digital divide not only has devastating effects for people with disabilities; it has resulted in costly and time-consuming litigation against employers and places of public accommodation, many of whom are merely stuck using the ad-hoc accommodations model because they do not know any better, and cannot single-handedly change the market. We often find that ignorance about accessibility, lack of demand generally, lack of streamlined demand, and lack of availability in the market are the biggest contributing factors to the proliferation of inaccessibility. For developers, accessibility has to be considered during the design phase, and advertised. For employers, accessibility has to be considered during the procurement phase, and made a priority in general. For the government, clear and robust metrics must be identified and shared. Then, developers, employers, the government, and consumers have to work together in order to achieve a viable digital marketplace. Large industries, like higher education, the federal sector, and health care can stimulate this cooperation and make broader change because of their significant purchasing power. If ONC adopts our suggested changes, makes that accessibility criterion mandatory, and builds on the solid foundation proposed in this rulemaking for future editions of certification criteria, the office will be making a strong step forward toward achieving this goal.
Conversion of the Certified Health IT Product List
ONC intends to convert the Certified Health IT Product List (CHPL) in its current form to an open data file represented in both XML and JSON with accompanying API functionality. ONC justifies this conversion as a response to multiple stakeholders reporting that the location of test report summaries and details on the list, and the fact that the list is an inaccessible PDF, makes it difficult to access. ONC estimate that this conversion will occur over the next 12 to 18 months. We support this change!
“Accessibility-Centered Design” For Transparency in the Market
As part of a new, broader approach to accessibility, ONC is proposing a new 2015 Edition EHR Certification Criterion, Accessibility-Centered Design, or § 170.315(g)(8). This criterion would require the identification of user-centered design standards or laws for accessibility that were applied, or complied with, in the development of specific capabilities included in a health IT Module or, alternatively, the lack of such application or compliance. We support this addition, as it will bring greater awareness to available accessibility standards, incentivize developers to give greater consideration for accessibility generally, and allow providers and employers to make smart selections with more consideration for, and education about, whether or not the product is accessible to users with disabilities.
ONC has identified an initial list of health IT accessibility-centered design standards and accessibility laws, and authorized health IT developers to either attain certification for this criterion by selecting something from the list, choosing something different, or indicating that they chose to apply nothing. ONC is seeking comment on whether the list of identified standards includes appropriate examples and whether ONC should limit the certification criteria to which this criterion would apply.
We believe the list is appropriate, but not expansive enough. We recommend adding WCAG 2.0 Level AA; even though the World Wide Web Consortium is not a governing body, it is a consensus group with accepted credibility in the industry. Moreover, as stated earlier, many agencies of the federal government are adopting the WCAG guidelines as enforceable regulations for accessibility. ONC does mention Section 508, which, once refreshed, will be harmonized with WCAG, but that refresh is not finished and therefore WCAG must be included in this initial list.
We also strongly discourage ONC from limiting the criteria to which the criterion applies, for the same reasons discussed earlier regarding accessibility for (c) and (d), and regarding the importance of accessibility in general for 504 compliance.
In conclusion, we again thank ONC for considering our recommendations to address the importance of accessibility for health IT in the health care industry, and hope our new suggestions here regarding adoption of WCAG 2.0 Level AA, expansion of accessibility requirements to cover different kinds of assistive technology and apply to more criteria, and our response to other changes are similarly considered and implemented. We thank you for your time and commitment, and hope you will continue seeing NFB as a resource during this rulemaking. If you have any questions about these comments, please do not hesitate to contact me at (410) 659-9314, extension 2218, or at [email protected].
Sincerely,
John G. Paré Jr.
Executive Director for Advocacy and Policy
NATIONAL FEDERATION OF THE BLIND
JGP/lm