CDISC Rules!

Ok, so a play on words. CDISC may rule in the field of Clinical Data standards, but, it does not rule in the standardisation of rules associated with data.

Let me expand here for those not familiar with the issue.

CDISC ODM provides a syntax for the definition of metadata (and data) used in the interchange of information between (and sometimes within) systems. CDISC ODM does not scope the definition of edit check rules that are applied to the data when it is captured. I feel that is a significant omission as the rules element of the data a) take a considerable time to develop and b). provide a context to the data.

Question - So, why do we not already have rules built into the standards?

Answer - rules are often technology or vendor specific. There are almost as many methods of implementing rules, as there are EDC products.

Question - Why not define a standard mechanism for creating rules that vendors could either comply with, or, support as part of interfacing?

Answer - Well, it all depends on what you want the rules to do. In their simplest form, rules are boolean expressions that result in the production of a Query or Discrepancy. However, many systems go well beyond simply raising queries. The boolean element of the rule may be consistent, but the activity performed in the situation that the boolean returns true, is often very vendor specific.

Lowest Common Denominator

So - lets assume that we are looking at implementing a lowest common denominator of rules and actions that the majority of systems support, and require

What can we do to standardize a syntax. Three options I think;

1) Choose a syntax from one of the leading vendors,

2). Develop a new syntax building on existing ODM conventions

3). Bring in another standard syntax, potentially already in the Health or LifeScience field

Lets look at them in order.   

No. 1 - Choosing a Leading Vendor Syntax is probably great for the chosen leading vendor, but, bad for most other vendors. A benefit though would be that it would already be proven as a means to represent rules and actions in a clinical study. Some syntaxes are based around standard tools such as Visual Basic for Applications, JavaScript or even SQL. This approach may create almost insurmountable boundaries for other vendor systems that do not, or cannot implement the technology - for example, it is not easy to interpret VBA on a non Microsoft platform. So - option 1 has some potential, but, depending on the chosen vendor, may result in closing the door to the standard for others.

No. 2 - Creating a new Syntax would result in something most vendors would be happy with, but, would require considerable effort from the contributors in order to develop a complete specification for the standard, as well as a reference implementation. The advantage of such approach would of course be that it would be seen as a common standard open to all, and not specifically biased to any one vendor company. In practice, the technology approach chosen would favor some more than others.

No. 3 - Leverage an existing Syntax may well bring the benefits of No. 2 without all the costs of designing something from scratch.

Ok, so lets say we go ahead with option 3 - what are the candidate standards for rules in the Health and/or LifeSciences are?

As far as I can tell, not many. In fact, I was only able to find one candidate that had any level of success - a syntax called ARDEN.

ARDEN has existed since 1989 as a syntax for describing Medical Logic. Similar to typical Rules in EDC, they are defined in Modules - Medical Logic Modules - and called based on the triggering of an event.

[For an accurate definition of ARDEN and its roots, check Google Books - search for ARDEN Syntax and examine Clinical knowledge management: opportunities and challenges By Rajeev K. Bali, Pages 209 --> 211]

As a syntax, it is mostly general purpose. Here is a snip from an Arden Syntax module,

logic:

if

last_creat is null and last_BUN is null

then

alert_text := "No recent serum creatinine available. Consider patient's kidney function before ordering contrast studies.";

conclude true;

elseif

last_creat > 1.5 or last_BUN > 30

then

alert_text := "Consider impaired kidney function when ordering contrast studies for this patient.";

conclude true;

else

conclude false;

endif;

;;

In the example, you can see that the syntax uses standard if/then/elseif/endif constructs. Assignments use the := combination etc.

HL7 have a section dedicated to ARDEN here. The activity appears to be limited with no Postings or Documentation since 2004. On walking through some of the presentations, some of the consumer companies such as Eclipsys were proposing extensions to the syntax - for example to add object definition support. It would appear that the take-up of the standard has been limited to those organizations that had a problem to solve in the EHR area, and wanted to re-use a syntax, instead of inventing their own.

The fact that HL7 has lended support for ARDEN may be sufficient in itself. However, we would need to dig considerably deeper to understand how ARDEN syntax would fit with a syntax such as ODM. The first challenge is the conversion to an XML form. There are plenty of articles on ARDEN XML for further reading.

RuleML is another standard that may address the need to create Rules, as well as meeting the perceived need of being XML based.

More about ARDEN and RuleML in a later posting I think. This one is quite long enough for today.

Source to eSource with EDC

One of the areas that I have felt for some time as being a compromise to the effectiveness of EDC, is the subject of Source data, or rather, the fact that source data is often not entered directly into an EDC system.

I appreciate that we have situations where this is impractical for logistical reasons - location of computers, circumstances of source data capture etc.

However, often, it is mandated by the sponsor that source data is not logged in the EDC system, but is instead recorded elsewhere first.   Some advocates will indicate the need to comply with the regulations that state data must remain ‘at the site’.   Personally, I don’t concur with this assessment. The data is ‘at the site’. The cable connecting the screen to the computer might be very very long (the internet) but the data is constantly available at site. I probably shouldn’t be flippant on this point, but, the conservatism in conflict with progress strikes a nerve.

Transposing information from paper to an EDC screen introduces the potential for error.   In the old world days of paper CDM, we had Double Data Entry as a method to confirm transcription errors did not occur - 2 staff enter the same data from the paper CRF’, and the differences flagged/corrected.   With onsite EDC we don’t have Double Data Entry, but, we do have Source Data Verification. Instead of 2 staff sitting next to each other double keying data, we have a monitor fly in to perform the 2^nd check. Yes, I know, they carry out other duties, but still. This seems like an enormous effort to check for transcription issues. It also has a massive effect on slowing down time to database lock.

So – where are the solutions:-

1). Data at Site

We could put on our ‘common sense hats’ and make a statement that allows the entry of source data into the online EDC system. I know of a number of EDC companies that have simply placed this in their procedures. No audit findings / concerns have been raised as a result that I am aware of. Come on Regulators – why the delay in making a statement on this subject? The confusion caused is creating a measurable delay in bringing drugs to market!

2). Physical availability

This one is harder to tackle. When you have data to log, do you always have access to a system/device to log the data? Possibly not. Do you simply try to remember it, like an Italian waiter remembering a dinner order… I don’t think so. We either need to provide portable data entry devices, or, we accept paper transcription for these elements.

3). Differentiating Source from eSource

This does open up one area of concern. If we have some data as source, and some as eSource, how do we know which is which? When a Monitor goes looking for the source data, if they don’t find it, does that make it eSource – no.   There needs to be some very simple flagging, and visual indication system built into such a mixed source/esource system that supports this. I have seen this in one system, but, it is very rare. Come on EDC vendors – you’re turn here!

4). Other systems

Health Record systems amongst others will often be the first point of entry for data that may apply to an eCRF.   The current approach for organizations such as CDISC and HL7 is to create interfaces between systems. This will be a slow burner, I predict. There are so many hurdles in the way. It requires active cooperation from both sides – EDC providers may be fully onboard, but, I am not so sure about most EHR providers.  

We may see a company emerge (maybe this is what some former PhaseForward employees are up to – who knows!) develop an online Clinical Development Electronic Health Record System that is immediately EDC ready. Of course, with such a small deployment potential, I am not sure that we will see this appear at all sites in a global study, but for domestic application – say within a single country, inside research hospitals, it could work. I digress - back to the integration issue – yes, when we have standards, the feeds will start to happen, but not for many years.

5). Patient Recorded Information

ePro, Patient Diaries etc.   These are increasingly realistic, for the right sort of study for the accurate capture of patient data. If used appropriately, they can cut down the volume of data that needs to be transposed into EDC, and therefore source data verified.

On a side note, I am sure we will see a downloadable iPhone app that will make the current hardware/software dependent or basic PDA browser based systems seem old and tired.

The advantage of diary based systems is that instead of an investigator quizzing a patient, writing down the responses, transposing the responses etc. The information is captured ‘at source’ often considerably closer to the time of event.

Expanding from my previous post, I expect to see systems like PatientsLikeMe expand onto portable devices and act as an entry point for both patient identification and data entry. Internet enabled device pervasiveness will simply make this happen.

Conclusion

A lack of eSource has direct impact on the time it takes to lock data. With adaptive clinical trials executed by forward thinking sponsor companies, the point at which an adaption can occur corresponds directly with how long it takes for the sample size end-point significant datapoints to achieve a locked status. To simplify - the less eSource you have, the longer your studies will take. Forget a few days - we are talking wasted months.

eClinical in 2009?

So what will the eClinical landscape be like in 2009?   Here is a projection on what I believe will transpire in the eClinical business area over the course of the next year.  As ever, these are purely my opinions, and do not reflect the opinion of the company I work for...

We have seen significant changes over the preceding 2 years.  The number of vendors have shrunk with Medidata and PhaseForward apparently swallowing up the vast majority of new business.   

Oracle have been suggesting the availability of a new, improved product.  If they want to stand a chance against the big 2, then they are going to have to get the EDC portion right this time. Previous attempts were so far from the mark with regards basic EDC functionality and ease of use that they bombed in the market.

Medidata's announcement of Developer Central is potentially more significant.  ClinPage describes this as an API. However, I think that is a simplification that underplays the significance of the release. Back in September, I wrote a blog on Web Services, and how they might impact eClinical.

A number of EDC/CDM vendors have claimed to offer API's - FW-IMPACT and Oracle for example, but many were simply an exposure of a set of Stored Procedures. Techie's developing eClinical systems have talked about a full web service solution for many years. Medidata appear to have take their experiences with CDISC and actually delivered a fully operational solution - a full CDISC compliant Web Service for eClinical data Importing and Exporting.  

Google were the first company to really generate buzz around the principle of an API over the Internet with the release of the Google Toolkit.  With this, any developer with an Internet connection could send a program request - using web service calls - to Google, and receive search responses that they could use for their own purposes.    If the Web Service eClinical API that Medidata has announced is all its potentially cracked up to be, then we should see a long queue of  eClinical providers - eDiary, CTMS etc all lining up to be in a position to offer Medidata Rave real-time connectivity out of the box.

On a technical note, it will be interesting to see if the use of the CDASH standards will be utilized as a means to standardize the metadata used to capture the data.  If this does occur, we could see a simple handshake occurring at the start-point between the two inter-connected systems to confirm 100% compliance with CDASH. If this is the case, then no manual metadata synchronization need occur. In reality, I suspect ALL CDASH based implementations will be customized, but, its a good start.

Back to 2009 forecasting...

The financial crisis will clearly impact the industry.  The smaller companies - BioTech's specifically - will struggle to find cash.  If the development programs they are running rely on a constant cash flow, then they could go under.  This might provide rich pickings for the big companies looking to pick up a bargain, but, potentially at the cost of new innovations.  For the lower end of the eClinical marketplace, things will be tough.    eClinical vendors that can demonstrate lowering costs - especially over paper - will see increasing business.

eDiary vendors will continue to see business grow provided they can show interoperability, and, can manage to keep infrastructure costs down.   We may see an increase in the prevalence of eDiary solutions based around Off the Shelf or pre-existing hardware - the iPhone for example appears to have the ease of use, connectivity  and synchronization capabilities to make it more widely usable then any other OTS product today.

CTMS vendors will increasingly struggle.  The value of such solutions is increasingly marginalized with the enhancements offered by leading EDC system providers.  Similar to the eDiary space, if they can 'play nicely' with the other systems, they stand a chance.  Otherwise, they will be considered unnecessary in the overall eClinical Life Cycle.

Overall, I think we will see the more marginal areas of the eClinical vendor solution business impacted the most.  When finances are tight, the argument for these types of systems will be difficult.  Life Science companies will focus on cost saving and direct efficiency gain solutions.  This will be no time for long term technology prospecting.

 

For those following these blogs, I wish you well for the holiday period, and Best Wishes for 2009.

CTMS in EDC?

One of the functional areas that I have been surprised at the lack of good support for is CTMS features built out of EDC products.

CTMS systems often perform a variety of tasks - Portfolio Management, Site Management, Trial Planning, Monitor Reporting, Study Progress Tracking, the list goes on for a while...

One of the difficulties with using separate EDC and CTMS systems was often the need to either synchronize or interchange the metadata relevant to both systems.  Both systems need to be aware of the visit structure, and, potential workflow associated with more complicated visit structures.  For example, it might be the case that a study has multiple arms, and, one or more trigger points that determine the branching.   In order to predict the CRF's to be completed from a trial planning perspective the CTMS either needs to recreate the structure - including an appreciation of the trigger points, or, it needs to import the structure from the CTMS.  This is all a bit messy.

So, why do EDC vendors not do a better job of leveraging the data and metadata in an EDC database in order to drive at least a % of the needs of a CTMS?

I am open to better ideas here, but to get this started :-

EDC systems try to generalize the definition of studies. Often things like Visit Dates, Visit Numbers, Branching points and subject statuses etc. are all purely data based - often simply fields on a CRF.  They have no special meaning that differentiates them from other CRF fields.  Vendors could tackle this by offering a form of user definable flags.  On the metadata, a spare attribute would be provided that in turn points to an internal metadata codelist. The codelist could be populated by trigger values such as 'Visit Date' or 'Visit Number' etc.  When interfacing, the CTMS system just need to be aware of the special nature of flags, and use them to pick up the one or more fields that are associated with the flags. So, even though 10 different fields are used to hold Visit Dates, provided the 'Visit Date' flag is attached, the CTMS knows the find them. Being data based, no special programming required from study to study.

A second issue is the lack of CTMS information defined on an eCRF. EDC systems are generally only geared to capture data through the eCRF medium. When a sponsor approaches either a CRO or Vendor, often, the contents of a CRF page is gospel. The thought of bolting on the capturing of additional fields is considered inappropriate - eek!  it could be mistaken for clinical data!  - for example - and I have seen it done - a standard could be developed that ensures that for every subject visit, an end of visit form is filled out.  The end of visit form would not capture clinical data. It would be used to capture (or derive) study progress information. Visit Date, End of Visit Subject Status and other such information could be captured a validated in one place. With this kind of information, it is somewhat less difficult to either report on status and progress using native EDC reporting tools, or, feed the standard information across to a CTMS.

The third reason I believe for EDC systems not effectively supporting CTMS needs is the whole lack of planning features - yes, when building a deploying a study it is possible to enter no. of expected subjects at a site level - all EDC systems include this, and, in my experience all EDC system rarely use it - but that doesn't give you the timeline planning - based on a specific recruitment interval, when will I reach my target subject recruitment.... when will the recruited subjects complete LPLV... etc.

So - could EDC systems better leverage the information they have to offer basic CTMS functionality - absolutely.  Should they do more - Yes.

The recent Clinpage article vendors offering multiple integrated solutions suggest that the existence of a fully integrated solution will prove to be a key decision influencer over and above the actual feature functionality of individual systems. There is something to be said for that, but (and this is a big but), the systems must be sufficiently well integrated, robust and flexible to actually work in real life.  I would venture that many of the purportedly fully integrated product suites are in fact separate products loosely coupled with single-sign-on and a similar UI.   I have known (and I will not mention any names) of products that were sold under the same branding, used the same UI, could be accessed through a portal using Single-Sign-on, but that did not share a single application table once utilized - data, and metadata went into entirely separate tables - seamless, yes - a chasm!

With a strong CTMS feature inside an EDC product - does a future exist for standalone CTMS tools - I personally think not.  Although more highly functional, their data entry requirements versus the EDC tools that leverage existing metadata and admin data offers a less convincing value proposition.   Then again, how many good EDC vendors know how to create a good CTMS?