Clinical Trials: Representing specific data items

Ian McNicoll Ian.McNicoll at
Thu May 31 12:01:11 EDT 2012

Hi Athanasios,

Thoughts inline below.

> I am interested in understanding the way that specific data collected from a
> clinical trial would be stored in the E.H.R.

Storing the result of a particular arm or study event i.e data
pertaining to a particular patient, is a hind of EHR and works well
within openEHR.

Basically for each study event, create a Composition, with stores the
patient and investigator identifiers, the time of the event, and , of
course the specific details collected. You will also have to record
some sort of Clinical Trial metadata, such as  Trial Identifier, Study
Arm Identifier etc, etc.

This could be done within an ADMIN_ENTRY archetype carried in
COMPOSITION/content or perhaps a CLUSTER archetype in the

> (And generally, how to associate data obtained for a particular purpose with
> an entity that describes that purpose)
> Specifically, i have the following questions while some more details about
> each one are provided after the end of the message:
> 1) How is the information identifying a clinical trial supposed to be stored
> in the EHR? (Where would a composition describing a specific trial be stored
> in?)

It is likely that you will want to store the detailed metadata for
Trial, Study arm etc somewhere else. The openEHR RM, being
patient-orientated, does not really support this sort of purpose, and
it may be easier to hold this in a parallel RDBMS, as it is pretty
static. Christian Kohl's work did use openEHR archetypes to hold this
information, but it does require some sort of hack like the 'dummy
patient' idea to make it work (or even a separate server instance).

> 2) How is it possible to "mark" some OBSERVATIONs as those acquired at a
> specific visit belonging to an arm of a specific trial? (How will this link
> be realised so that it is possible to query for all the datasets and
> subjects that participated in a specific trial? How is that done at the
> Archetype / Template level?)

See Above - Either in COMPOSITION/context via a CLUSTER or via an
ADMIN_ENTRY in COMPOSITION/content. I am pretty sure Christian adopted
one of these approaches.
> 3) Would a template have to be used to specialise entities such as
> PARTY_PROXY found at OBSERVATION Archetypes? (For example, the usable object
> would be IDENTIFIED_PARTY) Or is this supposed to be handled differently at
> runtime?
You probably do not need to populate the demographics links at
OBSERVATION level. The COMPOSITION/composer attribute would carry the
identifier for the clinical investigator and the EHR/EHRID would
identify the subject.

> Looking forward to hearing from you
> Athanasios Anastasiou
> (Throughout this section, i will be referring to previous work by Christian
> Kohl available from:
> Also, please note that wherever i am saying "Template" below, i mean
> "CompositionTemplate.xsd")
> 1) From an "ontological" point of view, the subject of openEHR is the E.H.R.
> and the top level object is exactly that. From the same point of view, the
> "Clinical Trial" is an entity on its own to which various entries in subject
> E.H.Rs are going to have to refer to. The question is:
> Where does an "entry" that represents a particular "Clinical Trial" get to
> live? Does it live in some special E.H.R. to which relevant COMPOSITIONs can
> refer to through LINKs? Or is it that every subject participating to a
> clinical trial would get a "ClinicalTrial" entry into their own E.H.Rs?
> (i.e. Study Definition Data is replicated)
I would say no - you want to carry identifiers to the Study Arm etc at
Composition level but not the detailed metadata - I think Christian's
work addressed this.

> 2) Clinical Trial OBSERVATIONs must be associated with various other
> entities. For example, the data acquisition would most probably be performed
> by a specialist from some centre participating in the trial.

See above - COMPOSITION/composer
> The OBSERVATION contains the right fields to do these associations (subject,
> provider, feeder_audit, work_flow_id). But how can i refer to a particular
> Visit within an Arm of a Clinical Trial from an OBSERVATION? (It's a little
> bit like extending OBSERVATION itself)
As Above Cluster in Composition/context or ADMIN_ENTRY in Composition/content

> I suppose here that i will have to create a Composition Archetype "Clinical
> Trial Data Acquisition" and also a "Clinical Trial Action" to represent the
> two basic entities that are required in Observational and Interventional
> clinical trials.
Well You might use a SECTION to
> The question is, how to refer back to the specific clinical trial visit from
> that? I can see two ways to do this:
> A)
> Archetype "ClinicalTrialDataAcquisitionSession" COMPOSITION
> data             SLOT of Any OBSERVATION //This is new data and it makes
> sense to have them attached directly here
> fromClinicalTrial    OBJECT_REF study_identification.v1    //This is data
> that is not supposed to be replicated and it should "live" somewhere else...
> atStudyVisit        OBJECT_REF study_visit_description.v1 //Same comment as
> above

You only need to capture the Trial/Arm/Visit information at Compostion
level. You cannot archetype an OBJECT_REF. You would need to carry
these identifiers in a CLUSTER or ADMIN_ENTRY archetype.

> B)
> Archetype "ClinicalTrialDataAcquisitionSession" COMPOSITION
> data             SLOT of Any OBSERVATION
> atStudyVisit        OBJECT_REF trial_visit_description.v1
> (OR...just add "links" to this COMPOSITION to an other E.H.R. containing the
> clinical trial)

I would avoid - limits your querying ability
> (B) requires that the clinical trial can be recovered just through the
> knowledge of the study visit.
> Would that be along the right track?
> 3) Related to the above...I can see here how the Template fits in with the
> OBSERVATION. Any OBSERVATION includes "Subject" which is a PARTY_PROXY (and
> anyway abstract). But, in the Archetype, there is nothing to hint at what
> this PARTY_PROXY should be at run-time. I suppose that when it comes to
> using OBSERVATIONs in clinical trials, i will have to specify that the
> OBSERVATION is going to be accepting PERSON (which would lead to a list of
> subjects assigned to a centre or specialist)...Is that correct or would it
> be better if the user is presented with another form of choice to decide
> what should be "attached" to an OBSERVATION's "subject" field?

In practice the user would select a subject from some sort of
demographic database which would return their EHRID, from which an
existing or new openEHR EHR would be opened, then the COMPOSITION
would be created within that EHR.

> openEHR-clinical mailing list
> openEHR-clinical at

Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at

Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care

More information about the openEHR-clinical mailing list