Tip:
Highlight text to annotate it
X
And thereby reduce time and costs throughout the clinical trial process
A quality, robust CLINICAL TRIAL MANAGEMENT SYSTEM essentially tracks each step of the
clinical trial process, from study start-up to study close out. It also serves as an essential
repository of clinical trial management information, such as investigator, site, subject enrollment,
site visits, payments, etcetera. With a single system, information such as investigator names
and addresses only needs to entered once, which saves time and reduces error. And with
all of your clinical trial information in one place, it is much easier to extract it
and use it to make informed decision about the future or answer questions about the past.
So who needs a CLINICAL TRIAL MANAGEMENT SYSTEM? A CLINICAL TRIAL MANAGEMENT SYSTEM can be
useful to several kinds of organizations of various sizes, such as again pharmaceutical
companies, contract research organizations or CROs, medical device companies or academic
institutions. The common element across these different types of organizations is that they
regularly manage multiple trials at the same time.
Organizations in this situation often use several tracking tools to keep themselves
organized. From paper logs to spreadsheets for contact names and addresses, patient visits,
payments, investigational product supplies, monitoring visits and so on.
Tracking this information in different places causes extra work and creates room for error.
And it also makes it difficult to pull together reports for both internal review and for outside
auditors. Plus, these tools are rather difficult to validate and keep validated. So for organizations
that function like this, a CLINICAL TRIAL MANAGEMENT SYSTEM can be a breath of fresh
air and an investment that pays for itself through the efficiencies that it's going to
enable. Let's discuss some key functions of a CLINICAL
TRIAL MANAGEMENT SYSTEM. A CLINICAL TRIAL MANAGEMENT SYSTEM can support an extremely
robust investigator and site data base that enables complex tracking of individuals and
organizations related to your trials. You can track information such as specialties,
experience, patient demographics, of doctors as well as the facilities and equipment that
are available at various clinics and institutions. In addition to investigators and hospitals,
and clinics, the contacts in the account data base should also allow you to track information
about any person or organization that you may interact with on a clinical trial, such
as lab technicians, pharmacists, and vendor contracts officers as contacts as well as
shipping and printing vendors or CROs as organizations. You can also track the performance these people
and places on your previous trials and then you can query all of this data to streamline
your site selection process or even aid in choosing a vendor for a specific service on
a future trial. This feature enables you to pick the highest performing investigators
and sites and vendors to ensure a smoother trial. So once you've selected your investigators
and sites, you can use a CLINICAL TRIAL MANAGEMENT SYSTEM to track things like essential documents
and other site initiation tasks, to set up subject visit schedules, standard payment
amounts and so forth. So once the study is underway, the CLINICAL
TRIAL MANAGEMENT SYSTEM is used to track everything from site budgets to monitoring reports. For
organizations without a centralized system, each of these bullets you see on this screen
is usually a separate spreadsheet or at the very least a separate tab on one big spreadsheet.
But with the CLINICAL TRIAL MANAGEMENT SYSTEM, all of this information is consolidated and
tracked in one place which requires less work to maintain and enables real time robust reporting.
Also, with a CLINICAL TRIAL MANAGEMENT SYSTEM, many of these processes can be at least partially
automated with integration to other systems, such as the clinical data management system
for subjects and subject visit information and a supplies tracking system for product
supplies tracking information. One of the most useful aspects of a CLINICAL
TRIAL MANAGEMENT SYSTEM can be the enrollment statistics that it provides. You can easily
learn how quickly specific sites are enrolling patients, which sites are consistently experiencing
screen failures, which sites are completing subjects on schedule and other related information.
And you can actually cut that data in any way you'd like such as by country or by study.
So you can get a full access to a real-time enrollment statistics for the entire study.
A CLINICAL TRIAL MANAGEMENT SYSTEM also will streamline your document tracking process,
which we know can be a large and costly component of every trial. A CLINICAL TRIAL MANAGEMENT
SYSTEM can help standardize the documents that must be collected from or sent to each
site, even country specific documents and then this information can be queried to learn
for example, which medical licenses are expiring in the next 30 days or how many documents
are due today but have not yet been collected. A CLINICAL TRIAL MANAGEMENT SYSTEM can also
provide robust financial tracking for sites, countries, studies, projects and individual
primary investigators. And when you integrate that with an accounts payable system, the
site payment process can be entirely automated, except for those steps where you want human
intervention of course, such as payment approvals. And finally, perhaps the most beneficial function
of a CLINICAL TRIAL MANAGEMENT SYSTEM is its reporting capabilities. Of course, you know,
the ability to track all of this information is important, but if we can't get that information
out of the system in a meaningful way, it's not that beneficial. So when all of your trial
data is in a centralized database, the ability to find answers to all of your trial related
questions becomes much, much easier. And when you have real-time answers, you can make well
informed decisions that have real impact on your business.
So now that we know more about what a CLINICAL TRIAL MANAGEMENT SYSTEM can do and what sorts
of organizations can benefit from one, let's talk a little bit about going about choosing
the right systems for your organization. The first step to any software selection processes
is to gather your requirements, and this can be done in a number of ways, such as analyzing
your current processes and tools, reading the features and functionality lists of commercial
systems and talking with your colleagues at other organizations.
Once you have a comprehensive prioritized list that includes feedback from all stakeholders,
you're ready to schedule demos. You may first want to look internally within your organization
for cases where other departments or areas of your business may be utilizing applications
that you can leverage before looking to external vendors for demos of systems.
We had a situation where a company was looking to implement a CLINICAL TRIAL MANAGEMENT SYSTEM
across their multiple global business units and each of their global business units were
operating essentially as individual companies since they were acquired businesses. And when
the CLINICAL TRIAL MANAGEMENT SYSTEM, the global CLINICAL TRIAL MANAGEMENT SYSTEM initiative
was under way, they realized that one of their business units already had a robust CLINICAL
TRIAL MANAGEMENT SYSTEM in place. They evaluated that internal application and determined that
it met their global needs or you know, with a few modifications, it'll meet their global
needs. And they saved a significant amount in licensing and implementation costs by selecting
an internal system. But, if no internal tool or application exists, or is in use, then
reaching out to external vendors for demos is the next step.
Each system that you consider should be evaluated against your prioritizing list of requirements
to ensure objective decision making. After each demo of a system, look at the requirements
that the system did not meet and determine how critical these gaps are and whether they
can be addressed within your budget through customization.
As you gather your requirements, you want to consider the various types of systems that
exist and determine which one makes the most sense for your organization in terms of functionality,
implementation time and budget. A standard CLINICAL TRIAL MANAGEMENT SYSTEM refers to
a system that is used out of the box without any configurations or enhancements. Selecting
a standard system can usually save your time, but you run the risk of not getting all the
functionality that you need. Another option is to go with an accelerator,
which is a standard system that has been pre-configured and packaged so that it comes with several
commonly requested configurations or enhancements. Accelerators are really designed to streamline
and reduce the implementation time and costs for these solutions. So this can be a good
choice for companies that need a robust system but don't have the budget or time for customizations.
A customized CLINICAL TRIAL MANAGEMENT SYSTEM is either a standard system or an accelerator
that has been modified to meet your organization's specific needs. This option is definitely
the best way to meet all of your organization's requirements. But, it also tends to be the
most expensive and time consuming choice. A great way to reduce the time and cost of
a customized CLINICAL TRIAL MANAGEMENT SYSTEM is to start with an accelerator, again that
already meets many of your requirements. So once you've looked at your functionality
requirements and your time and budget constraints, it should become clear which type of system
would best meet your organization's needs, standard accelerator or customized.
Once you have determined your best system type, you will then want to consider the various
implementation options available. And this is where requirements from your IT department
become pretty critical. Depending on the size and capacity of your IT department, you might
want to implement your CLINICAL TRIAL MANAGEMENT SYSTEM completely on site, at your organization
or you might want to share some of that load with a hosting partner.
With an in-house implementation, your organization buys all of the software licenses and necessary
hardware and then stores and maintains that hardware on site. This gives your organization
complete control over and responsibility for the system. But it requires a great deal of
knowledge, time, resources, and physical space from the organization.
With a hosted implementation, the housing and maintenance of the hardware is handled
by an external partner instead of the organization. So this reduces the organization's control
a little bit, but it also relieves if from the burden of having knowledgeable onsite
resources with the time to maintain the servers as well as the physical space to house them.
And recently, hosting has been becoming increasingly popular, especially for smaller organizations
that don't have the capital to invest in a large in-house IT department or just choose
not to. And these days, there are several different hosting solutions to choose from
as well. Dedicated hosting is where your organization
owns all the hardware and the software applications and the external data center is basically
just housing and maintaining the servers. And at any time you still have the ability
to bring that hardware and software internally for a complete in-house setup.
Shared hosting is where you own or your organization owns the software application, and you are
essentially leasing the space on the hardware which your software is on and the data center
is maintaining it. So if an organization wants to bring that application in-house, they would
just have to make a hardware purchase and bring in their application which they own
licenses to, onto their in-house hardware. Cloud Computing or software as a service,
known as SaaS assumes that in this scenario, the organization doesn't own the hardware
or the software and is essentially the service to be able to use the applications on demand.
And as their user base or demands increase, they just increase their subscription accordingly
with their external vendor. The organization doesn't incur any costs for hardware maintenance
or replacements because they don't own anything in this scenario. They are just simply using
the software as a service. So, clearly, there are many things to consider
during this selection process and not just functionality. So here is some best practices
to make sure that you ended up with exactly what you need.
You want to start by identifying all of the stakeholder departments and representatives
from each to collect feed-back from his or her respective departments. Once you have
gathered all that input, ensure everyone's needs are addressed by the list of requirements.
Don't forget to consider where you are today and where you plan to be in two to five years.
You're going to want to have a system that can grow and support you as you grow as an
organization. Next, don't limit your requirements to simply
system functionality. You want to consider system types, hosting options, along with
data migration and integration needs. Also include soft requirements such as vendor responsiveness
and the level of help that support that is required by your organization.
Finally, once you have a comprehensive list, you are going to need to prioritize it. And
get buy in from all the stakeholders on that specific prioritization. Divide your requirements
into must-haves and nice-to-haves. And then rank your nice-to-haves. Assign different
weights to your nice-to haves, and develop a scale such as 0-5 with 5 being meets the
requirements exactly. So if you use a numerical system like this, you'll ensure objectivity
and a system the truly meets your needs. Once you have selected your system, and your
implementation options, it is time to determine your implementation strategy. For implementations
that involve anything beyond using the system out of the box, there is always the question
of "Big ***" versus phased. The "Big ***" approach is very enticing because
it means you get everything you need all at once. But it also means a large, upfront investment
and also a long waiting period before your users actually get to use the system. Also,
we have found that once users actually begin using a system in their day-to-day lives,
they usually discover additional requirements. And the "Big ***" approach generally depletes
budget for future enhancements, at least for a while. So, the users have to wait longer
for these additional requirements to be addressed. We had a fewer early adopters of the Seibel
CLINICAL TRIAL MANAGEMENT SYSTEM solution take on the Big *** approach, in which they
included significant application enhancements, data integration, data migration and system
automation components as well. The projects were pretty large projects, which in some
cases took approximately two years to deploy the initial phase. And since data integration
(cough) excuse me, data integration and migration and some of these other components are dependent
on the base application functionality, it ended up being like trying to hit a moving
target in completing those aspects of the project and led to multiple iterations and
additional time. Also, once they deployed the systems and had the users use it for a
few months, you know the users inevitably came up with additional requirements or enhancements.
And that not only affected the base application configuration, but then they needed to update
the integration, you know the interfaces as well in subsequent phases.
So, what we recommend is that you plan for a phased implementation. This strategy allows
the core critical business needs to be addressed in the initial phase quickly, and then requirements
to be refined at the beginning of each subsequent phase, based on input from users that are
now actually using the system. So, this also allows for a stable system first, from which
then to build integrations in a phase two or phase three scenario. And in addition to
the flexibility this strategy provides, user feed-back is generally more positive with
this approach as is user adoption. Because new tools and new processes are easier to
accept in smaller doses, smaller chunks. So the more quickly your users master this new
system, the faster you can see the return on investment. But, a phased approach alone
is not going to guarantee success. There is a lot more work to be done well in advance
of your go-live date to ensure smooth transition to your new system.
So prior to beginning your implementation, here are some steps that we recommend that
you take:
Assemble your project team. Make sure you include representatives from all of the key
stakeholder groups, including IT and each area of the business that will be affected
by the new systems. Determine who will lead the project, who will have the authority to
make decisions, who will be part of the core team, who will be part of the extended team
and then decide how often the core and the extended teams will meet and how much time
in between meetings each member will be expected to work on that project. Then write all of
this down in a project chart or project definition document and have the team formally agree
to it. And for team members who are non-mangers, consider having their managers approve their
employees time commitment to that project. Next, determine the tasks, deliverables, deadlines,
and responsible resources. Be sure to include all of the tasks that we mention in these
best practices and not just typical system development life cycle or validation tasks.
Next create a scope control plan. We have seen this in the past. It is incredibly easy
for a project scope to creep during implementation, especially a long one. So, it is very wise
to come up with a strategy for handling that ahead of time. So, putting in a formal process
for requesting, reviewing and approving scope changes you're going to ensure that all of
the downstream changes, you can ensure that all the downstream effects are considered
and only the business critical changes are accepted.
Next designing your communication plan. Consider all of the audiences of the project. The Topics
and level of details each group is going to be c, going to care about, the best method
for reaching them and the frequency which each group needs to be updated.
Next, beginning your SOP gap analysis. So once you have selected your system, you should
have enough information to begin analyzing your existing SOPs and identifying the gap.
And as I am sure you will all agree, the SOP review and approval process can be quite lengthy.
So it's best to start working on this task as early as possible.
Next, begin analyzing the organizational structure. With the introduction of a new system, the
structure of the organization around it will most likely change. The best is to start considering
these changes early so that you can identify the gaps and begin figuring out who will fill
them. A key consideration for CLINICAL TRIAL MANAGEMENT SYSTEM implementation is how the
administration tasks will be handled. Will it be centralized or decentralized? And we
generally, generally find that centralized approach works pretty well, but it truly depends
on the organization, uh the organization's culture and needs.
So once you've created your formal plans for managing the project, stick with them. That
way everyone involved in the project will know exactly what to expect and what is expected
of them. But it is also wise to consider your communication plan as a living document, so
that you are able to make adjustments when you receive feed-back that the communication
needs is either too frequent or too infrequent to high level or too detailed.
Once a project is underway, it is time to start designing your rollout training and
support plans. Are you going to be planning a release of the system to all the users at
once? Are you going to pilot a single study first? Will you cut over mid-study or will
you maintain two systems simultaneously for a while?
Once you determine your rollout plan, you can start formulating your training plan.
If all the users are going to go-live on the system at once, you will need to plan for
training all at once. If you are going to make the transition study by study, you're
probably going to want to train one study team at a time.
So, once you have determined who will be trained and when, you can decide which methods and
materials are going to be most effective again, based on your organizational culture and the
characteristics of the user group. And incidentally, like I mentioned before, we are conducting
an in-depth workshop on this topic at next month's CBI CLINICAL TRIAL MANAGEMENT SYSTEM
conference in Philadelphia, March 24th and 25th along with one of our clients. And so
this is going to be a three hour workshop on to build an effective training program
for CLINICAL TRIAL MANAGEMENT SYSTEM. And if you want more information, or are interested,
please email me and I can get you some discounted registration rates for the conference.
So next is your support plan. The post go-live support plan should include multiple levels
of support. And we often see clients use or identify a super user in each area of the
business who serves as the first tier of support for the users in their respective area. Followed
by an in-house help desk and then an external support service. But beyond identifying these
tiers, the support plan should consider also how to maximize the help tools that are built
into the system as job aids and refresher training and other training documentation.
So as you can see the rollout, training and support plans are very much linked and interdependent.
They require a lot of careful thought and consideration to support both the immediate
needs and long term success of the project. Another best practice related to user adoption
is to involve the users early and often. Not only should they be involved in the selection
process and project team, but they should be involved in design workshops and document
reviews and even test executions. Consider having a sand-box environment as early as
possible for the users to sort of play in with the caveat of course that development
will be ongoing. Also plan on to have everyone who will be involved in test executions formally
trained before the testing. And that's going to ensure a smooth testing process and minimizing
anxiety in the testers. For example, if they don't know how to use the system, and they
struggle with the test steps, they may develop a negative view of the system and become resistant
in adopting it. So, the sooner the users are exposed to system, the smoother the transition
will be. And as you can imagine, implementation of
a new system is probably a great time to review or possibly create a data standards document.
This ensures that all of users know how and in what format data should be entered into
the system. This document should cover everything from what is entered in each line of the address
record, the accepted and not accepted use of abbreviations, accepted use and values
for comments fields, to the format of a site number.
We've had scenarios in the past that where a client implemented a system, but didn't
take the time to develop clear standards for data. And that led to things like addresses
in the system that were 100 Main street with street spelled out S-T-R-E-E-T and then 100
Main St. as you know, street abbreviated with ST. (period) in the system. So multiple records
that were essentially the same record, just because we weren't following these data standards.
And some users were using address line 2 for department names, address line 3 for suite
number and other users were using address line 3 for department names and address line
2 for suite numbers, so they were sort of switching it. But you can imagine that, you
know, querying the application turned into a nightmare since users didn't know which
field to query for that specific information. So standardized data makes the querying of
the data simpler and the reporting of the data cleaner.
And finally, prior to go-live, it is incredible helpful for a mandate to come from executive
business resources, such as the project sponsors that the CLINICAL TRIAL MANAGEMENT SYSTEM
must be used you know according to the release schedule. And then the use of Legacy worksheets
and logs has to be discontinued. This is probably one of the biggest reasons for low user adoptions
for new systems. If there is no clear directive that as of a certain date, old ways of tracking
our trials should be discontinued, users will continue to use those old methods. But if
it is clear that this is the expectation of everyone from senior leadership, user adoption
typically doesn't become an issue. So I will now open up this session for any
questions you may have. And again, if you do have a question, the best method to use
is the chat feature to submit your questions and I will address the questions as we receive
them. So let me, um, we actually have some questions that have been entered so I will
look at those right now. Uh, What features does Oracle's Siebel clinical
trial management system add beyond the trial management capabilities integrated in Oracle
Clinical? Um, hmm. Trial management capabilities integrated
in Oracle Clinical. So, I will try to address this question and maybe whoever submitted
this can submit a follow-up, but I mean Oracle Clinical is your clinical data management
system, so all of your actual clinical data, your CRFs, your data on the CRFs is going
to be housed in your clinical, in your Oracle Clinical system. Your clinical data management
system. Your CLINICAL TRIAL MANAGEMENT SYSTEM, or Seibel Clinical system is all the metadata
around, um, around your clinical trials, so tracking all the activities, all of the investigators,
the sites, you know what activities are happening, what's the progress of the trial, sort of
the study management aspect and site management aspect of the trials. And that is what is
captured in Seibel Clinical or Seibel CLINICAL TRIAL MANAGEMENT SYSTEM and where the two
sort of over-lap or the integration where it becomes sort of the likelihood of integration
between the two is around the subject and subject visit activities. So as, CRFs are
being collected, as subjects are being enrolled, and visits are being completed, those are
key pieces of information that could tie, that would tie in your clinical data management
system to your clinical trial management system and automatically complete those subjects
and subject visits because your payment to the investigator are tied to that subject
and subject's visit information. So, that is where we have seen that integration in
between the two, um between the two systems. Alright, next question is: What is the typical
size of project team? So from a business perspective, you know,
typically, it depends on, you know how many different departments, how many sort of business
units have that are represented. But, typically, on the business side, you can see involvement
from the at least one or two representatives of key functions in the systems. So, a couple
of study managers, a couple of CRAs, somebody from clinical finance, obviously somebody
from IT, from an executive, you know clinical executive. So those are typical people that
are going to be involved in sort of a core team scenario where, where they're providing
the requirements from the business side. And the extended team is you know, not as involved
as much, but they're sort of, you know, um, the communications from the project team are
taken from these core teams back to the extended teams and vice versa. So requirements are
being fed from the extended team to the core team. So, on the business side, that is what
the project team make up looks like. From an implementation side, it really depends
on, you know, again, whether, you are doing a standard implementation versus customized
or an accelerator. You know, obviously, a customized implementation will see a larger
project team for, you know a couple of different, you know, functional resources that will focus
on design and testing and training and then development resources focused on the development
and configuration and the installation portions of it and project management of course. So,
you know, these teams can range from three, four, five resources for you know, very, you
know sort of standard or accelerator type of implementation. And we've seen, you know,
of pretty large teams of, you know, twenty plus on very, very complex implementations
of CLINICAL TRIAL MANAGEMENT SYSTEM solutions. Let's see. Do CLINICAL TRIAL MANAGEMENT SYSTEM
systems provide functionality down to the patient and clinical scheduling levels and
other site activities? Absolutely. So, site management activities, everything from, you
know, creation of the site, tracking your site contacts, your site personnel, address,
your site supplies, things that you are shipped out to the site, the site activities, site
documents is a core function of a CLINICAL TRIAL MANAGEMENT SYSTEM. So, tracking all
of your essential documents that you are sending to the site and receiving from site and everything
down to the patient level. So protocol deviations, subjects, subject visits and even down to
the procedures that are done on each of, or on, on each of those visits. So, yes. All
of that is typically housed within a CLINICAL TRIAL MANAGEMENT SYSTEM.
What is typically used for clinical research departments in hospitals?
We haven't, I haven't come across, I haven't been involved in too many implementations
that involved hospitals per se. But if there is clinical research, their trials typically
run a slightly differently from organizations such as pharmaceuticals or CROs and they tend
to use internal staff, internal investigators, a lot of investigator initiated stuff as well,
that happens in those organizations. But I don't have a lot of information to provide
around specifically, you know, what their, what, what their , what they typically use
for clinical research in hospitals, unfortunately. But I know that their, um, standard types
of CLINICAL TRIAL MANAGEMENT SYSTEM solutions that we see on the market like the commercial
systems don't really lend themselves to hospital type of, uh, scenarios.
In a phased approach, how do you determine the scope and priority of each phase?
That's a great question, so, for, in a phased approach, what typically happens the beginning
of your, your, um, of your implementation, your still gathering requirements, so before
you prioritize your requirements, you still have a full listing of all the requirements
that your users want to meet with a CLINICAL TRIAL MANAGEMENT SYSTEM. And so the prioritization
step is really determining what, what is going to get slated for each phase. So you are essentially,
on that step, on that second step, is essentially developing a CLINICAL TRIAL MANAGEMENT SYSTEM
road map for, um, for your organization. So that's really what, what the activity that
takes place to determine what activity goes into each phase. And typically, what we see,
what I said recommendations is core functionality in phase one, and um, you know, further enhancements
and potential integrations in phase two and then, you know, further sort of system automations
in phase three. You know, you can sort of have a general look at how you should be phasing
these requirements in based on that. Okay, let's see, um. Have you seen RDC access
managed through CLINICAL TRIAL MANAGEMENT SYSTEM, as in approving users who should gain
access to RDC trials? I am sure there is probably some, some, you
know opportunities for integration, within CLINICAL TRIAL MANAGEMENT SYSTEM and specifically,
that feature of approving users who should gain access to RDC trials, but I haven't seen
that done for uh, that specific purpose, but we have, like I mentioned, we have seen integrations
between multiple different, you know, EDC vendors, electronic data captures vendors,
RDC and other EDC solutions that have integrated to seeking that solution such as Seibel Clinical.
So the integration between the two, like I mentioned is, you know, is purely, largely
focused on subject, subject visit and activity specifically. So, that information specifically,
and even protocol deviations in some cases, adverse event. So those are some of the key
areas that we have seen integrations between CLINICAL TRIAL MANAGEMENT SYSTEM, and um,
integrations between CLINICAL TRIAL MANAGEMENT SYSTEM and clinical data management or EDC
solutions. Umm, here's a question: Says you estimated
the cost of approximately a million dollars. What is this cost estimate include?
You know, I, I have to sort of be careful, but by saying typical implementations, cuse
there is no real typical implementation of a CLINICAL TRIAL MANAGEMENT SYSTEM. Because
it varies so much, but you know, what we have seen for mid-sized to large organizations
implementing say a Seibel Clinical, and doing a customized Seibel Clinical implementation,
you know what they've, you know, what we've seen happen more often than not is a nine
to twelve month implementation with you know again, with core functionality being the focus
of the first phase and utilizing external implementation vendor , you know, implementation
costs can run on the upwards of a million dollars or more. And that's really just to,
you know, take it, take something from sort of a base product and out of the box product,
to addressing all, well all of your core organizations requirements around CLINICAL TRIAL MANAGEMENT
SYSTEM. So, again, that first phase is of adding new fields, adding new view screens,
terminology, new modules to track specific things that your organization needs to track.
Taking that system from out of the box to that level, you know, we've seen it take,
you know, around a million dollars, nine to twelve months. And in some cases even more
than that. Uh, you know, organizations that, particularly CRO organizations where they
have specific requirements that need to be met from a sponsor type of scenario, they
end up spending a lot of money on those customizations. So, that's where that sort of estimate comes
from. But, I mean, it, it ranges from anywhere from a few hundred thousand dollars to upwards
of a multi-million dollar implementations. But now with the, the, the intro, introduction
of, of accelerators there's, you know accelerators in place that will reduce your implementation
time down from, you know nine to twelve months, down to nine to twelve weeks of implementation,
because, you know these accelerators have already addressed a lot of the gaps in the
base products, and um, offer, offer these uh, accelerated solutions that reduce time
and reduce cost. And, and even further, you know, there's even cloud computing and SaaS
on demand services, that are, that are on the market that we offer as well BioPharm
on demand so accelerators on demand further reduce the implantation time and the, um,
and the cost for, for having a CLINICAL TRIAL MANAGEMENT SYSTEM implementation done for
your organization. Here's a question: You mentioned adverse event
tracking is potentially an aspect of a CLINICAL TRIAL MANAGEMENT SYSTEM and the question is
can a CLINICAL TRIAL MANAGEMENT SYSTEM take the place of a safety system?
And my, uh, our answer or recommendation would be no. You don't want to over extend your
CLINICAL TRIAL MANAGEMENT SYSTEM solution to, it's not going to do what a safety system
like Argus is going to do for safety reporting and tracking. The only aspects of safety tracking
that we do within the system or we either typically customize or as part of our accelerator,
is purely for monitoring reconciliation purposes. So clients typically have the need to, you
know from a monitoring perspective, when their monitor goes out to the site, how many adverse
events are on file and sort of basic information about them around, you know, when they were
identified and when they were sent to safety et cetera. So just from a monitoring perspective,
you can utilize your CLINICAL TRIAL MANAGEMENT SYSTEM to track that information, but it certainly
not meant to be a safety system like Argus. But, un, but there are, you know, areas and
there are opportunities to integrate the CLINICAL TRIAL MANAGEMENT SYSTEM solution with the
safety system and we're actually working on a couple of those right now. So, you can actually,
again for reconciliation purposes you can tie your monitored, you know adverse events,
in CLINICAL TRIAL MANAGEMENT SYSTEM with the actual safety case records within, within
Argus. So, that's, that's another opportunity for integration.
Do CLINICAL TRIAL MANAGEMENT SYSTEM applications need to be validated?
That's a great question. So, we have seen a variety of this. I would probably say that
the vast majority of clients do validate their CLINICAL TRIAL MANAGEMENT SYSTEM at some level.
And, so, again, they take a risk based approach depending on how they are going to be utilizing
their CLINICAL TRIAL MANAGEMENT SYSTEM and they sort of identified the risk areas of
the application and choose to validate portions of the CLINICAL TRIAL MANAGEMENT SYSTEM. Those
portions of the CLINICAL TRIAL MANAGEMENT SYSTEM. And other organizations validate fully,
uh, fully validate the entire system While, we have also seen a few organizations not
validate the CLINICAL TRIAL MANAGEMENT SYSTEM systems. So it is really an organizational
driven topic, whether, they choose to validate the CLINICAL TRIAL MANAGEMENT SYSTEM that
they are implementing. On our side, we recommend validation and we actually provide all the
tools validation so, particularly with our accelerator we have developed all the outsets
for if we wanted to implement that in a, at an organization on premise, then we have all
the validation tools and validation assets and validation suite to fully validate the
application in that in-house setup or even on a on-demand setup. So, again, from a vendor
perspective to be ready for sort of different organizations that have a different varying
definition of what their CLINICAL TRIAL MANAGEMENT SYSTEM needs to validated, so we take a more
conservative approach with the validation. But again, and it's usually a client driven
or company driven task to do that risk analysis and determine whether their applications need
to be validated. Here's a question on are there project management
features with Get Chart budget resources, scheduling et cetera integrated with CLINICAL
TRIAL MANAGEMENT SYSTEM or do you find people needing MS project or Oracle project collaboration
in addition? There are some tools in Seibel Clinical specifically
that talk to project management. There are abilities to import MS project plans to application
and sort of manage it that way. There's integration sort of built in for that. There are resource
scheduling and resource management modules within Seibel as well. You know. And I will
explain those a little bit where you can actually build out your organization, give each of
your employees skills and experience with in the tool and then when you have a project
up and coming project, up and coming study the system can actually recommend whose available
and who has the skill set to fill a certain resource requirement on a particular study.
But you can imagine that probably something that, you know, it is robust but you have
to prime it right, you have to put all that data in there first to be able to use it.
And two, you know, only larger organizations really typically utilize features like that.
So if you're looking for a CRA that has certain skills that, you know, is in the west coast,
for example for an up and coming study, the system can sort of find you candidates that
will fill that need. If you've set that information to the system, the Seibel has the ability
to do that but, we only found very, very sort of large organizations utilize features like
that, you know, within Seibel. Sort of the smaller you know clinical operations groups
tend to be pretty small, you know, for not talking about talking about contract research
organizations. So we haven't seen that feature be utilized very heavily plus organizations
tend to typically have project management tools in place, you know for doing those,
those type of things outside of the system. But there's certainly room for integration
like I mentioned with MS project that you can import and integrate a MS project directly
into Seibel. I'm sure there's some other CLINICAL TRIAL MANAGEMENT SYSTEM solutions that have
some similar functionality. Somebody asked a question: will we be seeing
a demo? Unfortunately, we don't have time for a demo
on the one hour webinar, but if you'd certainly like to see a demo, then you can certainly
reach out to us and we'd be happy to coordinate something to schedule a demo either Seibel
Clinical or our Ascend Accelerator product. Another question: is there mail-merge capability
within the CLINICAL TRIAL MANAGEMENT SYSTEM correspondence to study site contacts? And
the answer is yes. So Seibel Clinical does have a mail-merge function it actually, yeah
so, it has had a mail-merge function for quite some time within the application there's a
document administration capability where you can upload templates and then utilize your
correspondence module, that's they call it, so you can select individual investigators
or multiple investigators and then generate a mail-merge document with those recipients.
And what it does is generates the merged document, as a word file then you can certainly print
that out then mail it via snail mail or email those documents. It also has the ability to
sending email directly from the system, so you can integrate it with your outlook and
you can have your email templates that are imbedded in the system. And then, again, you
can select recipients and then select the body of the text from a template and then
you know it will send out those emails. So there is some capability like that within
CLINICAL TRIAL MANAGEMENT SYSTEM. It does take a little while to get that set up sort
of properly but certainly that capability is there. And even, so the correspondence
module has been around in Seibel for you know, multiple versions of Seibel and the latest
version 8.1, you know, it also comes with a reporting tool call the iPublisher and that
also can be utilized to do...I mean it's essentially a reporting, uh, a reporting tool that is
embedded within Seibel, but it certainly can be used in a mail-merge type of capacity as
well, where you generate, it's almost like generating a report but essentially you have
your mail-merge templates in a report format and it would uh, you know, pull in the relevant
details from your application to merge it with those fields and, again merge document
for you to then manipulate and send to your site contacts.
So I think we have hit at least most of the questions and we're running out of time here,
so I will have to wrap it up. But I did want to thank you all for sharing your time with
us and I hope you found it was time well spent. I'd like to mention we are taking March off
due to CLINICAL TRIAL MANAGEMENT SYSTEM conference in Philadelphia. Again that's March 24th and
25th in Philadelphia, the CBI-CLINICAL TRIAL MANAGEMENT SYSTEM conference and we are going
to be delivering a co-presenting with one of our clients Covidien on building an effective
CLINICAL TRIAL MANAGEMENT SYSTEM training program. And we encourage all of you to attend.
And if you would like some reduced rates on registration, feel free to email us and we'll
be happy give you some, vouchers for reduced registration. I do want to mention that we
have the additional webinars planned for April and May, so if you haven't registered yet,
please go ahead and register. In April we're going to be, you know, doing a condensed version
of that training workshop and in May, we are going to be talking about post go-live best
practices for Seibel Clinical, such as data senders and maximizing the value of templates.
So, definitely register for those. And again, this webinar is going to be available for
download from our website within 24 hours or so, for those views or colleagues that
may have missed it, you want to route them to all of the webinars that we are going to
be recorded and are available on our website at BioPharm.com. And again, for demos and
other things, those also could be requested on our website as well, So if you have any
requests for demos, feel free to request that from the webinar as well. And if you have
any additional questions or you want to discuss any of your organization's needs, and determine
the best options feel free to contact me directly. My email address is on the screen. And, Again,
I want to thank everybody for joining today and enjoy the rest of your day.