Processes and systems

A CTMS (Clinical Trial Management System) is at the core of clinical IT landscape. It contains a wide array of master data about clinical studies and supports the organization performing the trial with tregard to managing all activities within the study.

Since the CTMS is involved in virtually all trial related processes, it also has a considerable number of interfaces. It contains the investigator and ethics committees address data which are e.g. required for sending out Dear Dr. Letters, it mirrors the site visit structure and trigger payments to investigators, etc.

When replacing a CTMS, it is thus inevitably important to invest an adequate amount of time and resources to analyze the business processes that the CTMS is supposed to support. The process analysis can then also be used to derive functional requirements for the URS.

Yesterday, I as at the kick-off for a new project, aiming at the revision of our CTMS, and it was clearly stated: First processes, then systems. Which reminds me of this:


©Far Side

I am very satisfied that this approach has become standard in our clinical development unit. Any new business project starts with a thorough process analysis and documentation. That's the way I like it!

Safety narratives in CSRs

According to the ICH E3 Guideline (Structure and Content of Clinical Study Reports), each study report (CSR) must contain a section on Safety (section 12). Most of the content here are listings, but section 12.3.2 requires Narratives of Deaths, Other Serious Adverse Events and Certain Other Significant Adverse Events.

A narrative is a brief textual description of the case. An interesting question is, where the content for these narratives comes from and who is supposed to to provide or write it. This could be either the Drug Safety (Pharmacovigilance) unit, or Medical Writing. Drug Safety could argue that the basic ocntent already exists as part of the CIOMS (Council for International Organizations of Medical Sciences) forms that are used for SAE reporting (reporting of Serious Adverse Events) and that have been submitted to the authorities already. On the other hand, Medical Writing could argue that these narratives are too lengthy and elaborated and not suitable for inclusion into the CSR. In addition there might be diverging data elements, such as reference dates.

A solution might be to use the clinical database to generate the CSR Safety Narratives automatically. One could develop a standard text, which is then filled with database content. This would create narratives that all have the same "look and feel", even though they might render somewhat "mechanic" texts. There are also some advantages:

• There are no more data divergence problems, since all data comes from one system. However, it should be checked whether the number of items being subject to reconciliation needs to be increased to ensure that all data being used for creating the narrative from the clinical system is consistent with the corresponding elements in the Drug Safety system.


• The narratives can be kept brief and there is no need for harvesting CIOMS forms. Those could be made available to the authority upon request.


• If the data extraction process is validated, there is no need for output validation of each narrative.


• The narratives must not be reviewed by medical experts with regard to correctness.

If any of you has experience regarding this issue, I would really appreciate your feedback.

Reporting of Adverse Events to BfArM

Sorry for mixing German and English in this post.

Over the past days, I had a discussion with our Pharmacovigilance unit on the reporting requirements regarding Adverse Events. I first questioned, whether it is necessary to perform a Sponsor Causality Assessments (SCA) for all non-serious Adverse Events. The German law "Arzneimittelgesetz" (AMG) requires in § 63b (4):

Der zuständigen Bundesoberbehörde sind alle zur Beurteilung von Verdachtsfällen oder beobachteten Missbrauchs vorliegenden Unterlagen sowie eine wissenschaftliche Bewertung vorzulegen.

The previous sections (§ 63b (1)-(3) talk about Suspected Serious Adverse Reactions, whereas (4) only refers to Suspected Adeverse Reactions. This means that all Adverse Events first have to be assessed with regard to relatedness and consequently all Adverse Events where relatedness is "unknown, not likely, likely, possibly, probably", i.e. all AEs where relatedness is not set to "not related", need to be reported.

After having consulted a considerable amount of secondary material I had to conclude that my argumentation did not have sufficient bearing to go away from the current procedure.

However, since this issue only concerns PSURs (Periodic Safety Update reports) and not Clinical Study Reports and does not require blinded data, we could remove this bottleneck from the Clinical Development Process.

Data exchange standards in the clinical domain

We are currently undertaking a major program, aiming at an almost complete overhaul of processes and systems in Clinical Development and Drug Safety. I spent yesterday in 2 meetings regarding the information and data flows between the future EDC system (Electronic Data Capture) and the Drug Safety system, and the future CDW (Clinical Data Warehouse).

The meetins clearly indicated that standards are becomingly increasingly important. The current clinical IT landscape is homegrown and all systems are integrated at database level, thus ensuring referential integrity and ease of transfer. However, some of the advantages will be lost due to the strategy of going for COTS (Commercial off the shelf) software. In addition, using an ASP model, or collaborating with external parties, such as CROs (Contract Research Organizations), require that the exchange mechanisms are clearly defined.

In the clinical domain, the set of CDISC standards is becoming more widespread. Consequently, we decided that CDISC SDTM is our choice regarding the internal and external transfer of clinical data. On the other hand, within the Pharmacovigilance domain, E2B is commonly used. Unfortunately, no systems speaks all languages and dialects and we do not have a lingua france for this purpose yet. While waiting for it, we have to teach our systems different languages, i.e. we have to develop interfaces that also allow data mapping and conversion.

BPM Organization in IT or Business

Yesterday, I was interviewed by a student who is currently writing his MSc-thesis on BPM, more specifically, on the establishment of BPM Centers of Excellence (CoE). He also asked me, where a BPM CoE should be located in the organization.

In many organizations, including ours, the BPM CoE is located within the IT department. Of course, one could argue that this creates a BPM organization that is only remotely connected to the business. On the other hand, there are also good reasons for this set-up:

(1) Being cross-functional IT has a perspective that spans across borders within and across the organization.

(2) The IT unit has no functional stakes to defend.

(3) Since BPM is closely connected to EA (Enterprise Architecture), a close collaboration between these areas is fostered.

(4) BPM also requires a level of IT competence that frequently does not reside within the business organization.

However, this does not mean that BPM can be run as an initiative by IT alone. Close cooperation between business and IT is required and even if the term is somewhat overused, "alignment" seems to be a good expression in this case.

What is BPM?

I am looking for a good definition of Business Process Management. Any suggestions? Here is my current proposal:

Business Process Management (BPM) is itself a process that ensures continued improvement in an organizations performance. It is thus the meta-process that defines the framework and provides the tools for driving and improving performance in business processes.

There is also a discussion regarding this issue on the BPM Focus discussion board.

Upcoming conference

On January 30-31, 2007, I will be giving a presentation at a conference on Business Process Management in Berlin. The twist will be on the establishment of a corporate structure and approach to BPM. The slides will be published on my website after the conference.

BTW, the slides from the IIR event on Business Process Management in September are already published there for download, so if you are interested, just go and check them out.

1st entry - Black Forest Group Meeting

Last week, I participated in a meeting of the Black Forest Group, a relatively unknown, yet rather influential group of representatives of large companies that share a common interest in the use of information technology.

One of the topics under discussion was the influence of blogs and other Web 2.0 (or are we already talking about v 3.0?) phenomena. After having thought for quite some time about becoming a blogger myself, I finally started it today. Let's see what happens ...

The meeting also reminded me of the times when I was working as a researcher. The discussions were really inspiring. I also met Prof. Marceo De Marco and it turned out, that we have a lot of friends and colleagues in common.