9.Thou shall remember the end user and patient
Sponsors are an IRT vendor's clients, but sites and their patient are their customers. Sites are the primary users of the system, to the benefit of their patients who are looking to find relief from their unmet medical needs (some phase is not with standing). The system must be designed with them in mind. Remember, there is often a patient waiting. That patient could also be your mother, father, friend, next door neighbor etc..With accuracy and reliability satisfied, next it must be easy and fast. Simplicity of design serves these users best. Just because a system can do something doesn't mean it should do it. It is easy to overengineer: it takes forethought and discipline to make it simple. There is an old story about a priest who said, "I would have written a shorter sermon, but I ran out of time.".
10.Thou shall not have hard stops
Through the experience gained from the early days of IVRS this has mostly been adopted, but there are those who insist on the practice, grinding transactions to a halt and requiring human intervention. My experience has been that hard stops are almost always overridden by sponsors when a patient is on site. It is not until that moment that they realize the difference between the theoretical world of a written protocol and the real world the sites and patients live in. The fact of the matter is that sometimes visits must happen outside of a window, and not allowing a patient to be treated is unethical.11.Thou shall develop and enforce standards, until it is time to break them
The best way to get efficiency, repeatability, and quality from an IRT is through the use of standards. They are not required to develop an IRT and if you are a small company that has a transactional approach it is understandable for this to not be high on your list of IRT imperatives. For companies desiring an enterprise approach to IRT, standards are a must. You won't attend any conference on IRT without a discussion of standards.Standards work best, and perhaps only, when there is alignment with cross functional upstream processes and the teams that support them. Standards can be a bulwark against rogue teams who want to do things their way because "this is the most important study in the company". I used to hear that phrase a lot. But you also need to know when to break a standard. There will be times when it is necessary, either to support a unique design or an operational imperative. But it must be infrequent, impactful, well thought out, and agreed to by cross functional teams. If that is the case, vendors need to yield when the decision is made to break the standard.
Learn More
