To the QA community, there is never such a beast as too much validation. As probable frustrated lawyers, "they" are content to make business life so onerous that no productive work or project could ever be accomplished or implemented. "They" fail to realize that it is impossible to test every software pathway unless you have the code in front of you, and even then, the number of pathways in a software function is enormous. Therefore, validation is only limited by "their" imagination. Sorry, I guess my baggage is showing ... Validation is generally defined by the quality community as producing evidence that confirms a product or service meets the requirements for which it was intended. However, the FDA thinks validation is "Establishing documented evidence that provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes." The words "high degree"and "consistently" drive QA people nuts! Practically speaking, my definition of "enough validation" is that you have tested something with enough examples and in enough ways to allow you to sleep at night. To me, that means that the technical aspects meet my requirements, that the limitations are known and controlled in normal operations, that procedures are accurate and well-written, that people are well trained, and that there is a formal or informal audit of the function to watch the process after implementation. For a plan, I usually start with the vendor's validation guide, then expand it until I'm comfortable. To my Medical Director, he needs to know that my work was done with due diligence, that I covered all the relevant bases, that the clinical risk of continuing the old way is equal to or more than the risk of introducing the new way, and that he won't have to sign any BPD in the near future beause of it. To my Admin Director, she needs to know that it won't cost her any more money. Heaven forbid if expenditures increase without a bump in revenue! Some words of advice: first, make sure that the software is FDA-approved for eXM; your vendor should be able to supply this documentation. Second, play with the software, so you know what you're working with. Then, develop a plan and have everyone who will approve it sign off on the plan -- that way, they can't change the requirements (like the government does) in mid-stream or after the fact. Note that the validation guide that the vendor gives you is what they require for activation; it may not be enough for you! Conduct and document the validation, understanding that not everything will follow the plan exactly. Next, write up the final validation report for signature, summarizing everything that happened during the validation project. If the report mimics the plan, there should be no problem with the conclusion and approval. Finally, train, train, train before implementing! (Your validation SOP should say all this already.) Final word of warning: never, ever, do anything for the sole purpose of saving money or for handing to a future inspector, if requested. It has to be relevant for you and no one else!