Stay Connected
Complete the form below and join our mailing list.
The RCE sought feedback on the draft QHIN, Participant, and Subparticipant Additional Security Requirements SOP released December 22, 2022.
All feedback received is published below.
“January 12, 2023
Mariann Yeager
Chief Executive Officer
The Sequoia Project
8300 Boone Blvd.
Suite 500
Vienna, Virginia 22182
Dear Ms. Yeager,
The American Academy of Neurology (AAN) is the world’s largest neurology specialty society representing more than 38,000 neurologists and clinical neuroscience professionals. The AAN is dedicated to promoting the highest quality patient-centered neurologic care. A neurologist is a physician with specialized training in diagnosing, treating, and managing disorders of the brain and nervous system. These disorders affect one in six people and include conditions such as multiple sclerosis (MS), Alzheimer’s disease, Parkinson’s disease, stroke, migraine, epilepsy, traumatic brain injury, ALS, and spinal muscular atrophy.
The AAN has concerns with the draft QHIN, Participant, and Subparticipant Additional Security Requirements SOP that would add a requirement that Workforce members and individuals who are authorized users be authenticated at the National Institute of Standards and Technology (NIST) Authenticator Assurance Level (AAL) 2* level in order to access systems with Protected Health Information (PHI). While the Academy certainly places a premium on the importance of protecting the information of our members’ patients, the academy believes that this requirement would add undue obstacles to already overburdened health care professionals. Not only would this requirement disrupt the current practice patterns by requiring additional steps to access shared workstations, but many practice settings would have to revise or replace their existing systems in order to comply with this requirement.
The AAN is grateful for the opportunity to comment on this proposed change and is eager to engage with the Office of the National Coordinator and the Recognized Coordinating Entity as these changes are considered and hopefully revised. Please contact Max Linder, the AAN’s Government Relations Manager at mlinder@aan.com or Matt Kerschner, the AAN’s Director, Regulatory Affairs at mkerschner@aan.com, with any questions or requests for additional information.
Sincerely,
Orly Avitzur, MD, MBA, FAAN
President, American Academy of Neurology
*See NIST SP800-63B for AAL2 types: https://pages.nist.gov/800-63-3/sp800-63b.html#aal2types”
General Feedback and Considerations
“On behalf of our 40,000 members, the American College of Emergency Physicians (ACEP) is pleased to offer comment on these proposed requirements for additional security to access TEFCA Information. As primarily based in hospitals, emergency physicians universally use hospital-provided electronic health record (EHR) technology in the care of the most ill and injured patients within the health care system. This high paced\high stress health care practice has been severely impacted by the implementation of information technology (IT) that is often ill-suited to the work emergency physicians are required to perform. Multiple studies have proven the negative impact of IT in physician burnout, interruption of patient care, and increased time dealing with such systems.
At the same time, emergency physicians are often data starved due to a lack of interoperability between a disjointed healthcare system. In this respect, ACEP applauds the promise that the Trusted Exchange Framework and Common Agreement (TEFCA) offers.
It is with these considerations in mind that we offer the comments contained herein, with the intent of enhancing the effect and efficiency of this program. Thank you again for your consideration.”
Section 3: Definitions
“This policy would benefit from a few additional definitions to help with the deployment of these additional security requirements. Specifically:
Physically Secure Healthcare Location: A healthcare workspace, such as a hospital, clinic, care facility, physician office, etc., where access to EHR systems and equipment is limited to credentialed individuals using facility owned\operated secure devices (e.g. computer work station).
Remote Access to Healthcare Protected Health Information (PHI): Access to EHR systems, Health Information Exchange (HIE), and other such systems containing PHI from a non-secure location (e.g. home office), using personal devices (e.g. smartphone, tablet, laptop, personal computer, etc.).”
Section 5: Procedure
“The primary intent of this policy appears to be a requirement for Two-Factor or Multifactor Authentication in order to access electronic health systems (e.g. EHR) with access to TEFCA Information. While ACEP is in full support of reasonable safeguards to PHI, there is a point at which overly zealous safeguards negatively impact patient care and the well-being of healthcare workers. As currently proposed, we believe this requirement imposed in all healthcare settings will cause healthcare entities (especially hospitals) to avoid participation in TEFCA due to the untoward impact of imposing additional (even onerous) system access procedures.
Currently, physically secure healthcare locations, such as hospitals, require single factor authentication (e.g. user name\password or single biometric) to access hospital work stations, in which clinicians may use several different workstations in the course of patient care. We have even heard of situations where physicians are prevented from accessing Multifactor Authentication because their cell phone was lost, misplaced, or the battery was dead. In the emergency care setting, this would significantly adversely impact patient care.
Current typical security procedures are more than sufficient to protect the hospital’s own PHI and should be more than sufficient to protect TEFCA information.
Remote Access to healthcare PHI, outside of the hospital setting, is typically infrequent and in most cases used for administrative- type purposes or for a single patient inquiry on a single device. Under these circumstances, Two-Factor or Multifactor Authentication is fairly common and would not be a change for most healthcare workers.”
“2FA could raise security in care environments against unauthorized access, but unless this is done by integrating and harmonizing the underlying workflow, 2FA is more likely to make security weaker – people are likely to use each other’s logins to avoid fumbling for 2FA when time is of the essense, or may start writing usercode/pw details on sticky notes, etc.
A better approach may be to increase the level of Real Time Locator Systems, and to use biometrics and proximity keys to log in and identify the user in a faster and more secure way.”
“I am writing to voice my strong opposition to the proposed multi-factor authentication (MFA) rule as it stands. As a leader in interoperability, Boulder Community Health believes in both the access and protection of PHI for providers who need it for patient care. We utilize many security protocols to protect PHI at our organization, including MFA for off-site locations. However, it is clearly apparent to us that the small increase in security offered by MFA on-campus far outweighs the damage it will do to productivity. While on-campus, our providers are extremely busy and every second counts in a hospital or clinic setting when taking care of patients. Imposing MFA in addition to our existing password and badge requirements is an undue burden to our providers.
I appreciate your consideration of the impact of this rule on patient care and balance the need for security with the reality of providing care. We have great appreciation for all that you do to ensure the interoperability of clinical information in our nation.
With Gratitude,
Michael Jefferies, MBA, FACHE, FCHIME
Vice President and Chief Information Officer
Boulder Community Health
(303) 415-8845
mjefferies@bch.org”
“Multi-factor authentication requirements for all staff with access to PHI where the system is connected to the TEFCA, regardless of care location and including shared workstations, would cause high burden of provider burden.
We’re already entering passwords at 50-60x a day, and adding additional MFA requirements would slow down and discourage providers from accessing a useful service as TEFCA. Orgs may also be reluctant to join TEFCA because of this requirement.”
General Feedback and Considerations
“The Care Everywhere Governing Council thanks the RCE for the opportunity to share our feedback about this policy proposal. Membership on the Governing Council is a volunteer, representative position, and Council member expertise includes clinical, IT, and compliance.
We oversee the largest EHR-based interoperability network in the world. Since 2008, our network has facilitated standards-based interoperability with consistent year-over-year growth in exchange. Network members include 20 out of 20 of US News & World Report’s “2022-2023 Best Hospitals Honor Roll,” and 20 out of 20 of Newsweek’s “World’s Best Hospitals 2022 – United States.” Spanning eight countries and over 150 million patient charts exchanged each month, our network participants use Care Everywhere’s interoperability tools to support treatment of ~76% of the total US population.
If this policy moves forward as written, the outcome will be hesitation by healthcare providers to participate in TEFCA, hindering the national goal of improving interoperability. This policy will weigh heavily on the guidance and considerations we share with our network members who are considering TEFCA participation.
Adam Davis, MD, MAS, FAAP, Clinical Informaticist, Sutter Health
Barb Bungard, RN, MSN, CPHIMSS, FHIMSS, Application Manager, Akron Children’s
Brett Oliver, MD, CMIO, Baptist Healthcare System
Clara Lin, MD, FAAP, FACP, Chief Medical Informatics Officer, Seattle Children’s Hospital
Craig Monsen, MD, MS, CMIO, Atrius Health
Francisco Fernandez, MD, Chief Health Information Officer, UC Health
Gabriel M. Coehn, MD, Chief Medical Informatics Officer – Population Health, NYC Health and Hospital
Kara Justi, IT Manager for Population Health, Cleveland Clinic
Karen Bogard, RHIA, MHA, Director of Medical Policy, Mass General Brigham
Melynda Brown, IT Interoperability Manager, Wellstar Health System
Michael B Marchant, Director of Health Information Exchange, UC Davis Health
Michele Whitt, MD, MBA, Clinical Informaticist, OCHIN
Nael Hafez, Chief Information Officer, Pediatric Physician’s Organization at Children’s
Sean Riley, MD, Director of Population Health Analytics & Health Information Exchange, Kaiser Permanente
Tammy C. Grubbs, MHA, BHS, RN, BC, Interoperability Office, Lexington Medical Center”
Section 5: Procedure
“** Authentication – Workforce Members**
The Governing Council has responsibility to manage security of the Care Everywhere network, including proposing modifications to the Rules of the Road that govern network participation. In our many years of running the largest EHR-based interoperability network in the world, neither the Council nor network membership have raised the need for broad AAL2 multi-factor authentication (MFA) to control access to exchanged data or general PHI.
HIPAA requires Covered Entities to implement appropriate, risk-based technical, administrative, and physical safeguards. All of our network members are subject to HIPAA, and some have experience implementing MFA in targeted, high-risk workflows, such as ordering of controlled substances. Expanding MFA to encompass all workforce staff with access to TI or PHI (which is virtually all staff, including providers, nurses, schedulers, billers, registrars, and more) will slow care by disrupting workflows.
A typical provider logs into the electronic health record 30 times per day, with a quarter of users logging in 55+ times per day. Experience has shown a strong inverse correlation between system access burden and provider satisfaction. Requiring MFA to be used every time workforce members access TI or PHI is an unacceptable disruption.
In addition to the workflow disruption, expanding AAL2 MFA to all workforce staff will require additional IT infrastructure, expanding the cost of healthcare. For example, authenticators must be provisioned for all workforce staff. This policy risks pricing smaller providers and critical access hospitals out of participation in TEFCA.
Because of the incurred cost and burden, and the lack of feedback from our network membership regarding the need for broad MFA of all workforce staff, we believe that requiring AAL2 MFA for all workforce members with access to TI or PHI is unnecessary and poses an inappropriate burden. RCE has not provided any evidence that would justify the proposed requirement, nor an analysis of the cost of implementation. We counsel RCE to not pursue this policy.
If RCE believes that existing HIPAA requirements are insufficient to protect TI and PHI, it should work to address it through national policy rulemaking rather than via TEFCA SOP.
If working through national rulemaking is not possible, RCE should release an updated SOP for public comment detailing why you feel a TEFCA SOP is a more appropriate avenue. That updated SOP should also include a cost/benefit analysis that includes real-world estimates of financial and workflow burden caused by this policy. The analysis should define the specific risks that RCE believes are being mitigated by AAL2 MFA with specific evidence supporting that thesis.
In that next draft, RCE should also indicate that AAL2 will be conditionally required using rules-based logic. We note that rules-based application of AAL2 is typical in industry. For example, in Microsoft products this is referred to as Conditional Access Policy and allows organizations to tailor access policies to match multiple risk level scenarios.
Some examples of rules RCE should consider include:
1. When using an on-premises workstation, AAL2 is not required, because access to workstations on-premises is already controlled via physical controls.
2. AAL2 is only required once every 24 hours. Requiring workforce staff to perform AAL2 repeatedly throughout the day is an unacceptable disruption.
3. Workforce staff are permitted to use a “remember my device for 30 days” feature. When selected, AAL2 will not be required again until the 30 days expire.
** Authentication – Individuals **
Adding AAL2 MFA as an additional step for Individuals (and their proxies) to access their health information may introduce an additional barrier to patients accessing their own data and actively participating in their healthcare.
RCE should compile a cost/benefit analysis of how AAL2 MFA will burden Individuals’ access to their own health information. The analysis should include the risks that RCE believes are being mitigated by AAL2 with specific evidence supporting that thesis. An amended SOP should be released for public comment after that analysis is available.
RCE should amend this SOP in the next draft to indicate that AAL2 will be conditionally required for Individuals using rules-based logic. Some examples of rules that RCE should consider include:
1. When using a provider-controlled network, AAL2 is not required. It is common for Individuals to access their data while in a healthcare facility. For example, MyChart Bedside is a patient-engagement platform that includes an admitted patient as an active part of their healthcare delivery. Patients can message staff, review lab & imaging results, and plan their daily schedules. Requiring AAL2 many times throughout the day while the patient is on-premises is disruptive and unnecessary.
2. Individuals may choose to opt-out of AAL2 if they prefer not to participate.
** Audit Trail **
Federal and state regulations already place obligations on Covered Entities and Business Associates to audit system access and retain records. RCE should align with HIPAA rather than requiring a different auditing standard. Such an approach is better for “future proofing” TEFCA policy because RCE will not risk the scenario where regulations are updated in a manner that is incompatible with ASTM E2147-18.
If RCE’s concern is specific to Non-HIPAA Entities (NHEs) who are not subject to federal and state regulations, then RCE should target additional auditing obligations to them without affecting Covered Entities and Business Associates.
** Secure Channel **
We defer comment on TLS v1.2 to vendors developing prospective QHINs.”
I understand the desire for privacy and security, but I think this proposed rule requiring multifactor authentication is unnecessary. Whenever I access a clinical system, it is either on a secure network or I have to use multifactor to access the clinical application. The downside of such a regulation is that it will add significant, ongoing friction to the workflows of every person accessing any clinical system. I would not be surprised if many organizations opt out of TEFCA specifically because of this provision.
I am a busy practicing rheumatologist in the the Chicago area. I am opposed to this requirement which will slow down an already jam-packed office workflow. Please find alternative methods which will not add further burdens to an already overburdened workflow for providers and staff.
“I have been made aware that there has been a proposal to add additional work and burden to clinical staff and clinicians when accessing PHI regardless of where the information is accessed (I.e. in clinics, throughout the hospital, and on mobile secured and managed devices). Clinicians and informatics specialists work diligently on decreasing burden to workflows and providers all the time. Adding a requirement like this would absolutely be detrimental to the clinical world and just might be might be the straw that breaks the camels back. Speaking as a provider, there are so many things that COVID has put a strain on when it comes to healthcare in general, but especially with burnout and needing to care for patients with significantly lower numbers of providers and staff, that adding something like this would be so burdensome and may truly push people further out of healthcare to where we’re even more short on clinicians and staff. As providers, we already worry about our patients and their care outside of our 8-5 jobs, at times even our families take additional strain, because our job never ends, that’s a price we and our families take on to do something we were born to do. Don’t make it harder to find fulfillment in our jobs and put additional barriers between caring for patients by mandating something which requires us to log in multiple times to take care of our patients.
Think about the times you’ve typed in your password wrong, multiple times and how long it can take to get it put in correctly or remember what you changed your password to…now think about that time in a critical situation, or when we’re caring for one of your family members, and we lose precious lifesaving moments and minutes trying to log into the EHR and your family member dies because of this…”
“I’m concerned about the login burden that the authentication requirements may place on providers. As providers move around our hospital they use multiple workstations a day, sometimes in situations where EHR access is urgent such as the emergency department or surgeries. Tap badges + location + the people around you should be sufficient while on site and it’s unclear if this is allowed with the current proposal.
It’s unclear if exceptions for location are accepted for these requirements when I feel they should be. To keep this requirement in place, please provide more information on the expected benefit compared to the time and effort burden to our providers.”
General Feedback and Considerations
“Cleveland Clinic appreciates the opportunity to provide feedback to the Recognized Coordinating Entity (RCE) regarding this draft TEFCA standard operating procedure (SOP). Cleveland Clinic is a not-for-profit, integrated healthcare system dedicated to patient-centered care, teaching, and research. With a footprint in Northeast Ohio, Florida and Nevada, Cleveland Clinic Health System operates 19 hospitals with more than 6,400 staffed beds, 21 outpatient Family Health Centers, 11 ambulatory surgery centers and numerous physician offices. Cleveland Clinic employs over 5,000 physicians and scientists. Last year, our system cared for 2.9 million unique patients, including 10.2 million outpatient visits and 304,000 hospital admissions and observations.
We have significant concerns about the policy proposed in this SOP to implement another complex layer of security measures. If this policy moves forward as written, the outcome will be hesitation by healthcare providers to participate in TEFCA, thwarting the national goal of improving interoperability.
Cleveland Clinic has worked closely with Epic to bring interoperable data into our clinical workflows. Interoperability has been indispensable for the successful coordination of patient care. For example, in the electronical medical record (EMR) system, a patient encounter, lab result, imaging report, and other clinical information can be filed into the area of the chart where native data displays. This allows clinicians to better follow the patient’s health care over time regardless of where the data originated. Essentially, our healthcare providers are accessing exchanged information every time they log into the EMR system.
Requiring multi-factor authentication (MFA) at Authenticator Assurance Level 2 (AAL2) places an additional barrier on accessing and sharing important medical information to coordinate care effectively and would undermine the purpose of an interoperable information system. It also has serious implications for patient safety and quality of care and imposes a significant cost and administrative burden on healthcare providers.
As a member of Epic’s Care Everywhere Governing Council, we agree with the Council’s comments to this proposed policy and join the Council in urging the RCE not to finalize this SOP as currently drafted. We recommend the RCE conduct an impact analysis and subsequently issue an amended SOP for public comment.”
Section 5: Procedure
“Authentication – Workforce Members:
While protecting personal health information (PHI) is critical, we question the need to broaden AAL2 multi-factor authentication (MFA) in order to control access to PHI or exchanged information under TEFCA (TI). Healthcare providers and health systems already have policies and controls in place to protect sensitive information in accordance with federal and state requirements.
HIPAA requires Covered Entities to implement appropriate, risk-based technical, administrative, and physical safeguards. We have experience implementing MFA and other multi-step security processes in targeted, high-risk workflows, such as the ordering of controlled substances and blood product administration. Expanding MFA to encompass all workforce staff with access to TI or PHI (which is virtually all staff, including providers, nurses, schedulers, billers, registrars, and others) regardless of location and at every instance of viewing TI or PHI will markedly slow care, disrupting clinical workflows.
A typical provider logs into the electronic health record 30 times per day, with a quarter of users logging in more than 55 times per day. Experience has shown a strong inverse correlation between system access burden and provider satisfaction. Requiring MFA to be used every time workforce members access TI or PHI is an unacceptable disruption.
Workflow disruption not only contributes to workforce burnout, it negatively impacts patient care. The cumulative time staff take due to AAL2 MFA to access a patient’s medical chart can add to wait times and delay care unnecessarily, impacting patient safety and quality of care.
In addition to workflow disruption, expanding AAL2 MFA to all workforce staff will require additional IT infrastructure, expanding the cost of healthcare. For example, physical authenticators must be provisioned for all workforce staff. This policy risks pricing smaller providers and critical access hospitals out of participation in TEFCA.
AAL2 MFA adds another layer of processes that may serve as a disincentive to sharing and accessing interoperable data. For example, rather than viewing results from an outside lab or imaging study, providers may be inclined to reorder their own tests for patients, resulting in duplicative work and incurring additional, unnecessary costs. Repeated testing and imaging can also impose inconvenience and/or cause discomfort for patients.
Because of the incurred cost and disruption to clinical workflows, we believe that requiring AAL2 MFA for all workforce members with access to TI or PHI is unnecessary. The RCE has not provided any evidence that would justify the proposed requirement, nor an analysis of the cost of implementation.
If the RCE believes that existing HIPAA and federal cybersecurity requirements are insufficient to protect TI and PHI, it should work to address them through the rulemaking process rather than via a TEFCA SOP.
We suggest that the RCE conduct a cost/benefit analysis that includes real-world estimates of financial and workflow burden and impact on quality of care. The analysis should include the specific risks that the RCE believes are being mitigated by AAL2 MFA with specific evidence supporting that thesis. It should also include justification for why the RCE is pursuing these changes via a SOP rather than formal rulemaking. An amended SOP should be released for public comment after that analysis is available.
The RCE should amend this SOP in the next draft to indicate that AAL2 will be conditionally required using rules-based logic. We note that rules-based application of AAL2 is typical in industry. For example, in Microsoft products this is referred to as Conditional Access Policy and allows organizations to tailor access policies to match multiple risk level scenarios.
Some examples of rules the RCE should consider include:
1. When using an on-premises workstation, AAL2 is not required. Access to workstations on-premises is restricted via physical controls.
2. AAL2 is only required once every 24 hours. Requiring workforce staff to perform AAL2 repeatedly throughout the day is an unacceptable disruption.
3. Workforce staff are permitted to use a “remember my device for 30 days” feature. When selected, AAL2 will not be required again until the 30 days expire.
Authentication – Individuals:
Adding AAL2 MFA as an additional step for Individuals (and their proxies) to access their health information may introduce an additional barrier to patients accessing their own data and actively participating in their healthcare. Individuals may struggle with implementing AAL2 MFA every time they need to access their medical record, particularly if they have limited digital literacy.
The RCE should compile a cost/benefit analysis of how AAL2 MFA will burden individuals’ access to their own health information. The analysis should include the risks that the RCE believes are being mitigated by AAL2 with specific evidence supporting that thesis. An amended SOP should be released for public comment after that analysis is available.
The RCE should amend this SOP in the next draft to indicate that AAL2 will be conditionally required for individuals using rules-based logic. Some examples of rules that RCE should consider include:
1. When using a provider-controlled network, AAL2 is not required. It is common for individuals to access their data while in a healthcare facility. For example, MyChart Bedside is a patient-engagement platform that includes an admitted patient as an active part of their healthcare delivery. Patients can message staff, review lab and imaging results, and plan their daily schedules. Requiring AAL2 many times throughout the day while the patient is on-premises is disruptive and unnecessary.
2. Individuals may choose to opt-out of AAL2 if they prefer not to participate.
Audit:
Federal and state regulations already place obligations on Covered Entities and Business Associates to audit system access and retain records. TEFCA standards should align with HIPAA rather than requiring a different auditing standard. Such an approach is better for “future proofing” TEFCA policy because the RCE will not risk the scenario where HIPAA is updated in a manner that is incompatible with ASTM E2147-18.
If the RCE’s concern is specific to Non-HIPAA Entities who are not subject to federal and state regulations, then the RCE should target additional auditing obligations to them without affecting Covered Entities and Business Associates.
Secure Channel:
We defer comment on TLS v1.2 to vendors developing prospective QHINs.”
General Feedback and Considerations
TEFCA is all about trust and security is a trust enabler. As such, we agree with the importance of an appropriately high bar for the security of the TEFCA framework including all systems and people who interact with data flowing through it. We do have some concerns with the specificity with the level of authentication specified in this draft SOP and have concerns it will be a barrier to adoption while not necessarily making TEFCA more secure.
Section 3: Definitions
The definition is clear. It’s application as outlined in Section 5: Procedure is concerning. We do not believe the entire workforce should be assigned a specific security bar but instead the requirements and processes should establish required and desired security levels based on a multi-factorial analysis consistent with other security frameworks. We do caution against taking our comments to mean the SOP should go from “workforce” as a broad catch all towards attempting to delineate the workforce into specific buckets in this SOP. There is a large diversity of roles, settings, systems and data types and it is unlikely to be possible to identify and separate in a manner that is implementable. We instead point to other rules that require entities to perform a security based on their own makeup and risk profiles. Entity specific profiling is consistent with the HIPAA Security Rule as well security frameworks such as HITRUST.
Section 4: Standard
The intended scope of the SOP is clearly delineated in this section.
Section 5: Procedure
“We are hearing concern about the AAL2 requirement for the “workforce” and recommend further collaboration with the provider and developer community before implementing. Based on the extent of the feedback received from our Members and end user, we believe including AAL2 as a mandatory component of TEFCA is likely to lead to a significant delay in the adoption of TEFCA and as such, at this time we do not recommend implementation of the authentication standard as a “shall” but would not object to inclusion as a “should” or consider setting the bar to AAL2 or a functional equivalent.
Security, data access and data exchange are a balancing act between controls, costs (hard and soft costs), access and liquidity. In health care, finding the right balance is a significant challenge given its diverse mix of roles ranging from administrative staff working at dedicated desktop to fully mobile clinicians seeing dozen(s) of patients an hour while interacting with systems and devices. It is no secret that physician burnout is real and that IT systems have been a factor in the decline in physician satisfaction. To focus health care on treating patients while reducing some of the burden of security, many entities have implemented advanced authentication systems and processes that help minimize the negative impact of secure and often frequent authentication (some many times an hour as they access various terminals) while maintaining high levels of security. A comprehensive understanding of the systems, people and processes is necessary to determine the right level of security by role and maintain covered entities obligations under HIPAA and this often means different levels of authentication (as defined by NIST) for different people.
Unfortunately, many of these processes implemented, while secure, are not technically compliant with AAL2. For example, take an emergency department clinician who has to enter and exit multiple patient spaces (rooms, bed, etc) and interact with the electronic data systems that distinctly each require a login not to mention interact with the patient and medical tools and supplies. In order to facilitate the required workflow to provide patient care, a CIO/CISO of that hospital might implement a proximity-centric system using badges or other technologies to login and logout out of applicable systems and devices. The technology implemented to accommodate this may be highly secure and meet the spirit of ensuring a person interacting with systems connecting to TEFCA is properly authenticated, but not necessarily meet AAL2.
Mandating AAL2 for participation could require widespread changes to the security methods and processes for many entities, likely face significant resistance and ultimately negatively affect adoption which serves to hurt the goal of widespread interoperability to the benefit of patients and providers alike. None of this is to say we do not believe AAL2 is appropriate for many roles and specific processes (e.g. controlled substance eRx), but mandating as a SHALL for ALL is a very strict posture that is likely to disqualify many from participation. New technologies that are recognized as AAL2 compliant in the future may change this, but we are not there at this time.
Given the difference between the proposed authentication minimum bar and what is practical within health care settings, we recommend removal of the AAL2 requirement as broadly applied. We further recommend a broader discussion with more stakeholders to better inform the ONC and the RCE on an acceptable approach that maintains a high bar for security in health care and throughout TEFCA, but does not overly disrupt the delivery of care nationwide. We suggest two possible ways to resolve this.
1) Postpone development of this SOP until the initial QHINs are determined and the initial governance of TEFCA is in place. Under that governance, convene all QHINs to work through this SOP with appropriate expertise from the RCE, the QHINs and outside parties as needed using this and other public comments as perquisite The QHINs and the RCE would together suggest new language and standards which under TEFAC would require ultimate approval by the ONC.
2) Work with HITAC to advice the ONC and the RCE on the topic. Given the need for transparency while being able to get the work done, it would likely make sense to begin this as an agenda topic for the full HITAC but then be sent to a working committee to provide more detailed insights and recommendation.
Without more thoughtful discussion, debate and consensus building, we are fearful the result will be low participation in TEFCA with potential for large scale resistance to future rulemaking that makes participation in TEFCA less voluntary.”
“The proposed requirement that “”Workforce members who are authorized users of systems which access TI or Protected Health Information (PHI)… be authenticated at Authenticator Assurance Level (AAL) 2″” is far in excess of legal requirements or industry standards, and does not meaningfully improve security. An individual who can physically appear at a terminal in a clinical location and present credentials has already shown “something they know” – the credentials – and “something they have” – the terminal. MFA in this context is redundant.
More generally, there is no benefit to these terms mandating end user behavior in detail. Privacy and security can be maintained by requiring that participants comply with HIPAA standards.
Staff who access the EHR generally do so dozens of times per day. These include physicians, other clinicians, and non-clinical staff such as clerks. Requiring AAL2-compliant authentication at each login would consume a measurable part of each user’s day, even if the process was optimized, and would cause a measurable loss in patient care time.”
“For Section 5: Procedure, we are submitting our strong opposition for the proposed requirement to require Workforce members who access TI or PHI from a system connected to the TEFCA network to be authenticated at the Authenticator Assurance Level. Many of the clinicians in our organization follow a workflow that necessitates them to log on or log off numerous times in a single work shift. This can be due to the frenetic nature of their daily routines (e.g. An emergency physician needing to log on to different workstations while seeing multiple urgent/trauma level patients). It can also be due to the EHR system’s automatic access time-out that logs them out after a set period.
In both scenarios, compelling a clinician to perform MFA (multi-factor authentication) would be hugely detrimental to their existing routines of logging on to the EHR. It will undeniably contribute to additional time spent away from providing care to the patient. Incorrectly entering credentials to more than one authentication method will lead to clinician frustration and system fatigue that can have a direct effect on patient care quality.
It is also worth noting that when our clinicians access EHR systems, which in turn will be connected to the TEFCA network, it already benefits from the security afforded by the hospital’s network infrastructure that include firewalls, access control and intrusion prevention systems. One counter-proposal to the proposed MFA requirement is to mandate clinicians to dually authenticate when logging in to a system remotely which places them outside of the hospital IT network. When the clinician is logging in within the hospital’s secured network, MFA will be mandated during the initial log-in for the day or once every 24 hours but will allow single-factor authentication otherwise. We believe this is an acceptable trade-off that doesn’t put undue burden to clinicians working with health systems while not compromising clinical data security.”
The proposal for multifactor authentication in a medical office would impose a burden on the practice which is unacceptable. Staff, including medical assistants, nurses and physicians move from room to room in short time intervals. Prolonging the time required to access electronic medical records will disrupt workflow and hinder already overburdened staff. Please take this into account going forward.
“The requirement “”Each QHIN, Participant, and Subparticipant shall require that Workforce members who are authorized users of systems which access TI or Protected Health Information (PHI), (including those who request TI or PHI, or request TI or PHI be sent to a third party) be authenticated at Authenticator Assurance Level (AAL) 2″” will add burden on our clinical users. Currently, our clinicians are able to access our EHR using Tap and Go access via their badges. Changing this to require 2FA every time they log in will cause excessive burden. I also worry, that given how much burden this will cause, this may be a reason some organizations decide against joining TECFA.
While I understand the need to protect healthcare data, hospital and healthcare organizations are already bound to strict security requirements for how data is protected and TEFCA should align with them. There are likely good use cases for AAL2, Individual access being one of those use cases, but I do not think that requirement makes sense across the board.
Please reconsider this requirement and allow more flexibility.”
Download Letter Response (PDF)
“Feedback Regarding: The Selection of Authentication Assurance Levels (AAL)
DirectTrust generally agrees with the Authentication Assurance Levels (AAL) selected by the RCE for both workforce and individuals. However, the risk profiles of the workforce and the impact of selecting an AAL2 assurance level is not consistent across the workforce members that would be subject to this IG. The information below is offered as additional context to the RCE to make a risk-based decision concerning the appropriate AAL for workforce members by taking into consideration the various types of actors that may be impacted. It may be valuable to establish different expectations for different circumstances.
In principle, selecting any assurance level is a determination regarding the appropriate risk management. Risk management often observes three distinct, and sometimes competing, security objectives defined by FIPS 199:
Confidentiality: Keeping data secret except to authorized parties
Integrity: Keeping data intact with provenance concerning it’s origin; and
Availability: Access to data when needed.
NIST SP 800-63-3 defines a rather lengthy risk assessment process that is designed to determine the appropriate assurance level for a given system. Unfortunately, this IG encompasses many systems, which may make the guidance difficult to observe.
As a result, DirectTrust offers the following examples to illustrate the general approach to risk management using FIPS 199.
Example 1: A physician is authenticating to a healthcare system from an off-campus location that is also off the healthcare organization’s network (no VPN).
Confidentiality: Keeping the healthcare data that the provider intends to access is a high-value objective.
Integrity: Ensuring the integrity of the healthcare data that the provider intends to access is also a high-value objective.
Availability: While ensuring the data is available to access is also a high value objective, the speed in which the physician accesses the data (measured in seconds or minutes) is not as important at protecting confidentiality and integrity.
Result: AAL2 offers strong multi factor authentication which allows the data to be secured from a remote location, even if the authenticators may take longer to use than AAL1 authenticators. In such a circumstance, we believe AAL2 is an appropriate assurance level.
Example 2: A physician is authenticating to a healthcare system from an on-campus location or a location that is connected to the healthcare network (e.g. VPN) using strong authentication, where healthcare services are being administered to a patient.
Confidentiality: Keeping the healthcare data that the provider intends to access is a high-value objective.
Integrity: Ensuring the integrity of the healthcare data that the provider intends to access is also a high-value objective.
Availability: Both the availability of the data and immediate access to the data may be a very high-value objective. In some cases, this objective may be of higher value than confidentiality and integrity objectives if a patient’s immediate health is in jeopardy.
Result: While AAL2 offers strong multi factor authentication, which allows the data to be secured, the increased time or physical interaction required to activate AAL2 multi factor authenticators could be observed as a higher risk than confidentiality and integrity. In such circumstances, DirectTrust recommends taking a close look at the risk profile to ensure AAL2 is appropriate. If AAL2 is still deemed appropriate by the RCE, then DirectTrust recommends publishing additional guidance concerning which authenticators defined in NIST SP 800-63B Section 5.1 are most appropriate when immediate access to the system is required by the workforce member. Cryptographic authenticators that indicate the physical presence of the physician should be given priority in these circumstances, such as those defined in sections: 5.1.6, 5.1.7, 5.1.8 and 5.1.9. The RCE should consider the use of biometrics as activation data used with a physical authenticator. The RCE should also consider suggesting authenticators that support NFC or Bluetooth in support of hands-free authentication.
Additionally, given the risk analysis above, DirectTrust believes AAL2 for individuals is appropriate.
Feedback Regarding: Audit
Participants and Subparticipants will often not be healthcare organizations and will often not be responsible for managing designated record sets. It is very reasonable to require these entities to record and archive audit logs for all transactions processed, including for each the date/time received and/or transmitted, a transaction identifier, the entity received from or sent to, and possibly other high-level information; however, it doesn’t seem reasonable to require that organizations that are not Covered Entities and that are not responsible for managing a Designated Record Set store the entire transaction for a minimum of 10 years. Requiring this level of record keeping for such entities may actually increase the attack surface and risk of data breach of an individual’s healthcare information by requiring that PHI be replicated and stored in multiple locations and for a lengthy period.
This comment relates to an excerpt from ASTM E2147 – 18 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems:
4.1 Data that document health services in health care organizations are business records and shall be archived to a secondary but retrievable medium, and readily accessible, such as data that would be archived in a server or cloud storage. Audit data shall be retained for as long as the medical record is maintained, and may not be destroyed before the medical record may legally be destroyed, and in any event, for at least 10 years or for two years after the legal age of majority, unless a longer period of record retention is prescribed by state, federal or other law or regulation.”
“The requirement for two factor authentication when accessing clinical charts represents an additional burden on clinicians by increasing time spent on administrative tasks and cognitive load during clinical care. Over a 10-hour shift, a clinician may login to access patient charts around 30-50 times. Even with streamlined authentication methods such as card swipe, the extra time can add up to hours of clinician time over the course of a year. When additional “hassle factors” of dealing with absent, broken, or miscoded cards or machines is accounted for, the amount of time skyrockets.
Our clinical workforce is already suffering death by a thousand cuts of “insignificant” administrative tasks that add up to take time away from clinical care and decision making, pushing charting time into personal hours and eroding well-being. A move to increase the amount of time spent authenticating identity is a move in the wrong direction, further burdening an injured workforce.
Consideration of the well-being of our clinical workforce is of utmost importance. We want sensitive and private care for patients. To do this, we need healthy clinicians.”
This feedback is in regards to requiring multi-factor authentication regardless of care location and shared workstations. For any remote access outside of our Duke network and for any non shared clinical workstation, we do require multi-authentication. For our share clinical workstations, we have streamlined to access for our clinicians leveraging “tap badges” that do require authentication every 10 hours to streamline the access and login and logout process that occurs many many times a day. We also have increased the length of our password to 12 characters for further strength. To require our clinicians to re-enter their password at every login will significantly increase their time to login and reduce the time they have taking care of patients which is what they should be doing. Securing PHI within our environment is our responsibility and the penalties are severe enough already if PHI isn’t secure. Do not continue to add cost to healthcare by adding even more hurdles and burden to our providers.
“Emory Healthcare, part of Emory University, is comprised of 11 hospital campuses, 250 locations and nearly 24,000 employees, and is the most comprehensive academic health system in Georgia. Emory Healthcare (EHC) is committed to the responsible sharing of health data, and supports the use of security controls for Trusted Exchange Framework and Common Agreement (TEFCA) Information (TI) that are commensurate with risks to the confidentiality, integrity, and/or availability of the TI. EHC appreciates the opportunity to submit comment on the specifications set forth in the Standard Operating Procedure (SOP): QHIN, Participant, and Subparticipant Additional Security Requirements.
Healthcare provider organizations are experiencing unprecedented financial and labor challenges. Clinician overburden is extreme, and many clinicians are retiring or leaving the field in response to these factors. At the same time, there are increasing malicious attacks on health data security and privacy. These circumstances can only be effectively addressed by innovative solutions that simultaneously reduce overburden and enhance security. EHC urges the Recognized Coordinating Entity to prioritize the following considerations in evaluating potential solutions:
While it will be tempting to recommend more rigid requirements using conventional approaches, we are convinced that with an appropriately innovative mindset solutions can be identified that provide better security with less effort.”
General Feedback and Considerations
This would add a massive impact to our clinicians and workflows if MFA is required during each session and I am not sure it is a realistic and reasonable requirement.
Section 5: Procedure
Massive impact to workflows with the potential of negatively impacting patient care. MFA on each session is unreasonable. Perhaps a timeout period of 8hrs would be a more balanced approach.
General Feedback and Considerations
“Thank you for the opportunity to provide feedback on draft additional security requirements for QHINs, Participants, and Subparticipants.
–Minimize the Scope and Burden of Additional Requirements Adopted by SOP by Aligning Expectations with Requirements from HIPAA, ONC Certification and Other Existing Program Expectations–
Although we appreciate the RCE’s objective of providing additional specificity to prospective QHINs, Participants, and Subparticipants of TEFCA, adopting additional technical and policy requirements through numerous SOPs, each of which are individually subject to revision in the future, increases the burden faced by stakeholders in tracking and adhering to TEFCA’s requirements. Implementing material new requirements on TEFCA entities through SOP will slow onboarding. Developers of health IT used by Participants and Subparticipants to connect to QHINs may need to update their products, and Participants and Subparticipants may need to purchase or implement new tools to accommodate the new requirements.
The RCE should evaluate opportunities to align the requirements in its SOPs and specifications with requirements of ONC certification, HIPAA, and other existing regulatory framework. Since a significant proportion of prospective Participants and Subparticipants will be HIPAA covered entities, business associates, and/or users of certified health IT, this would provide clarity on where stakeholders can rely on existing technology and processes, and where they may need to adopt changes before onboarding to the TEFCA network. It would also reduce the cost and effort required for those stakeholders to join TEFCA.”
Section 5: Procedure
“–Authentication–
Requiring workforce members to authenticate to AAL 2 will impose significant cost and administrative burden on prospective TEFCA Participants and Subparticipants and will act as a barrier to entities connecting to the TEFCA framework that are already HIPAA Covered Entities or Business Associates. The scope of the requirement would, as currently framed, require nearly every user of an EHR to authenticate to AAL 2 at each login to the system, since nearly all users (including clinical, billing, administrative, and IT support) would potentially encounter PHI in the course of their normal activities. The RCE should remove this specific Authentication requirement and instead continue to rely on compliance with the HIPAA Security Rule (for HIPAA regulated entities and Non-HIPAA entities) as an indicator that an actor is appropriately positioned to exchange and protect TEFCA Information.
Healthcare provider organizations and their Business Associates regulated by HIPAA already must implement appropriate physical, technical, and administrative safeguards to protect the integrity of PHI in their stewardship. This regulatory framework does not prescribe the use of specific technologies. Instead, it gives actors the flexibility to assess their own unique risk factors when designing and implementing controls that mitigate risks to PHI. Actors are expected to routinely assess risks to the confidentiality and integrity of health information in their stewardship.
Network-based interoperability through Carequality, Care Everywhere, and other networks is widespread and connects thousands of participating healthcare organizations and facilities, the vast majority of which are Covered Entities under HIPAA. Stakeholders participating in exchange today would have already assessed the risks to PHI under their stewardship stemming from their participation in health information exchange. Few, if any, have implemented AAL2 authentication requirements across their workforce as described in this proposed SOP. This demonstrates that information security and privacy experts across the healthcare ecosystem have determined that AAL2 authentication for the healthcare provider workforce with access to interoperability tools is not a reasonable, necessary, or proportionate response to the risks associated with health information exchange. Instead, stakeholders have identified that health information exchange increases the risk that PHI will be compromised in transit, and focused on the implementation of controls to mitigate that risk, such as encryption of transmitted data to render intercepted data unusable. Stakeholders have also implemented controls that protect against injection-based attacks from transmitted information.
If the RCE believes that TEFCA will create risks that are not present in current exchange frameworks that warrant AAL2 authentication across the workforce of Participants and Subparticipants, it should clearly enumerate them and provide an explanation of why it believes its proposal is the most cost-effective manner to mitigate such risks. When evaluating the efficiency of its proposal, the RCE should consider that the median healthcare provider using Epic’s software logs into the system 30 times per day, and the upper quartile of users logs into the system more than 55 times per day. Authentication at AAL2 could add an additional 5-15 minutes of time spent logging in per day for each of those users. It would also require IT departments to purchase additional authenticators and software to provision to each of the system’s end users.
The RCE should only apply this proposal to the workforce of QHINs, not Participants and Subparticipants. If it proceeds with this proposal for all TEFCA actors, it should adopt changes to reduce the cost and administrative burden it will impose. Specifically, the RCE should:
– Only apply the AAL2 authentication requirements for remote access to the Participant or Subparticipant’s system, since on premises access would be controlled by physical safeguards (since Participants and Subparticipants must comply with relevant sections of the HIPAA Privacy and Security Rules).
– Require AAL2 authentication only once every 24 hours, instead of requiring it at each system login event.
– Allow implementation of “remember my device features” that require re-authentication at AAL2 only once every 30 days. This would be analogous to the security measures used in API-based access to health information, which permits the use of refresh tokens.
–Audit Trail–
The RCE should refer to the requirements of ONC certification instead of a direct reference to ASTM E2147-18 in this section. The vast majority of provider organizations engaging in health information exchange today use ONC certified software, which is required to adhere to the audit logging requirements at 45 CFR 170.314(d)(2). The requirements of certification were designed in part to support healthcare provider organizations’ compliance with HIPAA requirements for audit logging and record retention. Aligning expectations here will provide clarity to Participants and Subparticipants that they can potentially use the capabilities included in their ONC-certified software to meet the security expectations of the TEFCA network. It will also reduce the risk that the expectations of this SOP differ from other regulatory expectations that Participants and Subparticipants might have in the future if other audit logging expectations change.
–Secure Channel–
We agree that the RCE’s proposal in this section will secure information exchange in the TEFCA ecosystem in an appropriate manner.”
Every computer log-in between in the exam room and my office several times daily adds up to a significant amount of time. Currently we are able to swipe our name badges to log in to various workstations. The thought of changes concerns me. Back when we needed to enter login and password on the keyboard we’d need to worry about caps lock and erroneous typing that would slow down the clinic workflow and detract from patient care. I think our current security of swiping a name badge has adequate security for protected health information without risking distractions on getting the right log in information while in front of the patient and trying to discuss their presenting concerns.
“Regarding the below section:
4.2.3 Reauthentication
Periodic reauthentication of subscriber sessions SHALL be performed as described in Section 7.2. At AAL2, authentication of the subscriber SHALL be repeated at least once per 12 hours during an extended usage session, regardless of user activity. Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 30 minutes or longer
My interpretation of this documentation would require most hospitals that participate in the network to change their EMRs as most will not have 2 factor authentication requirements as stringent as this guideline describes. I think this requirement is likely to be a significant deterrent in participation in the network. I’m quite sure the clinicians I represent will find the burden of this authentication policy significantly outweighs the benefit of participation in the network.”
Please reconsider the requirement for multi-factor authentication on log in. It is practically impossible and is so burdensome that organizations are likely to opt out of TSFCA because of this requirement. An average hospital-based physician or a nurse logs into their EMR 25-40 times a day. By adding even few seconds to each log in, we would be adding an additional cognitive burden on an already burnt-out staff.
General Feedback and Considerations
Other than our comments noted on the Procedure section regarding Authentication, Health Gorilla does not have any specific concerns about what is being proposed. However, we encourage the RCE to apply these updates by amending existing documents, such as the QTF re: the very minor clarification in the ASTM E2147 version. We note that the proliferation of multiple documents covering similar topics could cause confusion for stakeholders, especially when Participants and Subparticipants are covered by the requirements. Amending documents is particularly attractive as an option during this brief period when no Designated QHINs exist and the RCE therefore has broad leeway to make amendments.
Section 5: Procedure
“Health Gorilla understands the intent behind proposing Authenticator Assurance Level (AAL) 2 for all Individuals and Workforce members. We believe, however, that the proposed language could be improved in two specific areas.
First, we encourage the RCE to consider whether the requirement should be imposed only on QHINs. It is not necessarily guaranteed that systems used by Participants or Subparticipants will support authentication at AAL2. It may be that some desired types of users who are underserved by existing national interoperability networks or frameworks may be systematically more likely to have more basic systems that do not support this capability in all cases. To the extent that Participants or Subparticipants do have the capability within their systems to deploy authentication at AAL 2, but have not yet done so, the requirement to do so for TEFCA participation could be a disincentive to such participation. Finally, to those Participants and Subparticipants who have both the capability and general willingness to deploy authentication at AAL 2, the concerns noted below for QHINs would apply to such Participants and Subparticipants, as well.
In the context of QHINs themselves, it is more reasonable to require authentication to AAL 2 by the QHIN’s own Workforce. However, we encourage the RCE to consider being more specific in its requirements. The language as proposed does not distinguish between Workforce members who do not have any role-based access to TI or TEFCA-related functions, from those who do. Further, the existing language does not account for efficiency mechanisms such as requiring multiple factors only once per month or other reasonable time period, for devices very commonly used by the same Workforce member and/or that are within secure areas of the organization’s facility and thus require the Workforce member to have passed physical security barriers to gain access to the device.
In general, while we understand the intent to raise the security bar for the QHIN network, we are concerned that the language as written may create barriers to participation and have unforeseen, negative operational impacts.”
General Feedback and Considerations
“As a national trade organization of electronic health record (EHR) developers, the HIMSS Electronic Health Record Association and our 30 member companies appreciate the opportunity to provide feedback on the QHIN, Participant, and Subparticipant Additional Requirements SOP.
While we generally agree with the goal of providing secure access to data by authorized users, we suggest that the proposed approach does not consider existing controls, the prerogative of providers as Covered Entities to be responsible for making the determination of what authentication methods are appropriate for their workforce under HIPAA based on their own understanding of their risk, nor the substantial end-user workflow changes that would be required. Further, the benefits of investments necessary to support the changes in processes and infrastructure to achieve the proposed approach are unclear. As such, the EHR Association suggests narrowing the scope for workforce authentication requirements and auditing standards. We recommend workforce authentication requirements be applied only to the QHIN workforce, with specific consideration given to participants and sub-participants who are not HIPAA Covered Entities. Auditing standards should align with those in place under the ONC Certification Program.”
Section 3: Definitions
“The general definition of “Workforce” seems broad, while the Procedure section narrowly applies it to specific actors involved with the Trusted Exchange Framework. The EHR Association recommends that the more narrow definition of Workforce be used in this SOP to avoid confusion.
The EHR Association further suggests that the definition of “Individual” be stated here as well for completeness, as we understand this to be a patient, consumer, or proxy exercising their individual right of access.”
Section 4: Standard
While the general definition of the standards is reasonable, we suggest that adjustments may be necessary to focus on QHIN and non-covered entities more specifically, given our recommended revisions to the section above.
Section 5: Procedure
“The EHR Association is concerned that the AAL2, multi- or two single-factor authentication requirement for the entire workforce across QHINs, Participants, and Subparticipants is too broad to be feasible in the current exchange environment.
Currently, the recommended authentication approaches are typically implemented only for targeted use cases, such as e-prescribing in which such authentication is necessary to comply with controlled substance prescribing regulations. Organizations are otherwise not required to deploy the proposed approaches, and there is no reason to consider TI any different from other information that a covered entity currently manages and provides access to users with current controls. Introducing additional authentication requirements for all use cases in which a user is accessing TI or PHI effectively requires that users interacting with PHI must always be subject to these requirements, as isolating the scenarios where they truly are requesting and interacting with TI would interrupt workflow. Additionally, many of the interactions involving TI would be orchestrated by the system on behalf of the provider organization, not necessarily under the authentication of any specific user.
Further, the imposition of this requirement on providers as Covered Entities proposed by this draft SOP encroaches on the prerogative of those Covered Entities to determine their own compliance posture based on their risk assessment, as is required by the HIPAA Security Rule, and the technical security measures appropriate to mitigate identified risks and threat vulnerabilities. We note that extensive network-based interoperability already takes place, and Covered Entities would have assessed the risk under HIPAA and determined that AAL2 is not a control that appreciably mitigates risks associated with network interoperability. The EHR Association strongly urges that the RCE not dictate required technical security measures that would contradict or constrain the use of those that such Covered Entities already have determined for themselves for user authentication not otherwise required by law.
We also recognize authentication requirements may be a consideration for non-covered entities, as TEF intends to manage Participants and Subparticipants consistently, as seen in the Common Agreement which extends specific HIPAA clauses to non-covered entities. Consequently, we believe that given those contractual obligations in this context where all Participants and Subparticipants already need to manage PHI to the same level of privacy and security, the SOP should align with existing requirements to manage PHI where TEF is not part of the fabric, thus focus on the QHIN specifically, and if necessary, non-covered entities and non-business associates which are already subject to HIPAA.
We recognize, however, the special role of the QHIN workforce, for whom we agree that these requirements are appropriate where that workforce may require access to PHI.
We note that Carequality does not have such authentication requirements, nor has identified the need to do so. If there is a need to require this additional level of authentication for covered entities, we suggest that it be done consistently through regulatory processes to ensure PHI meets the same standards and procedures wherever it flows, within an organization, within a network, or outside a network.
We suggest aligning the requirement to adhere to ASTM E2147-18 with ONC’s Certification Criterion § 170.314(d)(2), which references § 170.210(e)(1), which in turn references § 170.210(h) – ASTM E2147-18 (incorporated by reference in § 170.299). We note that § 170.210(e)(1) specifically identifies specific sections in ASTM E2147-18. The rationale for differing from ONC certification requirements is unclear. The EHR Association recommends that, for at least Participants and Subparticipants, there is no need for additional requirements.”
General Feedback and Considerations
Health care workforce well-being is challenged on many fronts daily. A particular pain point for those who access electronic health records is signing in/out for information security purposes. Maintenance of mandated training requirements for information security adds a periodic friction point amidst their myriad clinical responsibilities for currency and competency. Most (if not all) health systems employ robust credentials verification and privacy currency requirements as conditions of employment. Fewer and fewer members of the health care workforce are independent (non-employed) meaning that the vast majority possess an institutional identification based on CSP authentication at hire and periodically. Imposing AAL2 burdens on this workforce adds an unacceptable workload and cognitive distraction in their workflows that contributes to EHR/IT-fatigue and overall burnout. AAL1 represents a more reasonable information security posture with so many protections already in place. Multi-factor authentication or two-single factor authenticators is asking too much of workforce members who sign in/out of the EHR 30-50 times (or more) daily as they move physically through the institution or share work-stations with multiple other workforce members.
Section 5: Procedure
AAL2 requirements for multifactor authentication or two-single factor authenticators represents an overly burdensome requirement for health care workforce members accessing the EHR 30-50 times (or more) per day. Privacy of patient data in a HIN is no different than privacy of patient data in a local EHR and so should not be subject to higher security requirements than local security dictates. AAL1 requirements for identifiability of Participants or Sub-participants accessing patient data via the HIN is sufficient for audit purposes. Reliance on audits to detect breaches and inappropriate access to TI should be sufficient to protect patient data without imposing excessive and repetitive workload or cognitive burden on the health care workforce.
General Feedback and Considerations
“Draft QHIN, Participant, and Subparticipant Additional Security Requirements SOP Feedback
January 13, 2023
Mariann Yeager, CEO The Sequoia Project
Recognized Coordinating Entity
Dear Ms. Yeager;
Thank you for providing the opportunity for iShare Medical to provide feedback to the Draft QHIN Participant, and Subparticipant Additional Security Requirements SOP.
We commend the RCE for recognizing the need for both:
1) Identity proofing and assignment of a trust credential bound to the real identity of the person in compliance with NIST 800-63-3 IAL2
2) Authentication of each person’s identity credentials each time the person logs into the system in compliance with NIST 800-63-3 AAL2.”
“We commend the RCE for requiring Participants and Subparticipants including Non-HIPAA Covered Entities to agree to comply with HIPAA Security Rule as if they were a Business Associate of a Covered Entity. Further, we commend the RCE for also requiring authentication at NIST 800-63-3 AAL2 of identity proofed at NIST 800-63-3 IAL for all Workforce members. Further, we believe that there should be an audit trail of all transactions performed by Workforce members as required under HIPAA.
We agree that the security requirements for Individual Access Services (IAS) Providers for Identity verification which specify NIST 800-63-3 IAL2 but believe that it is also necessary to Authenticate individuals at NIST 800-63-3 AAL2.
We also believe that TEFCA QHIN’s, Participants, and Subparticipants should also be required to comply with the HIPAA Privacy Rule and HIPAA Breach Notification Rule.”
We commend the RCE for also requiring authentication at NIST 800-63-3 AAL2 of identity proofed at NIST 800-63-3 IAL 1) Workforce members and 2) Individuals. We agree that when Assertions are used in a federated environment to communicate authentication and attribute information to a relying party, such assertions shall comply with NIST Federation Assurance Level (FAL) 2. Further such assertions need to be confirmed by the issuer of the identity trust credential.
Requiring multi-factor authentication will add significant burden to the workflow of healthcare providers, and may even go so far as to deter some institutions from joining TEFCA. In current state at our institution, users use badge taps to access computers in exam rooms and the hospital. Every 4 hours, a second form of authentication is required by verifying your password. Due to 5 min screen timeouts, some users will badge tap into a computer multiple times during a patient encounter. If the badge + password was required every time a user wanted to use any computer, that would significantly increase the burden on users. It may also lead users to pressure their institution to increase the screen timeout times, to reduce the frequency of logins, which would also reduce the system security. Multi-factor authentication is a useful security feature, but it should be required at reasonable time intervals to ensure security while balancing user burden.
“””QHIN, Participant and Subparticipant workforce members and individuals who are authorized users of systems which access TEFCA information must be authenticated at Authenticator Assurance Level (AAL) 2. Authentication SHALL occur by the use of either a multi-factor authenticator or a combination of two single-factor authenticators.””
– KP is not in agreement with this requirement as it will impose an undue burden on provider time by requiring 2-factor authentication every time the user accesses the EHR. This is time that will ultimately take away from patient care and other healthcare operations. Assuming a provider logs into the EHR 40 times per day and the additional authentication requires 30 seconds each time, that’s an extra 20 minutes out of the provider’s day just to log into the EHR. 20 minutes is more than a single patient visit, meaning each provider would be able to treat one fewer patient each day due to the additional log-in time. This is unacceptable.
2-factor is reasonable when accessing the EHR from a remote location, so long as the two single-factor authentication option includes a daily log-in to the organization’s network (through MFA), plus a separate log-in each time the provider is accessing the EHR.
It is NOT reasonable for providers working within the healthcare facility on machines that are already logged into the internal network and therefore do not require a separate remote log-in.
Perhaps the language should be updated to require two-factor for individual access providers only.
“”QHIN, Participant and Subparticipants MUST record audit log entries of TEFCA transactions that adhere to ASTM E2147-18 “Standard Specification for Audit and Disclosures Logs” as a minimum requirement. “”
– KP is in agreement with this requirement.
“”All internet-facing connections shall utilize the Internet Engineering Task Force (IETF) Transport Layer Security (TLS) protocol5 , version 1.2 with BCP-1956 , or a later version of TLS, to establish a secure channel. This in addition to conformance with requirements specified in QTF 007, 008, 009.””
– KP is in agreement with this requirement.”
I am speaking from over 20 years of bedside critical care nursing experience, as well as an MSN in Nursing Informatics and 12 years of implementing and supporting EMRs.
Regarding the proposed multifactor authentication requirements: clinicians are already stressed to the max and counting clicks; we cannot add any more roadblocks between them and patient care. Our systems should be facilitating and supporting their work, not adding more valueless steps to every encounter. Having to use MFA every time they log into the system might be enough to send them over the edge. They are already accessing the system via a secure network or using MFA to access the clinical application. Please do not do this.
I am highly concerned by the requirement for 2FA for EHR logins. In particular, during code blue events, ‘rapid response’ activations, and other hospital emergencies, it is critical for providers to be able to log in as quickly as possible in order to be able to access key information and EHR functions. This is already a problem due to the current design of EHRs. I would suggest including an ’emergency’ opt-out functionality or clause in the requirements.
“I’m pretty sure this policy will pass. Frankly, it’s the right thing to do to secure our data. The real challenge is making it frictionless i.e. as easy as Face ID on your iPhone + your badge. The EHR is great at checking boxes with cumbersome bolt-ons to meet criteria. Steve Jobs would have an aneurism if he got his hands on Epic and how bad the experience is for people using it. Tech can be so much more elegant to help people, but the incentives need to be completely reevaluated to make that happen.
Time must be considered as our most precious human resource that it is.
My perspective is as a practicing physician. The key problem is that we keep adding things that take a little time here and a little time there, and almost never take any burden away. This will be another burden added to a long list unless it’s required to actually make it faster and easier than current login as part of the rule.
This is an opportunity to do some good. But just requiring 2-factor without active consideration of workload burden would be a big miss.”
Have received information regarding requirements for multi-factor authentications. Currently, as it stands – we have seen multistep access to be quite the burden on end-users and providers. Would recommend being acutely aware of what a multi-factor authentication process would actually mean for many and to explore less pain producing methods/processes.
Forcing third-party authentication on all clinical EHR users will make badge and other types of secure and efficient log-in methods virtually obsolete. Physicians and other clinicians log in and out of workstations all day. An overly burdened healthcare workforce is already moving toward burnout at an alarming pace and this unnecessary step can only add to that frustration. Concentrate on safeguards at the system firewall level. Emphasize standard practices such as a once-daily badge identification, secure password requirements, and secure remote entry via portal or VPN. Don’t move down this rabbit trail. Third party authentication is appropriate for external log-ins and securing transactions such as e-prescribing of controlled substances, not as a repetitive Groundhog Day exercise.
“It is our understanding that the proposed rule will require two-factor authentication when a team member accesses protected health information (PHI). Current security protocols within our organization require the securing of a workstation when leaving an area to avoid unintentional access to PHI. End users must then log into a workstation each time they enter a new area such as a nursing station, their personal office, or an exam room. This can result in numerous login and logout events over the course of a typical workday. The use of proximity badge readers with requirement of password entry once per shift or the use of fingerprint readers is currently our standard for proof of identity. We also use a 15-character password to promote security and reduce cyberattack risk.
Implementation of this rule would require additional security measures such as the use of a mobile device with authentication or the entry of the password in addition to proximity card readers or fingerprint devices. This would represent an additional burden on each individual within the organization with a disparate amount of burden placed on clinical team members due to the multiple areas accessed in the course of single day.
If each event represents 15 to 30 seconds of time for password entry or use of secondary authentication, this could add an additional 15-30 minutes of time to the clinician’s day. Time spent away from patient care, time delay in access to vital information, and a significant time increase in administrative burden that has been shown to worsen burnout.”
General Feedback and Considerations
“We appreciate the opportunity to provide feedback on the QHIN, Participant, and Subparticipant Additional Requirements SOP.
While we generally agree with the goal to provide secure access to data by authorized users, we suggest that the proposed approach does not reflect the current state reality for the controls already in place with healthcare providers for their workforce who would be the main Participant or Sub-participants impacted .Substantial changes impacting end-user workflows for user authentication and significant investments by these participants or sub-participants would be necessary to support the necessary processes and infrastructure while the benefits of such changes and investments to these Participants or Sub-participants are not clear.
We suggest a narrowing of the scope for both the requirements relating to the authentication of the workforce and the auditing standards. For the workforce authentication requirements, we suggest the requirements only be applied to the QHIN workforce while specific consideration is given to participants and sub-participants as to their current practices in the use of EHRs and HIT for their day-to-day workflow. Additional consideration is needed for organizations who are not covered entities under HIPAA who may have less stringent authentication practices in place for accessing EHI.’
Further, we also encourage that any auditing standards applying E2147-18 follow the same scope of requirement as to the auditing standards in place under certification criterion 170.315(d)(2) within the ONC Certification Program.”
Section 3: Definitions
“While the general definition of “workforce” is reasonable, we note that in the Procedures section this definition is applied narrowly to specific actors within the trusted exchange framework.
We suggest that the definition of individual be stated here as well for completeness as we understand this to be patient/consumer/proxy exercising their individual right of access.”
Section 4: Standard
While the general definition of the standards is reasonable, considering the adjustments to the Procedure section being proposed we suggest that adjustments may be necessary to focus on QHIN and non-covered entities more specifically.
Section 5: Procedure
“Regarding the AAL2 and Multi/Two Factor Authentication requirements for the entire workforce across QHINs, Participants, and Sub-participants, we are concerned that this is too broad to be unworkable in the current exchange environment and for data holders.
We note that, while providers can implement either, many have chosen not to for reasons of end user satisfaction and burden reduction, and those that have implemented have not implemented these across all EHR user roles especially for roles beyond physicians/clinicians who engage in specific workflows where they may be required by prevailing law or policy. This typically has only been implemented for targeted use cases such as e-prescribing where that is necessary to comply to controlled substance prescribing regulations for the use of high reliability MFA. There are few other requirements driving deployment of the proposed approach and there is no reason to consider TI any different from all the other electronic personal health information (PHI) that a covered entity currently manages and that users have access to with current controls in day-to-day clinical workflow.
Introducing this for all use cases where a user is accessing TI or PHI effectively requires that users interacting with PHI must always be subject to these requirements as isolating the scenarios where they truly are requesting and interacting with TI would be difficult to parse and interrupt the workflows where they may invoke that as needed even more. This is particularly evident where clinicians move around and having to sign-in to different workstations while workstations are commonly shared. Additionally, many of the interactions involving TI would be orchestrated by the system on behalf of the provider organization, not necessarily any specific user.
We therefore strongly suggest that the SOP aligns with the reality of the authentication procedures and two/multi factor authenticators that covered entities may have put in place to address requirements for prescribing controlled substances balancing with their overall risk assessment and planning under HIPAA guidelines as internally sourced PHI data has the same sensitivity and security requirements as TI.
We recognize though the special role of the QHIN workforce for whom we would agree that these requirements are appropriate where they may require access to PHI. We also recognize that for non-covered entities this may be a consideration as TEF intends to manage all Participants and Sub-participants consistently, which it is doing already in the Common Agreement by applying specific HIPAA clauses to non-covered entities. Consequently, we believe that given those contractual obligations that in this context where all Participants and Sub-participants already need to manage PHI to the same level of privacy and security, that the SOP should align to current requirements already in place to manage PHI where TEF is not part of the fabric. We note that Carequality does not have such requirements, nor has identified the need to do so. If there is a need to require this additional level of authentication for covered entities, we suggest that be done consistently through regulatory processes to ensure wherever PHI flows, within or outside a network, it meets the same standards and procedures.
Regarding the requirement to adhere to ASTM E2147-18, we suggest to align this with ONC’s Certification Criterion § 170.314(d)(2) that references § 170.210(e)(1) that in turn references § 170.210(h) – ASTM E2147-18 (incorporated by reference in § 170.299). We note that specifically § 170.210(e)(1) identifies specific sections in ASTM E2147-18. It is not clear what the rationale would be to be different from the certification requirements set by ONC and suggest there is no need for additional requirements by at least Participants and Sub-participants.”
Orlando Health supports the enhanced information security provided by multifactor authentication, however we feel like the proposed timeline imposes a significant burden on hospitals and health systems to accelerate adoption of technology at significant cost and potential workflow disruption for clinicians. It would be particularly difficult for smaller health systems to rapidly deploy MFA technology to meet the proposed schedule.
I strongly oppose requiring multi-factor authentication for all EMR logins. It would substantially increase clinician workload while failing to secure a major source of HIPAA protected data breaches (extensive data breaches are occurring frequently at the institutional level.
As a family physician who embraced EHRs in the early 2000’s, a physician leader who transformed a large medical group around a theme of returning joy to patient care, and a trusted advisor to health system leaders working to reduce burnout by fixing the workplace drivers, not simply making clinicians more resilient, I urge you to end consideration of this additional security requirement.
Doctors and nurses are already experiencing record levels of burnout, causing many to leave the clinical workforce, and ultimately creating a potential existential threat to the stability of our healthcare “system”.
This proposal to require multi-factor authentication every time a clinician accesses the EMR will further exacerbate the primary root cause of burnout – work overload – particularly involving work that provides no clinical value, but adds to the already overwhelming cognitive load.
EHR user interfaces and processes are poorly designed and user-unfriendly. Making it even more onerous with this requirement will lead clinicians to find a way around the requirements, potentially leading to worse care and lower security. Those that don’t find a way around this may well simply walk away from their careers.
It’s time that the IT community took responsibility for maintaining security by committing innovation to design safe and secure systems that are user friendly, rather than require clinicians to take up the slack of the poorly designed systems.
Thank you for listening,
Paul DeChant
“We believe that the requirement for using multifactor authentication for accessing TEFCA Information (TI) as a potential Participant in the Epic QHIN to be extremely onerous and unnecessary; enough so to preclude our participation in TEFCA.
We are a network of 550 primary care pediatric providers in the Commonwealth of Massachusetts. We care provide medical and behavioral health care to more than 400K children across the state as a network of 80 independently owned and operated practices. We have multifactor authentication enabled where it is required by Federal regulation and where it makes sense to ensure our compliance with the HIPAA Security and Privacy Rules.
As an example, our medical providers are required by the Drug Enforcement Agency (DEA) to provide a second factor authentication every time they wish to electronically prescribe a controlled substances (EPCS), and we license a product at significant expense in order to ensure safe and secure prescribing of controlled substances.
In addition, we have enabled two factor authentication for remote access to our Electronic Health Record and other applications, such as email as a security best practice. On premise (on network) access does not require a second factor since having physical access to a computer on a secured network is considered the second factor.
There is constant tension to balance implementing stringent security standards with the usability of systems by the end users. The requirement by Sequoia for every individual to authenticate using a second factor every time they access TI may provide for a very secure system, but that system will not be used.
Finally, we believe that the Sequoia Project should simply enforce existing Federal rules and regulations (e.g. HIPAA) rather than implement their own set of standards.”
“(Section 5, on page 3)
The requirement for 2 factor authentication is unreasonably burdensome for onsite clinical users. Doctors and other clinical staff need to change workstations up to 100s of times per day in certain locations. Requiring a 2 factor solution at each login would significantly decrease productivity and increase healthcare costs.
2 Factor authentication is in place at most systems for offsite/remote users and is a reasonable requirement.”
We think you should consider giving organizations the option to require two-factor authentication, and for organizations that demonstrate a history of this being insufficiently secure requiring two factor authentication. As most clinicians log into and out of workstations dozens of times a day the additional burden risks worsening our already considerable security requirements and clinician burnout. Targeting the extra security to where it would be most helpful may help reduce clinician burden.
“Multifactor authentication could be not required if a user has already logged into a secure network, then clinical application with additional username and password.
Enabling multi factor authentication for any system connected to the interoperability system could place huge burdens on front line clinical staff unnecessarily
As an internal medicine as medical informatics physician I understand the need for security. However, undo burden on frontline staff will increase workload/ burnout and make records slower to access.”
“HIPAA requires all Covered Entities including Stanford Health Care to implement appropriate, risk-based technical, administrative, and physical safeguards. All of our staff are subject to HIPAA, and some have experience implementing MFA in targeted, high-risk workflows, such as electronic prescribing of controlled substances. Expanding MFA to encompass all workforce staff with access to TI or PHI (which is virtually all staff, including providers, nurses, schedulers, billers, registrars, and more) will slow care by disrupting workflows and likely limit our ability to join TEFCA as a QHIN participant.
A typical provider logs into the electronic health record 30 times per day or, with a quarter of users logging in 55+ times per day. Experience has shown a strong inverse correlation between the burden of EHR system access and provider/clinician satisfaction. Requiring MFA to be used every time workforce members access TI or PHI is an unacceptable disruption.
In addition to the workflow disruption, expanding AAL2 MFA to all workforce staff will require additional IT infrastructure, expanding the cost of healthcare. For example, authenticators must be provisioned for all workforce staff.
Because of the incurred cost and burden, we believe that requiring AAL2 MFA for all workforce members with access to TI or PHI is unnecessary and poses an inappropriate burden. The RCE has not provided any evidence that would justify the proposed requirement, nor an analysis of the cost of implementation. We counsel the RCE to not pursue this policy. If RCE believes that existing HIPAA requirements are insufficient to protect TI and PHI, it should work to address it through national policy rulemaking rather than via TEFCA SOP.
Thanks for your consideration.”
While a lofty goal, we are concerned that the requirement for multi-factor authentication (MFA) will result in significant clinical burden. The only way EHR MFA (and its integrated touchpoints) will work internally (non-remote access) without significant issues at the point of care is by integrating an adaptive model where context and step-up authentication (threat based) are applied. This requires a robust behavioral analytics approach. In addition, MFA should lower the password management burden. This perspective follows the updated NIST guidelines on authentication. We will not be able to get to this kind of model for another year (2024). And even that is idealistic. Those who treat this as a point problem and not a “systems/design” thinking issue will create enormous reliability, resiliency, and performance issues in their environments.
Two factor authentication for providers as proposed will create an undue burden. Providers are under extreme strain and are leaving health care due to burn out. Adding this requirement will put up barriers to patient care and increase burn out.
General Feedback and Considerations
“UC Health is an integrated academic health system affiliated with the University of Cincinnati. The health system consists of three inpatient campuses and 64 outpatient locations. We have over 12,000 team members in 95 specialties, serve over 385,000 patients, and render over two million services per year. In partnership with the academic strength of the University of Cincinnati, one of the nation’s top 25 public research universities, we currently participate in over 900 clinical trials. As southwest Ohio’s only adult academic health system, our flagship hospital, UC Medical Center, is recognized as the region’s essential hospital in that we provide life-saving health care services to everyone regardless of their ability to pay.
Information security is a challenging and constantly evolving area where it is essential to balance security with feasibility. A process that is incredibly secure but practically infeasible for technical or workflow reasons will be avoided. The proposed SOP, as currently written, imposes onerous requirements on healthcare users and is simply not tenable in a working clinical environment. If the SOP is approved as written we anticipate that it will drive many, including ourselves, to decline participation in TEFCA.”
Section 4: Standard
“The proposed SOP notes that the Common Agreement requires, “…appropriate security controls for TI that are commensurate with risks…”. The proposal however then goes on to describe onerous authentication requirements with zero regard for whether the proposed authentication requirements are commensurate with risk in a particular setting.
Additionally, the “Common Agreement for Nationwide Health Information Interoperability, Version 1” in Section 1. Definitions and Relevant Terminology defines TEFCA Information as the following:
“TEFCA Information (TI): any information that is exchanged between QHINs for one
or more of the Exchange Purposes pursuant to any of the Framework Agreements.
As a matter of general policy, once TI is received by a QHIN, Participant, or
Subparticipant that is a Covered Entity or Business Associate and is incorporated into
such recipient’s system of records, the information is no longer TI and is governed by
the HIPAA Rules and other Applicable Law.”
The proposed SOP would functionally void the intent of the Common Agreement to treat TI as equivalent to other information in the Covered Entity’s record once the TI is incorporated in the record by needlessly applying stricter security requirements in a sweeping fashion without consideration of risk. HIPAA does not explicitly cover all security controls, however this is done intentionally to allow Covered Entities to address security risks according to their unique circumstances. The intent is to avoid excessive and unnecessary security control requirements which would significantly and unnecessarily impact the efficient delivery of healthcare.
We urge the RCE to drop the proposed SOP and not pursue it any further or at a minimum remove Covered Entities and their Business Associates from the proposed SOP as these entities are already obligated under HIPAA to apply appropriate security and auditing requirements.”
Section 5: Procedure
“** Authentication – Workforce Members**
UC Health, as a Covered Entity, is already required by HIPAA to implement appropriate controls to protect the security and integrity of the data we store. We meet these requirements through a mix of physical access controls, multifactor authentication (MFA) requirements, and other measures that are selectively applied depending on a variety of factors. We do not see any need to implement a sweeping requirement for MFA for all users with access to PHI under all circumstances and without regard to other access controls.
The proposed SOP as written raises two significant concerns. First, the additional time and steps necessary to use MFA for each instance when a software system is accessed would be a significant disruption to staff workflows in a time when healthcare systems are already understaffed and highly strained. Per our EHR vendor’s data, the median provider accesses our EHR approximately 30 times each day and a quarter of them access the system more than 55 times each day. The additional burden of using MFA each time is simply untenable. The second significant concern is that applying the SOP as written would incur a significant financial cost on healthcare systems – our organization alone can see approximately 16,000 active users in a single day. A few thousand currently have the ability to use MFA for particular workflows or to allow offsite access to our systems. The proposed SOP would require significant expenditure to license MFA functionality for thousands of additional users and to equip every workstation appropriately. The additional costs would include both capital costs and ongoing operational expenditures for licensing costs. Weighed against these two concerns we must ask – what benefit is gained by the proposed SOP? We see no evidence to suggest that existing state and federal regulatory requirements on the protection of PHI are insufficient and need to be augmented by a TEFCA SOP.
** Authentication – Individuals **
We agree that MFA creates a more secure mechanism to access information, however as noted above we do not believe that a sweeping requirement for MFA in all instances makes sense. A broad requirement for MFA could adversely impact the ability of some patients to access their health information. A more nuanced approach that allows individuals to opt out of MFA at their discretion achieves a better balance between security and usability.
** Audit Trail **
UC Health understands the need for an Audit trail relative to TI as it traverses the QHINs. Per the aforementioned TI definition, TI becomes PHI once it enters the Participant’s system, if the Participant or Sub-Participant is a CE or BA. Therefore, adding additional auditing requirements for the TI that is now PHI becomes irrelevant because typically once TI is accepted into the system it is no longer distinguishable from the other PHI that was created by the CE.
Federal and state regulations already place obligations on Covered Entities and Business Associates to audit system access and retain records. RCE should align with HIPAA rather than requiring a different auditing standard. Such an approach is better for “future proofing” TEFCA policy because RCE will not risk the scenario where HIPAA is updated in a manner that is incompatible with ASTM E2147-18.
If RCE’s concern is specific to Non-HIPAA Entities (NHEs) who are not subject to federal and state regulations, then RCE should target additional auditing obligations to them without affecting Covered Entities and Business Associates.
** Secure Channel **
We defer comment on TLS v1.2 to vendors developing prospective QHINs.”
“I’m here to provide a comment regarding the Standard Operating Procedure (SOP): QHIN, Participant, and Subparticipant Additional Security Requirements.
My organization (UNC Health) has implemented user authentication requirements adherent to AAL2, specifically dual factor authentication. Our implementation allows for that authentication to span over a short period of time such that DFA is not required with each login. The SOP as written, does not specify (introducing ambiguity) as to whether DFA would be required with each login, but on behalf of UNC Health, I want to recommend that each organization should be allowed the flexibility to determine the specific duration relative to DFA.”
General Feedback and Considerations
“UnityPoint Health appreciates this opportunity to provide feedback on the Draft QHIN, Participant, and Subparticipant Additional Security Requirements Standard Operating Procedures.
UnityPoint Health is one of the nation’s most integrated health care systems. Through more than 32,000 employees and our relationships with more than 480 physician clinics, 40 hospitals in urban and rural communities, and 14 home health agencies throughout our nine regions, UnityPoint Health provides care throughout Iowa, central Illinois, and southern Wisconsin. On an annual basis, UnityPoint Health hospitals, clinics, and home health agencies provide a full range of coordinated care to patients and families through more than 8.4 million patient visits.
While UnityPoint Health is not on the Care Everywhere Governing Council, we add our voice to their comments and urge RCE to reconsider the authentication process for workforce members and individuals as well as the proposed audit trail. If this policy moves forward as written, the outcome will be hesitation by healthcare providers to participate in TEFCA, hindering the national goal of improving interoperability. This policy will weigh heavily on the guidance and considerations we share with our covered entities who are considering TEFCA participation.”
Section 5: Procedure
“** Authentication – Workforce Members**
HIPAA requires Covered Entities to implement appropriate, risk-based technical, administrative, and physical safeguards. All Covered Entities are subject to HIPAA, and some have experience implementing multi-factor authentication (MFA) in targeted, high-risk workflows, such as ordering of controlled substances. Expanding MFA to encompass all workforce staff with access to TI or PHI (which is virtually all staff, including providers, nurses, schedulers, billers, registrars, and more) will slow care by disrupting workflows.
A typical provider logs into the electronic health record 30 times per day, with a quarter of users logging in 55+ times per day. Experience has shown a strong inverse correlation between system access burden and provider satisfaction. Requiring MFA to be used every time workforce members access TI or PHI is an unacceptable disruption.
In addition to the workflow disruption, expanding AAL2 MFA to all workforce staff will require additional IT infrastructure, expanding the cost of healthcare. For example, authenticators must be provisioned for all workforce staff. This policy risks pricing smaller providers and critical access hospitals out of participation in TEFCA.
Because of the incurred cost and burden, we believe that requiring AAL2 MFA for all workforce members with access to TI or PHI is unnecessary and poses an inappropriate burden. RCE has not provided any evidence that would justify the proposed requirement, nor an analysis of the cost of implementation. We encourage RCE to not pursue this policy.
If RCE believes that existing HIPAA requirements are insufficient to protect TI and PHI, RCE should work to address this through national policy rulemaking rather than via TEFCA SOP.
If working through national rulemaking is not possible, RCE should release an updated SOP for public comment detailing why a TEFCA SOP is a more appropriate avenue. That updated SOP should also include a cost/benefit analysis that includes real-world estimates of financial and workflow burden caused by this policy. The analysis should define the specific risks that RCE believes are being mitigated by AAL2 MFA with specific evidence supporting that thesis.
RCE should amend this SOP in the next draft to indicate that AAL2 will be conditionally required for workforce members using rules-based logic. We note that rules-based application of AAL2 is typical in industry. For example, in Microsoft products this is referred to as Conditional Access Policy and allows organizations to tailor access policies to match multiple risk level scenarios.
Some examples of rules RCE should consider include:
1. When using an on-premises workstation, AAL2 is not required, because access to workstations on-premises is already controlled via physical controls.
2. AAL2 is only required once every 24 hours. Requiring workforce staff to perform AAL2 repeatedly throughout the day is an unacceptable disruption.
3. Workforce staff are permitted to use a “remember my device for 30 days” feature. When selected, AAL2 will not be required again until the 30 days expire.
** Authentication – Individuals **
Adding AAL2 MFA as an additional step for Individuals (and their proxies) to access their health information may introduce an additional barrier to patients accessing their own data and actively participating in their healthcare.
RCE should compile a cost/benefit analysis of how AAL2 MFA will burden Individuals’ access to their own health information. The analysis should include the risks that are being mitigated by AAL2 with specific evidence supporting that thesis. An amended SOP should be released for public comment after that analysis is available.
RCE should amend this SOP in the next draft to indicate that AAL2 will be conditionally required for Individuals using rules-based logic. Some examples of rules that RCE should consider include:
1. When using a provider-controlled network, AAL2 is not required. It is common for Individuals to access their data while in a healthcare facility. For example, MyChart Bedside is a patient-engagement platform that includes an admitted patient as an active part of their healthcare delivery. Patients can message staff, review lab and imaging results, and plan their daily schedules. Requiring AAL2 many times throughout the day while the patient is on-premises is disruptive and unnecessary.
2. Individuals may choose to opt-out of AAL2 if they prefer not to participate.
** Audit Trail **
Federal and state regulations already place obligations on Covered Entities and Business Associates to audit system access and retain records. RCE should align with HIPAA rather than requiring a different auditing standard. Such an approach is better for “future proofing” TEFCA policy because RCE will not risk the scenario where HIPAA is updated in a manner that is incompatible with ASTM E2147-18.
If RCE’s concern is specific to Non-HIPAA Entities (NHEs) who are not subject to federal and state regulations, then RCE should target additional auditing obligations to them without affecting Covered Entities and Business Associates.
** Secure Channel **
We defer comment on TLS v1.2 to vendors developing prospective QHINs.”
“Our password security requirement is a minimum of 16 characters
We use Badge ID & only require once daily “”authentication”” of the badge
If we have to start typing the long security code each time we open up our EHR (Epic) and/or workstations, then the burden of this performed hundreds of times per day will lead to severe end user push back, and TEFCA will likely NOT be adopted by our organization.”
“I am writing to comment on proposal for AAL2 level of security for accessing workstations. As a busy hospitalist, I am logging in to the EHR between 30 and 40 times per day. I use dozens of different computers throughout the day, and I log in from every patient room. We use badge taps to unlock secured workstations.
Adding another layer of authentication will be unduly burdensome to physicians and other clinicians. Many of our patients are in isolation, and it is very difficult to type a password while wearing gown and gloves, especially with longer passwords (mine is 18 characters). This will also add a significant time delay. I am concerned that in an emergent situation (like a Code Blue) any additional time required to access the EHR could be very dangerous for patients.
Please reconsider this proposal. Our badge taps already require password authentication every 4 hours. Increasing this frequency to each time the computer is accessed is unduly burdensome for already time-constrained clinicians.”
Submission 1:
Please do not require 2 factor authentication for every user login to workstations with PHI. Quickly accessing the electronic health record to document relevant and timely updates and place orders is vital to safe, efficient patient care. I’m an emergency physician in a busy level 1 trauma center. I probably log in and out of any number of workstations 20 or more times per hour. Requiring 2FA for each of those logins would negatively impact how we care for patients. I understand the need for security, but this would be a hindrance.
Submission 2:
Please do not include a mandate to use multi-factor authentication for our in-house workstations. We are a 10,000 person organization and use badge taps for authentication with intermittent passwords. For remote access we always use multi-factor authentication. Working in clinic today I’ve probably logged into machines 50-60 times, sometimes more than once per patient. It would be extremely inefficient and frustrating to use multi-factor authentication every time I or other clinicians log in while seeing patients. We are already so overburdened with so many things and this is a significant barrier to workflow and efficiency. Considering the entire nation my sense is we should not mandate multi-factor authentication for clinical workstations in our clinical buildings – hospital, clinic, emergency dept, other. This would have a major negative impact on our staff, and at least where I work I cannot see a significant benefit in patient privacy/safety. There are enough burdens on our clinical staff and we really do not need to add more unless absolutely necessary, the burdens are already creating a negative effect on patient care and we are working hard to unburden our clinical staff as much as possible.
Submission 3:
Requiring two factor authentication during completion of clinical tasks and documentation will be a significant increased burden on an already taxed clinical staff. This is not an effective or efficient method to improve security and would most certainly have detrimental effects on the clinical workforce.
Please don’t require MFA more frequently than daily, and recognize that for many organizations it is not feasible for clinical staff to do MFA. For example, while it is common for salaried physicians to have personal cell phones that they use (securely) for things like MFA, hourly clinical staff are not permitted to use personal devices, and it would be cost prohibitive to provide them devices for that. Additionally, the requirement to frequently enter passwords must be avoided, when there are reasonable alternatives, such as single-sign-on/badge tap, etc.
A MFA requirement for organizations connected to the TEFCA network will discourage us from connecting to it as we believe our current security measures are robust both from the technical side and the physical side. We require MFA for users outside of our physical locations and use a high quality alternative method for access in our physical locations. We already have access to multiple systems via other networks and to add a MFA requirement to get a little more access would not likely be worth it.
Complete the form below and join our mailing list.