For many CTOs, HITRUST served to finally bring definition and practical guidelines that were lacking in the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Best practices regarding the protection of PHI via physical and electronic mechanisms were largely defined by a collective understanding of how to interpret HIPAA rules, but the lack of explicit instruction left room for inconsistent implementation and, worse, gaps subject to breach. But one of the unfortunate side effects of this enhanced level of detail is the introduction of guidelines that render the user experience impractical...to put it mildly.
When User Account Management Is A Four Letter Word
The biggest barrier to implementing a HITRUST friendly protocol for health IT systems (in terms of adoption) is user account management. Despite best efforts, begging and pleading, we know that most physician users are writing down their usernames and passwords for reference (or have asked their support staff to do so on their behalf). We can’t blame them, as it’s not unusual for practicing doctors to have no less than a dozen different systems to which they need access to provide comprehensive care to their patients.
Single Sign-On (SSO) is one way healthcare integration efforts can help alleviate this burden, but you’re still going to fight tooth and nail to keep busy practitioners from allowing their browsers to retain credentials (unless you design the UI to prevent that). And can you blame them for trying? There is an incredible pressure on health systems to protect PHI, all while relying ever-increasingly on electronic records and data exchange. Yes, it must be handled with care, but what good does great data do for patient outcomes if there is a significant barrier to access by the very experts we count on to process that information, all in the name of security?
One More Password To Keep Up With
Per HITRUST regs (CSF), passwords should expire no more than every 60 days, should have enhanced complexity (alphanumeric and character usage required), and may not be replicated within the last six resets. Temporary passwords cannot persist beyond the first login, and organizations may even maintain a list of unacceptable passwords given their potential for abuse or frequency of use
(therefore making them easier to guess). Nothing groundbreaking for most of us
who use a handful of systems to run our daily lives, but imagine this on a larger scale, over several systems that require passwords to access the desktop, and then subsequent (unique) passwords to login to the various programs and systems needed to function as a medical professional. (WaaS is a prudent solution in these cases.) The exponential effect is dizzying, and explains why there are often (unsanctioned) workarounds and endless complaints from even the most tech-savvy users.
User Experience Makes Healthcare IT Adoption Possible
When new healthcare end users can’t easily access and learn a new health IT system, there are going to be barriers in even the best laid project plans and most streamlined integration development. Systems should be intuitive, obviously meeting a need or delivering a new value-add, and accessible with reasonable effort. It’s not unreasonable to require two-factor authentication (2FA) for the user registration process, but setting that requirement for regular access -- especially if it’s a daily-use system -- could result in stalled adoption, or worse, organizational rejection. (Never underestimate the power of the masses to call an implementation a mistake and flat out refuse to get on board.
But You Can’t Please Everyone, Either
There will always be tough cookies. In every organization, there are a few folks who are known to play Devil’s Advocate or prove to be the naysayer in any given decision-making process, and while that can be difficult for making swift, ambitious decisions (especially around IT efforts), they are also a good indicator of where potential difficulties may arise as you try to implement a HITRUST level environment.
Access points may be secured, roles more tightly defined, and additional burden given to those who are closest to patient data. Any change can be cause for concern, but making sure that the goals of these new policies and procedures is clear can go a long way in the majority embracing the new. (If you expect perfect concurrence, you’re setting yourself up for disappointment and project delay.) Telling your key stakeholders that the goal is simply “HITRUST” won’t help you make progress unless the benefits and implications are well socialized, such as:
- Attractive for patient and physician recruiting and retention
- Job creation and opportunities for specialization
- Positioned for partnership with or acquisition by major health system/payer/org
- Reduced liability
- Strategic development for customer pipeline
Know your audience and speak their language, as an overly-technical focus on efforts toward HITRUST may be met with blank stares and an unwillingness to sponsor workflow changes in their respective department.