On Providing Feedback for HealthIT Standards and Regulations

I spend a lot of time reviewing Health IT standards and regulations, something I'm preparing to do for the next HL7 ballot cycle for which signup closes on Friday, and also on the HHS's draft strategy for reducing regulatory burden. One of the things I was taught (by both HL7 and IHE) was how to provide feedback, and that same technique also works quite well when providing feedback on regulation.

The basic principles are the same:

1. Focus on what is important.
2. Coordinate your feedback with others.
3. Provide the solution first.
4. Include your rationale, with facts to back it up when available.

Focus on what is Important

This is the key.  In both standards and regulation, there are parts that the person or organization following the requirements in the document have to do, and parts that explain that and give rationale, and parts that simply introduce new material to the reader. 

Usually, when providing feedback, I'm MOST interested in the requirements, and least interested in introductory material.  My general priorities for feedback are in order: Meaning, Clarity, and Grammar.  Meaning addresses what I have to do or not do.  Clarity further defines what I have to do so that it is clear and testable.  The statement: "The system must be able to read C-CDA 1.1 or 2.1 documents" is unclear.  Does the system pass if it can read C-CDA 1.1, but not 2.1 (or the reverse)?  Or must it do both?  A more clear statement would be "The system must be able to read both C-CDA 1.1 and 2.1 documents."  I don't write spelling and grammar software any more (not since about the turn of the century), so I rarely focus on grammar or spelling except where it's important (e.g., HER for EHR).

In regulations, I generally skip the introductory pages up through the statutory authority simply on that basis.  Usually, when I'm reading a regulation, I already am familiar with the why and wherefore, and the statutory framework.  In standards, I often skip the scoping and introductory pages.  And when I say skip, I mean "skip in my first quick read-through".

Which brings me to the second part of focus.  I typically do three reads of a document: A quick scan, a deeper review of important parts, and a final read through of everything I think that matters to see if there's anything I missed.  For particular important things, I may just skip the "important parts" read through, and read the entire document start to finish.  But you can't do that last in one sitting for a 500 page document.

The first read through is a quick scan to identify the areas of most importance or concern.  When doing this, I don't need to read every last sentence.  I can generally get a quick idea of what is important by first looking at the table of contents, and then reading the first sentence of major paragraphs, diving a little deeper if they prove to be interesting.  This read is usually the one that I usually do my "twitter note taking" with.  Something that captures my attention gets a tweet, all tweets get the same hash tag, and if I have a quick though about the impact, that goes in my tweet as well.  You don't need to use twitter in this read through like I do, but you do need to take notes.  This is basically using a highlighter in the document so you can go back and assess.

The second read is deeper, and focuses on those sections that I've identified as important.  I generally go a bit wider than my first scan would suggest, just to see if there's something I missed.  If there's three paragraphs in a ten paragraph section that I find important, I'll probably read the whole section.  If a whole section is important, I'll look at material elsewhere that might introduce that section, or describe the scope for it that might appear elsewhere in the document.  That's where my notes are important, and I'll go back through them to understand what I have to look at more deeply.

The last read is of the whole document (save material I already know I know).

Coordinate your Feedback with Others

In both kinds of documents, you aren't alone in having to provide feedback, and you won't be looking at every perspective.  Sharing your feedback with others serves two purposes: 

1. It helps you validate your point, and perhaps clarify it further.
2. It helps others who think the same way as you provide supporting feedback.  The more that the originator of the document hears the same or similar comments, the better chance you have of your comment having an impact.

Coordinating your feedback can be done in several ways.  You can coordinate internally within your organization, you can also coordinate with other organizations.  For example, the HL7 Clinical Decision Support workgroup is planning on providing some of its feedback to HHS on the reducing regulatory burden.  Finally, since public comments are just that, public, you can seek out the feedback of others who have already provided theirs before preparing your own.  This last method can also be helpful in identifying things you want to focus on, so you might even consider reading the feedback of others before reading the document (especially if you are stretched thin for time).  I generally use similar but not identical wording as others when I'm coordinating feedback in this way.  Most of the time, this is much more effective than providing identical wording, because exact duplication of comments can work against you.  It's too easy to exactly duplicate the words of others, and people can become inoculated against a viewpoint they've seen too many times.

Sharing your feedback directly with others is extremely helpful, and remember, it's already going to be public, so you might as well take advantage of it.

Provide the Solution First

This is pretty simple.  Write what you would have preferred to read in the regulation or standard, rather than what you actually read, and propose the new text replace the old text.  This saves the people having to respond to comments from having to do the harder work of revising the regulation or standard.  The tricky bit here is to write in the same style as the original document is written in.  There's some obvious stuff here.  If the document uses a particular voice or perspective, you have to write from that same perspective, in the same style (unless your goal is to fix grammar, in which case, go ahead, but recall your priorities).

Explain why your Text is Better

But, don't just write it, explain why the change is better, and back up your rationale with facts.  Numbers are really good to have, and if not numbers, at least something that isn't just "I don't like this".  Explain why your change is better, and don't just argue from a position of authority.  The person reading your feedback won't likely know you from Adam (or Eve), and your authority generally won't matter all that much.

If you can align your text with the proposed goals of the standard or regulation, and explain why it will help the originator achieve those goals, that's even better.

Impacts

If you follow these guidelines, and do your job well, don't be surprise if the text you wrote shows up in the revised document.  I can speak to at least two cases where text I wrote survived virtually unchanged in revised ONC and CMS regulations, more times where I had the desired effect (from my perspective), and plenty of times where similar things have happened in HL7 and IHE specifications.  And there are many times where changes that I wrote about in this blog achieved were quite successful.

    - Keith