With Meaningful Use Stage 3 (MU3) affecting most in-hospital, ambulatory, and patient portal software, never has user experience and software architecture been more important to electronic health record (EHR) software vendors.
The ONC’s Meaningful Use Stage 3 proposed rules and associated 2015 EHR certification criteria will have major impacts on EHR software vendors in terms of:
- Patient Engagement
- API Access
- Integration with Patient-Gathered Data
- Increase Patient Safety
Meaningful Use Stage 3 is an ambitious program that could transform the provider and patient experience. Though there are many factors at play including the way providers encourage their staff and patients to use the software, a big part of the onus falls on EHR vendors and their ability to address these challenges through UX design. EHR vendors who rise to the user experience challenge will not only comply with the regulation but will gain strategic advantage over their competitors as they win over providers and patients.
A cornerstone of Meaningful Use Stage 3 is patient engagement. The basic principle behind the new healthcare model is to enable a care team to effectively share medical information about the patients. This used to be largely information collected by the clinicians and hospitals. Now, the focus is more on the patient and the information they can provide.
Providers are already expressing concerns about how high the patient engagement bar has been set in MU3. More than 25% of patients seen by an eligible professional or discharged from a hospital or emergency department must “actively engage” with their EHRs. And for more than 35% of patients seen by an eligible professional or discharged from a hospital, a secure message must be sent using the EHR’s secure messaging function or in response to a secure message sent by the patient.
To support providers, EHR vendors need to ensure their patient-facing software – namely their patient portal – is as engaging and usable as possible. This could mean a proliferation of useful features for patients like voice, video, and e-mail communication with the care team, patient education material, uploading and tracking of fitness and self-care data, and care plan wizards.
Of course, providers will need to make it clear to patients what will happen to their data, who their data will be shared with, and how it will be used to improve their care. No matter how useful the features, putting the patient in charge of this data gathering gives them additional responsibility and increases their workload.
Therefore patient software must make it easy for providers to make it clear to patients the positive impact this extra work on their behalf will have on improving the outcome of their care. To ensure buy-in the patient will have to see an immediate benefit from the software.
As an additional (and maybe most important) driver, the ONC has declared that providers can also meet the patient engagement requirements if patients access their data via third-party software that uses a new API that those EHR vendors must supply. The message to EHR vendors is clear – make your patient software more valuable, engaging, and usable, or lose out to third-party software that does it better.
The intentions behind the API requirements are an admirable push towards ‘freeing’ patient data from the EHR to the patient and promoting competition among EHR vendors and third-party software vendors that may do a better job addressing patient needs. The API requirements make sense at a high level. Get various providers’ systems talking to each other and give the patient control over who gets what.
But the language in the API section of the criteria is mostly technically focused. The risk here is that any EHR software vendor could provide an API that complies technically, but with challenging login/authorization steps heaved on the patient. For example:
“The provider only needs to implement an API, and fully enable the API functionality, provide patients with detailed instructions on how to authenticate and provide supplemental information on available applications that leverage the API. This allows providers the ability to allow the patient to receive info.”
Engineers can define the plumbing for all of this information to flow freely and securely. The problem is giving the set of keys to the patients. Most people don’t fully understand how sharing on Facebook works, or permissions requests from their mobile apps. Imagine the inherent difficulties of sharing information from one system to another system and then giving control to the patient and asking them to manage it. The patient would have multiple steps to consider, such as:
- The patient will need to authenticate.
- Caregivers/parents / children will need to authenticate.
- Providers will need to authenticate.
- The patient needs to fully understand and control who they are giving access to and what kind of access is being granted and manage ongoing access.
All of this in an environment without a federated identity authority.
All of this while preserving HIPAA and other regulations.
Like most security/access control issues, the biggest problem is not the engineering. It is the human side.
Integration with Patient-Gathered Data
The other Meaningful Use Stage 3 (MU3) requirement that will involve a bit of technical savvy and a lot of attention to usability is the requirement to allow patients to upload their own data, not taken from a clinical setting, into their patient record. For example, as a patient, I could upload my own historical data from my fitness tracker of choice for the doctor to review.
Unless there is careful attention paid to the way that data is filtered and presented (not to mention careful attention to the regulatory ramifications of clinicians reviewing non-clinical data in order to provide care), incorporating patient-gathered data from a variety of sources and in different formats could be a doctor’s nightmare.
“The objectives encourage sharing of patient-generated data with providers (including through APIs), an issue that has long given rise to concerns by providers about being overwhelmed with information, about alarm fatigue. The key, of course, will be intelligent filtering of the data so that it may be presented to clinicians and patients as actionable information,” says David Harlow, a healthcare lawyer and consultant in his article, “The Meaningful Use Stage 3 talk won’t matter if the tech isn’t ready”.
EHR vendors have started experimenting with patient-gathered data, like eClinicalWorks who announced an update of their software that will integrate wearable data into its EHR. eClinicalWorks is the second EHR company to recently integrate wearable data, following a partnership between Cerner and Validic that similarly seeks to make wearable data more functional. The trend is likely to accelerate with MU3, especially if these initial integrations are successful in surfacing the right information at the right time for clinicians, and they effectively manage to avoid data overload and alert fatigue.
As with patient engagement, not only must this software be usable, it also needs to be useful. Doctors will not want to get really involved with this data unless the software makes clear “what’s in it for them”. Patients also will want the same question answered before they’ll go through the process of uploading their data. For example, doctors that are not part of a care team that is accountable for the results may have little incentive to deal with extra data like fitness history data. But this might not be true for other kinds of patient-initiated data like blood glucose or blood pressure readings, where having them directly in the EHR could be a plus. And some doctors give their patients goals like “lower cholesterol’ or “lose weight” and may find useful to view fitness history data in the EHR.
It all depends on the physician and patient context, and the way the information is presented, if at all. If the system’s alert system is fine-tuned to avoid alert fatigue, the system could reasonably update the doctor only if there is a real issue.
TIP: Small Data vs Big Data
Meaningful Use Stage 3 has direct relevance to the handling of big data vs small data. If you haven’t done so already, review our section on – Small Data vs. Big Data and – Putting Your Application Into Context (it gives examples of displaying big data in digestible chunks).
Increase Patient Safety Through Usability Testing
As with MU2, Meaningful Use Stage 3 (MU3) requires a particular type of usability testing called summative usability testing. In summative usability testing, a qualified user experience design professional walks users one at a time through a series of tasks with the EHR software. Then they measure the amount of time to complete each task, how many and what type of errors occur, and user satisfaction with the task interaction.
The goal is to benchmark the current usability of the EHR user interface – as measured by things like task times, completion rates and satisfaction scores.
The goal of this requirement is to ensure EHR vendors are incorporating a user experience design process into their software development on a regular basis, which has been shown to measurably reduce usability errors that could impact patient safety. Everyone remembers the Ebola incident that highlighted a potential EHR usability problem. Complying with these requirements is the first step. Incorporating a user experience design process throughout the EHR development lifecycle is even more important.
TIP: Incorporate User Design From Day One
Increasing patient safety and reducing risk are goals, often addressed by regulations and certifications that demand users are made the focus of the process from day one. It’s here, near the end of our regulatory section, that we want to bring you full circle again, to the – User. If you skipped it in the beginning, hopefully, you see now how you cannot choose a technology or capably address privacy and certification requirements without going back and truly understanding, who is your end user?
NISTIR 7742 Template
The NISTIR 7742 template is meant for EHR vendors to demonstrate usability in their final product. You will need to submit the information specified in the template for each and every one of the applicable 17 certification criteria for which you are seeking certification. The following is a broad overview of the information required for submission; the NISTIR 7742 had been modified to allow for qualitative studies, regardless quantitative or summative studies are still strongly encouraged.
The following information/sections in NISTIR 7742 are required for submission:
- Name and version of the product
- Date and location of the test
- Test environment
- Description of the intended users
- Total number of participants
- Description of participants as follows:
- Occupation / role
- Professional experience
- Computer experience
- Product experience
- Description of the user tasks that were tested and association of each task to corresponding certification criteria
- List of the specific metrics captured during the testing
- Task Success (%)
- Task Failures (%)
- Task Standard Deviations (%)
- Task Performance Time
- User Satisfaction Rating (Scale with 1 as very difficult and 5 as very easy)
- Test results for each task using metrics listed above
- Results and data analysis narrative:
- Major test finding
- Areas for improvement
Download The Complete Guide to Engaging Digital Health Software