This has taken me back to the question of what eSource really is.  The CDISC Glossary says – Source record that is electronic.

‘eSource Data’ is described as

‘Source data captured initially into a permanent electronic record used for the reconstruction and evaluation of a clinical study. NOTE: “Permanent” in the context of these definitions implies that any changes made to the electronic data are recorded via an audit trail.

I believe the term eSource is misunderstood. eSource is a state of data, rather than the data itself.   We cannot say data is itself ‘eSource’.  It depends how it achieved its state, and how it is maintained.

I believe the confusion with eSource is partially due to the attempt to manifest physical (paper) principles to an electronic medium.  Conceptually.. it is similar to the idea of copies of electronic music versus copies of a Vinyl Record.

Allow me to explain further…

If I enter data into a database..  and.. the data I entered came directly from my head.. onto the keyboard and into the computer.  That might be considered ‘eSource’..   Now….   I copy that data to another database using a program.  I now have 2 copies of the same data.  So… do I have 2 eSources??  or is that 1 eSource, and 1 copy.  Lets imagine that I validate the software to prove that the copy is identical to the original database… does that make 2 eSources..

How about.. if I have a computer that has 2 hard disks…  and the hard disks are mirrored… they contain electronic copies of the same data… are they both eSource..?  or is eSource only the copy on the first hard disk…  Is the software that replicates the data validated… does that make both of them eSource?

So.. I don’t think 1, 2, 3 or 10 instances of the data are necessarily eSource or not eSource…

If I develop software to capture the data.. and.. I develop software to replicate that data… then all replicas of the data are – in my humble opinion – eSource.

Ah… but hold on.. which copy can I modify?  Is that not the real definition of eSource?  The version that is under the control of the originator (e.g. Site)… well… is that not just a matter of permissions that must be managed?  Or maybe… it is just a matter of technology… if I created a clever database system that ensured updates in one location were automatically applied to all other locations?   Would that not make all instances of that data ‘eSource’?

I think that the principle of eSource only applies if multiple un-replicated instances of data exist, and one of these ‘master’ instances remains in the control of the originator (typically site).

Ensuring the sites maintain control over a master copy of the data, and ensuring a person other than the sponsor – a trusted 3rd party – manages permissions that control access to read/write to that master copy would seem to be the key here.

Trusted 3rd Party

Lets think hypothetically.   Lets imagine I own a company that hosts clinical data.  I am considered to be a ‘Trusted 3rd Party’.   I hold data that belongs to the Site users. Lets say it is 10 fields of information on a Patient.  Some of that data – 8 fields – are also available to the sponsor.  The data… is the same data… it just has different permissions on who can modify and who can see the data.  Could I say that the 10 datapoints are ‘eSource’.. and yet I have only 1 copy of the data?

The Patent

I said in my response to the comment chain that I was not overly concerned with the patent, because I didn’t think it was a good idea.  The idea, reputedly copied from CDISC derived materials (sorry Dave), is that data is entered once.. and then sent using typical security and transaction handshake methods separately to an eSource document and an EDC system.   Nothing is new here of course.  It is all relatively low tech stuff…. but I don’t care about that.  What I do care about is that a perception exists that it is good, and necessary that physically separate copies of data are required to maintain the independent integrity of eSource versus non eSource.

I think the missing piece here is that the EDC – non eSource data – is perceived to be under the control of the Sponsor – whereas the eSource document is ‘read only’ and under the control of the site (or a trusted 3rd party).

I take from this..  that if the EDC system, and the eSource document are under the control of a trusted 3rd party… AND.. the trusted 3rd party managed the controlled access to change the data.. then we only need 1 copy.

Conclusion

So – am I concerned that a commercial organization can apparently take ideas that were developed as public, open standards and patented them?…  yes.. I think I am.   Am I concerned that this particular patent is going to negatively impact clinical development.  No.. I don’t.  I don’t think this is a good way to go anyway.  In my opinion, the patent will simply discourage those that may mistakenly have taken this approach.  However, I am interested in other comments and opinions on this topic.

Note:  Information contained above may contain new ideas, or existing ideas brought together in a new way.  Although I manifest them in this publically available blog, I do claim copyright on the content.

Unfortunately, in my experience the workflow is often broken.

Rave is an excellent tool at telling multiple user roles what they need to do in order to carry out their function in the entry, review and cleaning of the data. Any user that logs in can see at a glance what their duties are – be it Answer a Query, complete an eCRF or sign. Once their work is done, they get a nice – your finished indicator. Sounds great…

Until… you decide to do things outside of the system…

Lets say I have decided my Rave ‘Core Configuration’ – the thing that defines the available workflows for data- that data will go through the following steps;

1 – Entered
2 – Edit Checked
3 – Investigator Signed
4 – Source Data Verified
5 – DM Reviewed (some datapoints)
6 – Locked

Also, I decided that the above statuses can run in parallel, steps 2-5 apart form the last one – Lock can only occur once the other items are completed.

The Dilemma

Now… lets say we decide to carry out edit checking & listings in batch mode using SAS and pass the result onto a Medical Monitor. No problem… We can extract the data – or, read it directly into SAS, run the listings and checks and pass the outputs to the Medical Monitors.. Great.. no problem.. Ah.. but hold on… this only occurs once every 3 months…

Each week, a Data Manager comes along to review the pending data, and notices that pages are sitting at ‘Pending Lock’.. great.. time to lock the datapoints,  pages & visits… Perfect – datapoints… pages… visits locked… and then the results of the Medical Monitor review come back…

Mmmm the pages are already locked… why is that… ah… Rave didn’t know that this outside the system activity was happening or going to happen… Oh dear – the locked data has already been used in an interim analysis… problem…

Why not place a ‘Monitoring Review’ flag on each datapoint?  Well… not every datapoint is actually reviewed…

So.. what is the answer to this dilemma? Well.. we could simply wait to lock the datapoints at the very very end.. and just run a ‘lock’ routine to force all the datapoints to lock… yes… that will work… but.. what about all the beautiful workflow… what about the ability to immediately know what state all the data is in? Surely, that is not much better than running paper studies?   How on earth will that work when we do Interim Analysis or Adaptive studies?

The Workaround

It would be great if Medical Monitors were able to open up Rave, page through eCRF’s detecting issues, and raise queries as they go… But, of course, that doesn’t work.   Listings are used because they pull together, and derive related information allowing the reviewers to see data across patients allowing them to detect issues that cannot always be picked up with edit checks.  The JReview and Business Objects products are designed to do just such a thing.

However, we still have the same challenge as above.    If  Medical Monitor reviews – lets say 1000 rows of data – lets say they raise 4 queries.   As far as Rave is concerned, it only knows that 4 queries have been raised, not, that all 1000 rows have been reviewed.  Yes.. I know.. the Medical Monitor could access each page and datapoint and set a Monitoring Reviewed flag… but that’s never going to happen. It could take hours.

A couple of workarounds do exist.

1). To create a data review tool that allows the appropriate data to be reviewed, and for the results of the completion of the review to be passed back to Rave as web service calls.  This would include the confirmation of the completion of Medical Monitoring review (this would be setup as a review status on relevant datapoints, and also act as pre-conditions for lock).

2). Batch Status Updater.  This is an add-on to Rave that allows you to change the status of datapoints in batch by range of Visits, Sites etc.    With some effort, the batches can be configured to match the listings.  After the listings have been reviewed, and the queries raised, the batch status updater can run, and the clean data flagged as reviewed.    Not perfect – as in theory data may have changed between the review and the batch update – but it does mean the workflow is maintained.  If a user changes a value after this.. then the datapoint reverts to unreviewed, and gets put back in the queue for Monitoring review.

Other reasons for delayed lock

A 2nd reason for delayed data lock in Rave is the non integration of data.   Traditional data management methods often involve the late reconciliation of data, or, the reconciliation of data from different sources outside systems such as EDC.   The result of this is that it is not possible to achieve a true complete picture of the status of data without significant manual intervention.  Spreadsheets, checklists and custom SAS programs are all often used to track what is actually going on.  Unfortunately, such tools are often labor intensive, and struggling to provide trial management visibility.

Integrating data costs – but, through standardization, can often cost a lot less than the impact of non integrated data.

Conclusion

The implementation of a batch review facility into Rave would obviously help address the issue of external data review activities on locking.

The lack of Data integration is caused by a number of situations.  Many of the vendor solutions – IVR, some eDiary and less common external data sources can fail to adequately support the provision of standards based, non programmed integration support.  As a result, integration work is complex and expensive.   When selecting an data providing vendor – I would encourage sponsors to understand integration costs. If the cost of study integration does not reduce over time with standards, then that indicates a lack of maturity in the vendors solution and that might have a major impact in the solutions ability to support rapid (adaptive) studies.

Bjork-Shiley Heart Valve

My first employment.. a few years ago…  was working for a very small software company developing database software for what is now referred to as Post Marketing follow-up study.  It was for tracking the post surgery follow-up of what has now become somewhat famous (or infamous) the Bjork-Shiley Heart Valve.    For those that have not heard of this, it was a revolutionary replacement to traditional valve replacement therapies (typically bioprosthetic – pig or ball and cage valves).  Initial indications showed that they reduced the incidence of clotting and rejection in comparison to other devices.   However, due to design and manufacturing flaws – failures occurred.   Unlike pig valves that deteriotate over time – potentially killing a patient slowly – the Bjork-Shiley valves failed catastrophically often resulting in sudden death.  The valve was taken off the market  in 1986.

The software we wrote was designed for an Apple Macintosh – or Mac as they are more commonly referred to now.    It had no hard disk, a 3 1/2 inch floppy (cartridge drive) with a 1.44Mb Capacity.   What made this computer special in comparison to others was its graphical user interface.    Before, and for 10 years after, I was accustomed to developing simple text based database systems.

With the Apple Mac – we could develop a database application driven by icons and mouse clicks.   The computer came with Microsoft Basic that allowed us to write code to produce a graphical user interface.   The database features were non existent, so my colleague wrote a (B+Tree) relational database that I leveraged in the application and in graphical reports.

The system was successful within its limited deployment and use.  Personally, I learned how, as a single user system how doctors and registrars would complete paper source documents, and how a study nurse would chase them down when she couldn’t make out their hand-writing…   In the end it died out because it was proprietary, and it suffered database problems with the limited reliability of the storage mediums – portable disks. Dbase xx based systems took over the application.

I still use lessons I learned in UI design – graphical icon based menu systems for example- similar to an iPhone – in the work I do today.  People are naturally afraid of things they don’t know.  First impressions count in software – so presenting a simple page with pictures that can be clicked on to gain access to system features was a important aspect for this new ‘scary’ technology.

The challenges with paper source documents remain an almost identical challenge to that of 1986.  Transcription errors… missing information…

Things like Cloud computing, data interchange standards and edit checking technologies are all important, but it is the end-user and the positive experience we can create for them that often counts first and foremost.

Thanks Steve for setting me off on the right tracks!

A few years ago, I recall one sponsor company manager telling me how pleased they were with the 36 reports they had that reported data out of their EDC tool.  At the time, 36 seemed like a large number of reports to be running on a routine basis.  I wondered if a large number of reports was the solution to effectively managing clinical trials?

I think as a Manager, I would prefer that a system told me what I need to know, rather than tell me everything, and expect me to find what I need.

Pharmapros Data Flow Manager appears to take an alternative approach by presenting information in a form that is easier to glance at and take action on.   Take for example the following screenshot (thank you Laurine Pineo from Pharmapros for offering to share this);



This screenshot shows the visualization of the sites that are associated with a study, and the color coded status of each site.  Green indicates a site that is fully operational, and has no outstanding issues.   Yellow indicates the site is operational with issues.  If a site has significant problem such as compliance issues, it would appear in red.   With this format of information, the manager can at a glance see where issues exist, and can use this presentation to take actions.

The visualization doesn’t stop here of course. Users can drill down with country and local maps, and, for additional site information.    The source of the information is the CTMS and/or EDC system that holds the master site and status information.  This is of course just a very small element of DFM.  Across the product, it appears to work hard at presenting information in forms that are easy to consume and digest.

So.. a new eCTMS?

In a former life, during the mid to late 90’s I worked on a CTMS system – ClinWare CTMS, an IBM product.   This CTMS was designed to work with EDC, but, it working in the old school ways of CTMS – it required lots of manual data entry before it produced any value. In addition, the value was typically not returned to the individuals performing the data entry.  As a result,  currency of information was always a problem. Deriving information from other systems that already have such information is potentially more attractive.

Many of the eClinical solutions on the market today contain tools for both planning and executing studies – EDC systems in particular.  However – they often work in their own world without a perspective on other systems.

Data Flow Manager in some regards could be considered an eCTMS – electronic Clinical Trial Management System – solutions  because it derives most of its knowledge electronically from other eClinical systems.   This means not only that the effort of maintaining the meta information is largely removed, but also, that the data that is presented can be assured to be aligned with the metadata.  Those of us that have attempted to effectively map complex dynamic visits structures between an EDC and CTMS system will empathize here I hope.

So – I think Pharmapros have potentially a very good product on their hands.   CRO organizations may well be attracted to the idea of being able to present different eClinical technologies through a single information portal giving sponsors a common realtime window on their studies.   Pharma companies will be interested in the tool to help standardize the availability of management information.  All types of organizations will be interested in the potential for cost reduction, while at the same time having clarity of information.

I will finish this short series of blog postings with a disclosure that Soltex Consulting have entered into a non exclusive partnership with Pharmapros. We think the combination of this tool together with the Integration, Process and Change Management consulting services that Soltex Consulting provide will return significant value to Pharma, Device and CRO organizations struggling with either data integrations or maintaining visibility of information flows during clinical trials.

For further information, feel free to reach out to us at info @ soltexconsulting.com, or simply comment above.

Before I continue on this thread, I would like to expand on the topic of eClinical Cloud computing.

eClinical Cloud Computing

Recently, Jim Howit (Haughwout) eloquently expressed in his blog the attributes that define Cloud computing.  Applied to eClinical, I believe that this technology will help resolve the inherent high cost and low scalability of single study – ‘build & destroy’ solutions that have been prevalent in the past in Clinical Development.  I believe that systems or configuration that target too heavily towards a single study use, are often one of the causes of failure in achieve ROI or better performance in clinical research.

Cloud based eClinical has the potential to say – lets install and configure this once – and for the value to be repeated across all programs and studies. (In fact, across all sponsors).  For CRO’s this is especially relevant.

Cloud eCTMS?

Data Flow Manager from Pharmapros meets many of the Cloud computing criteria.  It is fully web based, it is single instance, multi-tenanted.  In the eClinical field, it supports the re-use of configuration across studies and comes pre-supplied with connectors to many of the leading eClinical tools.

The connectors are key components here. For instance, when Pharmapros releases a connector for a new Web service supporting EDC vendor – that connector will be available to any CRO or Sponsor. Sure, some metadata configuration might need to be done, but, the hard task of programming and validation are covered once.

One concern I raised when I initially spoke with Pharmapros was that not all eClinical products offer up data or metadata in a format that can be easily consumed by other systems.   They have a solution to this problem. Enterprise Adapter is a Pharmapros module that is designed to be plugged into a host eClinical product (EDC, IVR, CTMS, LAB etc) that extracts the relevant information and converts it into standard DFM Web services speak.   This means that both mature systems like Oracle Clinical and IMPACT CTMS – underlying Client/Server SQL based solutions -  as well as more recent web service ready products such as OpenClinica, Rave or BioClinica EDC can be feeders to a standard DFM system.

Tied or Independent Portal Solutions?

This was a bit of a light bulb moment for me.   I was thinking about what Executives and Managers need. Do they need many systems all standardized… or… do they need the presentation of the information they receive to be standardized?   Sure – data standards such as CDISC are all fine and good… but… they are a means to an end…. They are the plumbing.

If a Senior Manager looks at Enrollment figures – they should see them in the same form from study to study, across programs.  It shouldn’t matter if the Enrollment is coming from IVR, EDC, CTMS or any other system.  They just want to see a report on how Enrollment is progressing.   They want the report to be consistent, and for the information to be entirely up to date…

Study Managers also have demands related to this topic – they don’t want to see the cost or complexity ‘per study’ for programming systems integration to meet this information demand.

So – is Pharmapros competing with the CTMS Vendors?

I don’t think so, at least in the traditional areas of CTMS.  The product consumes information from CTMS systems as it does with other eClinical software products. In that sense it complements CTMS systems. However,  it potentially negates some of the need for CTMS functionality .  As has been the case for the last few years due to EDC scope increases, we will probably continue to see the net value of CTMS systems continue to decrease as the reporting demands are replaced by products similar to DataFlow Manager. Organizations may feel that in an entirely ‘e’-Clinical world, traditional standalone CTMS is just not required.

A system such as Data Flow Manager may be seen as the consistent information hub in the wheel of clinical research with the various commodity components of eDiary, EDC and labs all feeding information into the hub as required.  DFM converts diverse terminology (DCF’s / Discrepancies / Queries…) into standard terminology that sponsor companies are comfortable with.

How is all the usual information presented?

That will be the topic of my next blog post tomorrow.

Traditional method of consolidating information

The currency of data available to Managers is only as good as the oldest data feed.  That may not be critical for all studies, but,  a lack of clarity will undoubtedly impact the value of the overall information.

One of the common flaws in eClinical systems and their associated vendors is that they often see the life-cycle of data from their own perspective.   If you work with an eDiary vendor for instance, they will offer you a complete solution with Devices, Portal, data extracts, archives etc.   If you speak with an EDC company – they will offer something similar… but different.  The same kinds of data can be called different things.  In EDC it may achieve a status of ‘clean’, whilst in another system data may be described as ‘locked’… Reporting on this is problematic.

Another problem this causes is clearly identifying missing data, especially where no one system has a complete picture of what is, and is not expected. It is almost as if organizations need to wait to the very end to piece together the parts… to see what is not there!

One solution to facilitate data access is to fully integrate the systems – into a single database – DataTrak for instance have taken this approach with their ‘One’ unified platform.  Nice technology, that has some merits, but I would question whether this is viable in all deployment scenarios.

Data Integration though between systems can be difficult, expensive and in some cases, just not possible. Despite the clear challenges, Research and Development organizations need to be able to pull together information and present it in a non-technical standard format that is easy to access and use to make decisions.   This is a need that exists whether the eClinical technologies are integrated or not.

Another, more feasible solution to the information delivery problem is the implementation of a portal.  Many firms sell portals that consolidate information from various sources – but these portals are often only able to draw from the technologies that were created by the same entity that created the portal.   In many cases, they become yet another technology that requires training and a login, instead of a tool that provides information clarity. So, how do we make something that is relatively complicated, convoluted and expensive – easy to use and implement?

One company that may have it right is PharmaPros.  They have developed a solution called Data Flow Manager (DFM).  PharmaPros is not the only organization offering up portal style tools in this area, but, they are unique in that from a software product perspective, they are focused entirely on this one area. Pharmapros’ Data Flow Manager is targeted towards pulling together information from many disparate eClinical systems and reporting it near-real-time to the end user.

Data Flow Manager – removing the lag?

This takes the Excel consolidation reports out of the equation, and gives Managers rapid access to information on all of the data, and the flows of information through the studies.  The ‘net currency’ of information can be measured in hours rather than weeks.

Being independent, they are vendor agnostic, pulling data from many integrated and non integrated solutions.  Additionally, the DFM product is relatively simple to implement and configure, and produces quality, easy to read data outputs.

I like the principle of independence when it comes to this particular technology.   I have known a number of portal solutions in the past with impressive interfaces and promises of clean integration, but that only really worked well in a pre-canned environment with information pulled from a single vendor system.  In a typical clinical trial, you might see Lab, IVR, EDC and CTMS data from different organizations – and this mix might change from study to study.

It is possible that Pharmapros’ have created a solution to the information chaos that results from working with the disconnected information from multiple systems.

So – where is the magic?  What exactly does DFM do differently to achieve tighter, more effective management of data from multiple sources?

I will expand on this in a future posting.

The future of eClinical software solutions will change over the next 5-10 years.

The architecture of many of the leading EDC solutions on the market place is derived from the days when for example, you did 1 study, and you installed 1 instance of your software to support it.   Today, this still works, but is increasingly less common.   The single instance solution is already understood to be too difficult to scale.  Integrates are one-off’s.   It is just too expensive to manage volume with this model.

Emerging Models

The new model of systems that have emerged in the last 4-5 years have the capacity to host many clinical studies in a single instance.   By doing this, certain information, standards and interfaces can be re-applied for no additional cost.  They are all ‘there’.

I believe that the next step in the cycle is fully multi-tenanted / single instance solutions.   We have seen this in many other industry areas, but we have not yet seen this in eClinical.

I have heard doubts voiced – primarily by the large single study instance software vendors – that such a model is too risky…  that sponsors data will ‘accidentally’ become available to other sponsors.     I don’t buy that argument provided the solutions are architected correctly in the first place.  If you are still being handed back-end access to your database as a sponsor.. then that says to me that your software has a problem.

Single Instance, Multi-tenanted solutions will be similar to any application that you might be familiar with on the internet.  Amazon, eBay,  etc – they all give you access to their system… but, they certainly dont allow you to access their database directly…   Instead you are given a brower application user interface to buy and sell things. If you want to do more – then API’s – often web service based – exist to allow you to communicate system to system.

I have no doubts that single instance, multi-tenanted solutions that run over the web – ‘cloud like’  will prevail.  The question is when.

When working with CRO’s and Sponsors – it is often that they describe setting up a study in EDC as ‘Building the Database’.   Of course, it has been 15+ years since a database has actualy been ‘built’ to host any EDC study… but it does indicate the kind of mind state that organizations are coming from.   How long will it take them to take a leap into a form of cloud based computing.

Clinical Data  & Cloud Computing

The Term Cloud computing has caused enormous debate over the last 5 years.   However, I think it is a term that helps define a new technology paradigm.

Cloud computing is defined as  the use and access of multiple server-based computational resources via a digital network where applications are provided and managed by the cloud server and data is also stored remotely in the cloud configuration.

One major concern raised with using Cloud computing in the area of clinical research and development is the idea of data protection, confidentiality and regulatory compliance. Is the data stored in the cloud secure, and suitably managed in a way that would pass a regulatory audit?

Data Projection

The following is an extract from the UK Government website related to Data Privacy :-

You may transfer personal data to countries within the European Economic Area on the same basis as you may transfer it within the UK.  However, you may only send it to a country or territory outside the European Economic Area if that country or territory ensures an adequate level of protection for the rights and freedoms of individuals in relation to processing personal data.

The US do not have the same degree of data privacy laws, so, to avoid EU/US litigation,  in 2000, the  US/EU Safe Harbor agreement was put in place.  It provides some degree of support for data privacy between EU and US organizations provided the US organization complies with appropriate data privacy guidelines.  So.. provided the company, and hosting organization comply with the Safe Harbor agreement, then this part is covered.

Regulatory Compliance

This is harder to deal with.   The question is, what Regulatory compliance is actually required?   Well – sponsor companies need to assure that adequate controls and safe guards are in place.  Typically, they carry out audits of the hosting facilities to ensure that this is indeed the place…  Can they audit the location(s) used for cloud hosting?  Often not.

Private Cloud?

The idea of Cloud computing is that software runs ‘somewhere’.   You don’t necessarily know, or control where, but it runs ‘out there’.   Virtualization technologies exist today that allow this to happen.  Today, I can take my software and run it on 1 server, or 2 servers of 10 servers… How many servers, and how much capacity depends on how much I use them, and how much I pay.   (The SPEC+ Application runs on Google App Engine for instance – this is in the cloud).  These servers can be in the same rack.. or different racks,.. or different locations.   If I don’t know where they are… then they are described as being in ‘the cloud’.

So – what about Private Clouds.  This is a relatively new term for cloud based computing that has certain restrictions applied.   Private clouds may be the interim answer to concerns raised about the location of data in true cloud computing and data privacy. Private Clouds are the same in architecture to regular cloud computing, except the servers involved are all privately controlled and managed servers.    Virtualization will still apply. Software may scale across servers and locations – but these are limited to a private set.

The advantage here when it comes to audit and data privacy is that the location of the data can be asserted, and the audit worthiness of the facilities controlled.   This would therefore provide sufficient assurance to sponsors and regulators that compliance can be maintained.

Private Cloud Inter-connectivity

The one remaining element of cloud computing that can make eClinical Cloud computing make sense from a positive business perspective is the open connectivity that it can help support.

Single Instance, multi-tenanted cloud applications function by providing an open interface that ensures all tenants can push data in, and pull data out with compromising secure access to their, or other users data.   The vendors of such systems develop these open interfaces once.   These interfaces are available to all users without further re-development.

eClinical computing has significant demands for the same type of platform. They need to scale, they need to interface quickly.   They need to be easy to setup (zero additional work) and they need to speak to other distributed systems without significant software development.

Conclusion

So – my prediction for the future -

1-5 years – I think we will see Private Cloud based eClinical solutions with open connectivity allowing similar cloud based systems to communicate on a low cost / low maintenance enterprise basis.

5-10 years – I think Public cloud based eClinical solutions will become established.  Concerns regarding data privacy and regulatory compliance will be dealt with for the sake of business.

Comments welcome on this post.

This year we focused on unveiling our methods; People, Process and Technology. At Soltex, we believe
that all three elements are necessary to create an effective and efficient solution in Clinical Research &
Development. We work one on one with our clients to analyze and identify their critical problems and
recommend value-driven strategies. Once we establish an approach we implement the solutions.

This year we had a drawing to win an iPad2 and our lucky winner was Eric Morrie! Congratulations Eric,
we hope you are enjoying your new iPad! Click to watch Soltex Consulting’s Partner, Christie
Mahoney, interview Eric at the DIA about his experience.

Thank you again to everyone who visited our booth. We look forward to next year’s DIA in Philadelphia,
PA! To learn more about Soltex Consulting and our methods click www.soltexconsulting.com.

Many thanks to Eric for participating, and for his valuable insights.

One hot topic area for us was the early review of a concept tool for the rapid prototyping and specification of eCRFs. This went down particularly well. Soltex Consulting are looking at progressing this further, although the method of implementation will need to be adjusted.

It was pointed out to me that our friends at Formedix are tackling a similar problem. They provide a generic means for the definition of eCRF’s that in turn can be pushed to a number of EDC tools that are CDISC ODM compliant. I think they have a good solution for this. This is not the challenge that Soltex are looking at tackling. Soltex are looking at the problem of the development of specifications, in particularly related to the largest chunk of the development effort – the edit checks. Let me explain the scenario;

CRO Company ‘Studies-r-Us’ are contract with a Pharma company ABCPharma to carry out a clinical trial. A protocol remains in draft, and due to commercial pressures, it is key that the study gets underway as soon as possible. The protocol is rushed through, with no input from the CRO. The CRO visits ABCPharma to kick-off the implementation.. the following week, the CRO sits down with the client to complete an eCRF Specification (excel).

Two weeks later, the draft eCRF’s – built in the EDC tool – are presented to the ABCPharma in PDF format for review. The PDF file is shipped around the stakeholders who in turn take a couple of weeks to provide final feedback… Many changes – some competing are presented, discussed and agreed.

Once the eCRFs are finalized… after 5 weeks… Studies-r-Us staff meet with ABCPharma to define data cleaning rules… these are defined in a separate Excel spreadsheet. ABCPharma staff struggle with the definition of complex checks, and dynamics. They find it hard to visualize how the checks will appear in the final eCRF.

Unfortunately, due to time constraints it is not possible to fully define the data cleaning rules. As a result, the edit checks in the EDC system are limited, and instead, back-end SAS checks are defined and applied post FPI. As the study is reliant on Batch SAS back-end edit checking, it is not possibly to apply the review/SDV/Freeze/Lock workflow and therefore the study runs in a similar manner to a paper study with no data availability until well after DB Lock.

So… what was the problem that ABCPharma and Studes-r-Us faced above?

Well – a number of problems occurred here. Timelines were preset, and compressed – we are all familiar with that situation I am sure!

One of the main issues though, was that the study design process was driven by the completion of spreadsheet based specifications that took a while to complete, and, were not immediately reflective of the needs of the sponsor. It was not until the sponsor actually visualized the eCRF AND saw the rules associated with the data in the eCRF could they fully realize what would be delivered.  This is not always clear though.  The specification in spreadsheet format is often used.   Business Analysis that I have carried out in the past was originally targeted towards improving the work of the edit check developers.  On closer examination, the problem was isolated to the quality and clarity of the specifications, and, the difficulty that the sponsors had in adequately reviewing and completing the specs.

DIA 2011 & SPEC+

The concept behind SPEC+ is that the process of the development of eCRF’s should be interactive. In addition, the process of defining the rules that are associated with data on the eCRF should be defined ‘on the eCRF’. I believe this method will offer the maximum degree of appreciation and buy in from the sponsor stakeholders.

I believe the concepts behind SPEC+have been proven with the feedback from the DIA.  It is possible to interactively prepare an eCRF live with the user requirement owners, and, to define the edit check requirements in place within the eCRF.   With this tool, it should be possible to complete a standard eCRF build within a few days, and to annotate the eCRF with edit check rules within a similar period.   I would estimate 2 weeks should be sufficient to full prepare eCRF’s and spec rules for a large (50+) unique page eCRF.

A few elements are missing. Namely;

1. Determine if code base is suitable as SaaS platform
2. Determine if syntax should be switched from Wiki to 4GL style
3. Native library, importing / utilizing standards
4. Viewers for common EDC platforms (subject to vendor approval)
5. Web Service deployment to EDC Platforms (alpha version to Medidata Rave)
6. Test bed – environment to confirm completion of build/testing of requirements

So, keep an eye out for further information on the development of a tool leveraging the concepts.

With the implementation of clinical trials with eClinical technologies, I have often seen this scenario.

The Problem

A Therapeutic Area Director will have an idea of the requirement for the study.  This will be converted into a Protocol. The protocol will then be interpreted down into a serious of CRF and Edit Check specifications. The system will then be configured or developed according to the specifications….  then…

The Data manager see’s the implementation… and says no.. change this.. or change that…

The Therapeutic Area Director see’s the eCRF’s… and says no…  change this… or change that…

The Statisticians sees the results of the implementation – the data – and says no… change this.. or change that…

Of course.. this is all compressed into a short space of time. An eCRF study is typically designed and developed in less than 12 weeks.    In some circumstances.. the system isn’t really ready.. It is deemed to be ‘good enough’… Any work is pushed beyond First Patient In.. The costs of the study implementation spiral, and the general feelings towards the success implementation are low…

Analysis

So – was the actual build of the study the problem in the above scenario?  Possibly not.  The build simply reflected the perception of requirements.  Maybe the fault lies in the methods used to identify and capture requirements.  Maybe the ‘logical’ distance between the person that knows the requirements, and the person that actually implements the requirements is too great?  Maybe the way in which the requirements are manifested are difficult to grasp?

Please allow me to describe an analogy;

I own an old wooden boat.  Strangely built in New Zealand… shipped around the world… and until recently in my garage. I occasional do work on it, modifying and tidying up bits and pieces…   When I want to change something in the boat.. the first thing I do, is to design the change using a rough drawing…   Yes, I  could write out the change in words… but.. that wouldn’t really help me visualize what I want.   Once I have the drawing scribbled down.. then I annotate the drawing with the various information that defines the implementation of the drawing.

I don’t think I am unusual in this approach.   People find it more engaging to work in pictures, and then to annotate pictures to help grasp likely results.  In effect – they are preparing a ‘specification’ in a format that they are comfortable with.

So – how about applying this principle to the challenge of quickly and effectively specifying clinical trials?

Very often, spreadsheets are used to define both screens, and edit checks.   I myself have been involved in the development of a tools (such as the DVS) for capturing edit check requirements.  I was quite pleased with what could be achieved with Excel.  However that was a diversion. When I looked at the effectiveness of the tool, I discovered that the requirement owners struggled to visualize the rules outside of the context of the forms and data.    What made matters worse was that the blame was often placed on the requirement owners for not providing accurate feedback, or, for not provided feedback in a timely manner.    In reality, the process and the tools (template) were broken.

A Solution?

I believe a case exists for the use of a tool that would allow you to interactively prepare the definition of an eCRF – real-time, in front of the requirement owners – complete with the definition of the way the eCRF looks, AND to be able to define the rules that should be associated with data that is captured .  Effectively to interactively produce a specification.

If the tool was as fast as it was for the requirement owner to actually write this information down, and, was able to show the results for immediate feedback and adjustment – would that not be a better solution?

To test out this theory,  Soltex Consulting will be demonstrating a tool we are calling Spec+ that we believe may address some of the challenges that organizations face in quickly and accurately specifying clinical studies.

Panacea?

A solution to all the challenges of clinical development – I think not!   However, it might be useful as part of an arsenal of tools that improve the quality and performance of study implementation.   Do we believe that using this tool alone will guarantee a 6 week study build?  Absolutely not.   Will it help?   We will see.

Next Steps

We are going to use the DIA as a proving ground for some of the principles.   The tool on its own is nice, but we also want to explore how the use of such a tool might fit into the overall lifecycle from Protocol through to deployed study, and the delivery of datasets. For instance, designing great forms are no use, if the resulting datasets fail to meet the SAP or Program demands.

If the tool is generally well received in concept, then we will be looking to proceed with further development and potentially a beta cycle around the Aug/Sept 2011 timeframe.