Turning Health Requirements into Quality Content

The content strategy world is a welcoming one, and I’ve been grateful to benefit from articles that share advice and best practices. There’s Jonathon Colman’s 2013 (but often updated) Epic List of Content Strategy Resources, one-off articles like WebpageFX’s Information Architecture 101, and my own list of copywriting resources, to name a few.

It’s harder to find resources to help translate requirements into content – particularly in healthcare.

Why do we need help in healthcare content?

Aside from the fact that health literacy is at a bogglingly low 12%, health care itself can be very complicated – and the terminology is not exactly simple. Patients struggle to understand providers’ websites and emails, and as content strategists it often gets dropped at our feet to figure out a solution.

Many first-time health writers and content strategists will dig in, wide eyed and eager, only to find their every content change slashed and shut down by compliance and legal departments.

It’s not that healthcare has to be confusing. Much like legalese, much of health’s complexity is because “that’s how it’s always been done.” Good health writing requires three things:

  • Knowledge of the requirements
  • Empathy for the target audience
  • Relationship with Compliance teams

Know the Requirements

When it comes to HIPAA, NCQA, and other health requirements, their goal is to improve content – not make it more difficult to create. Unfortunately, for many busy content teams, the requirements are just a checklist that result in adding more stuff.

  • HIPAA says you need to make sure people know whether a site’s secure? Add another disclosure.
  • NCQA says to make things easy to use? Build more tools.
  • etc, etc… for 1000s of pages that visitors can’t find

But there’s another way.  If at all possible, someone on the content team should become familiar with the requirements. When Legal or Compliance teams need to translate them, the content team ends up just taking orders, typically to build more content.

When there’s a content strategist/creator who understands the requirements, they can begin to consider why the current content doesn’t fulfill the requirements, and how to change or update the experience, instead of adding more.

Check out Allison Bland’s article on how to interpret NCQA requirements

Build Empathy

The amazing thing about requirements is that they come from somewhere. They have a goal. But sometimes the goal is difficult to comprehend. It’s easier if you come at it from the patient or consumer’s perspective.

Without empathy it’s easy to take requirements literally, and do whatever’s easiest to check off the box. But ideally these requirements are meant to be understood, and the spirit becomes as important as the letter of the law. To do that we need to consider where the patient or consumer is, what they’re trying to accomplish, what their background is, how much they understand about the process, what barriers they might face, how much time they have, and anything else that may impact their ability to accomplish the task at hand.

Empathy can come from many places. I find it particularly helpful to build out personas and create empathy maps.

Meet the Compliance Team

Of course, it’s also easy to become to empathetic to the consumer or patient that you just feel frustrated with the Compliance team. Requirements can be interpreted in many ways, and the Compliance team doesn’t always interpret a requirement the same way the content team does, which can cause frustrations.

There are many ways to handle this:

  • Giving in: some people will just change whatever Compliance says to, assuming they know best
    • Pros: it’s easier, and Compliance can ensure that requirements are being followed
    • Cons: it can result in losing sight of the patient or consumer’s needs
  • Championing the user: some people will push back on everything Compliance requests, to make sure that the patient or consumer is always served
    • Pros: it ensures everything is very well considered
    • Cons: it’s exhausting and frustrating for everyone
  • Picking your battles: some people will go along with Compliance changes that feel like smaller “wins” but select the major changes to push back on
    • Pros: better working relationship
    • Cons: still approaches the relationship as a war
  • Working together: I recommend building consensus, rather than siloing Compliance and Content teams
    • Pros: best possible relationship AND good for the end-user
    • Cons: it takes time and effort

I recommend working together. Have lunch with the Legal or Compliance person. Take opportunities to share the insights you’ve gained from empathy mapping and studying the patient or consumer, and ask for help understanding why they make the changes they do and how they interpret the requirements.

The end result will be a better shared understanding that allows both teams to learn from one another and do a better job interpreting the requirements to create high quality content.

The Magic Button

There’s no magic button to make requirements easier. Most of these recommendations mean additional upfront work, and maybe even more time put into content creation in general. But they also result in better websites, better experiences, and better ROI.

Requirements weren’t meant to be blindly followed. They are there to ensure we serve the needs of our target audiences – and we need to take them seriously and learn to understand them. Our audiences deserve it.

Marli Mesibov

Marli is a content strategist with a passion for the user experience. Her work spans websites, web applications, and mobile. Marli is the VP of Content Strategy at the UX design agency Mad*Pow, where she helps healthcare, finance, and educational organizations communicate with their audiences. Marli is a frequent conference speaker, and has spoken at conferences including Content Strategy Forum and LavaCon. She can also be found on Twitter, where she shares thoughts on content strategy, literature, and Muppets.

Leave a Reply

Your email address will not be published. Required fields are marked *