You know that clear communication between patient and providers is essential. It’s no different for digital health tools, such as apps, patient portals, devices, telehealth, and the most popular digital health tool, websites.
Clear communication in and through digital health tools is complex in its own right. Based on a recent podcast with me and my Health IT pro brother, let’s take a look at a communication roadblock that you don’t want to derail the digital health tools you and your patients use.
Research on communication and digital health tools
Digital health tools are such a popular topic that digital health literacy and electronic health literacy (ehealth literacy) have become their own sub-fields of study.
The majority of the research on health communication and health literacy in digital environments focuses on patients/consumers. Some research has analyzed the health tools themselves, often for readability and occasionally for its accessibility. Less common, though very important, is research into issues of readability and accessibility for specific populations or groups, such as this study into the accessibility of a diabetes app for speakers of Spanish and this study into the usability of apps for gestational diabetes.
There has also been the development of guidelines, checklists, toolkits and measures for designing high-quality online health information. In 2014, the IOM stated that “both health care organizations and those who develop communication channels and devices have a responsibility to make health information understandable and easy to use for people of all health literacy levels.” Research suggests these guidelines aren’t being followed–but it’s unclear why.
Taken together, this research draws attention to the use and affordances of these digital platforms. And it hints at the complex literacy and numeracy activities individuals and groups engage with in digital environments.
This research also is of one voice regarding issues of user-centeredness in the design of resources. There’s broad agreement that digital tool development should involve speaking with people before and during the design process.
So what’s the problem?
Well…
A 2016 Commonwealth Fund data brief on the usability of apps found that “most mHealth apps have low design quality.” And, it turns out, the health information on them is largely inaccessible to most Americans. Internet-based consumer health information is written at a level that exceeds the USDHHS recommendations.
Again, there doesn’t seem to be uptake of those guidelines, checklists, toolkits and measures for designing high-quality digital health tools.
You know it’s good to reduce medical jargon in patient communication. You also know that shared meaning or mutual understanding is important all the time in patient communication (and not just when it comes to medical terminology).
As it turns out, terminology and jargon is also a concern in the software systems world. This is because when you’re building or configuring a system, your terminology is the foundation of the system. Terminology shows up as your data fields, your attributes, your measures, your metrics.
Here’s the problem: If there’ s not a common understanding of that terminology, then you’re getting off on the wrong foot.
Not a binary
Let’s try a little imagined scenario. Say you got a grant, and you’re having an app designed for your department, or for your research.
Arriving at clear definitions and shared meanings is trickier than it sounds.
For instance, sometimes, a term can be so downright ordinary that it’s easy to imagine it means the same thing to everyone.
Take something as straightforward as a date. You want your app to ask for the visit date, i.e. the date the patient was seen by the provider. If you ask your developer to include a field for ‘date,’ unless that is really well defined, it could get easily confused with other dates: the record creation date, the date the visit was scheduled on, the follow up date, the prescription fill date.
If you’re not aware of all of these dates, going into the specification, you have a problem. (Especially if you want your digital health tool to play nicely with others!) That’s to say nothing of the confusion a patient might feel if they see a field for ‘date’ and aren’t sure what to input.
That’s a lot of confusion around a pretty straightforward concept. When the concept in question is more complex, there are even more chance for misunderstanding. Imagine all the different ways these complex concepts could be (and have been) defined:
- gender
- race
- family structure
- diet
- alcohol or cigarette use
Consider: how many options are you giving people when they have to provide information like this? Because we’re not talking binaries here, folks!
More problems down the line
How you’re defining a term dictates how you’re collecting the data. Remember, terms are the foundation of the system. If they’re not well defined between you (who’s having an app built) and your software developers, you’re in trouble.
What could happen if the problems of shared understandings don’t get addressed?
- There can be confusion when soliciting information
- Apples-to-oranges problems when data is used downstream.
- Data could be used in the wrong way
- Data might not be reportable or usable
Perhaps worst of all, you’re going to have built a data model and a system that embodies misunderstandings.
Whose responsibility is this?
I.A. Richards famously defined rhetoric as “the study of misunderstanding and its remedies.” Misunderstandings and miscommunications are part of why the field of health communication exists. To address issues like this in the patient encounter, in face to face communication, in patient education materials, in public health campaigns, in health education, and more.
For that app you’re having built in our imagined scenario, if you’ve got a good business analyst, it’s part of their job to make sure requirements are clearly defined, understood, and properly implemented.
It would help if you can stay very much engaged in the process, catching little things along the way. Remember, at the end of the project, the developers will say, ‘We gave you what you asked for.’ So, what are you asking for? Stay vigilant and watch those terms.
If your organization needs someone who can be an advocate for the patient–from the inception of the project through implementation and user testing–contact me. I’ll help you bridge the ‘language gap’ between health experts, IT experts and patients.
Because this is about being very clear to ensure that there are shared meanings.
What can you do?
Many of us are not near the creation phase. Often, we’re using the tools someone else has designed and purchased. If this is you, what can you do?
Keep your eyes open for any terms in an app or a system that could be interpreted in multiple ways
Have the terms been clearly defined, maybe in the help section? Are there resources, like a help request or ticket you could raise, that can help clarify the terms so that the data can be collected and/or used with more confidence and clarity. Again, you’re aiming for shared meanings and shared understandings, so that things work the way they’re supposed to work.
Be critical consumers of data
Keep it in context . Read the data you’re getting in relation to everything else you know about an individual or group. Remember that because something is quantified doesn’t mean it’s objective.
