Evidence

Like all of us, URAC's accreditation reviewers often are pressed for time. They operate under quality and performance guidelines that help them plan how much time they need to set aside to perform your desktop review. Their lives can get pretty messed up if they encounter an application that is more difficult to navigate than the ordinary application. Therefore, you want to make their job easier so they can spend their limited time focusing on the important issues in your application, not basic navigational questions.

One of the big potential snags -- multi-section standards -- can be made much, much easier for the reviewer if you follow a couple of easy tips when you submit your application through AccreditNet:

• Point to specific language in the submitted documents. Particularly in cases in which the standard has several subsections, reviewers have a strong preference for being told where they can find the language to support subsection (a), where they can find the language for subsection (b), and so on. The word "all" can cause a reviewer's heart to sink.
• Reference all the subsections of a standard. A corollary to the first point is that, for multi-section standards, since you should generally not use "all", you should reference each subsection. Where you don't reference a particular subsection, it suggests that you do not have documentation to support that subsection. Not a good message to convey.

So, what would following this advice actually look like?  URAC's AccreditNet Instruction Booklet gives the following example:

Document, OrgABC section A.3 on page 1 for evidence supporting Core2c

While this is good, we think it may be a bit wordy.  Our URAC consultants recommend the following format for notations in the "Citations" section under each document:

Core 2(c)/P. 1, Sect. A.3.

Note that this concise format works only if you've got a numbered document.  It can get pretty cumbersome if your documents have no paragraph numbers (e.g., Core 2(c)/ P. 1 fourth bullet).  So, where possible, convert all your policies into a numbered outline format.  

There are so many multi-section standards in a typical module that just following these two tips can save your reviewer lots of time, even hours.

Think about how you feel about people whose consideration and good adminstrative skills save you hours of your time!  You definitely want that kind of good feelings coming your way from your URAC reviewer!

Over the years, many applicants have taken the sound approach of borrowing language directly from URAC to use in their policies and procedures (P&Ps). Tracking URAC's language closely often can help you avoid quibbling with reviewers.

However, cribbing URAC language may not be sufficient. More often than not, URAC language is written at the "policy" level, with not much procedure attached. URAC reviewers have been known to reject such high-level statements of policy, under the theory that a proper P&P should guide your staff on how to implement that policy.

So, then, what should go in the P&P? Well, it varies from one standard to the next, but the best rule of thumb is, in my opinion, to reference the program guide as much as possible, particularly the sections under the standard called "Evidence for Meeting the Standard", "Interpretive Information/Commentary", and "Points to Remember". If you can weave some of the comments from those sections into an explanation of how you implement your policy, and do so in such a way that a new employee would have a pretty good idea as to what he or she needs to do in order to implement that policy, then you've probably hit a URAC home run. If not, you may get the P&P returned to you in the Desktop Review Summary with a comment indicating that the P&P is not sufficiently detailed to demonstrate compliance with the intent of the standard.