# Clinical Trials: Representing specific data items **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2012-05-31 13:50 UTC **Views:** 1 **Replies:** 5 **URL:** https://discourse.openehr.org/t/clinical-trials-representing-specific-data-items/15175 --- ## Post #1 by @ANASTASIOU_A1 Dear All I am interested in understanding the way that specific data collected from a clinical trial would be stored in the E\.H\.R\. \(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?\) 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?\) 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? Looking forward to hearing from you Athanasios Anastasiou GORY DETAILS: \(Throughout this section, i will be referring to previous work by Christian Kohl available from: http://www.klinikum.uni-heidelberg.de/fileadmin/inst_med_biometrie/med_Informatik/Health_Data_Management/ValEHRia/Study-Metadata_1.3.zip 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\) 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\. 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\) 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\. 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 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\) \(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? --- ## Post #2 by @ian.mcnicoll 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 COMPOSITION/context/other\_context\. > \(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 > > GORY DETAILS: > \(Throughout this section, i will be referring to previous work by Christian > Kohl available from: > http://www.klinikum.uni-heidelberg.de/fileadmin/inst_med_biometrie/med_Informatik/Health_Data_Management/ValEHRia/Study-Metadata_1.3.zip > > 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\. --- ## Post #3 by @ANASTASIOU_A1 Hello Ian Many thanks for the helpful response, please see below: > 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\)\. That's good to know\. It was how i was planning to do this initially \(separate "assets" database\) but wanted to verify if there is a related openEHR good practice\. > 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\. Many thanks, Christian's work \(at least what i have available here\) "only" covers the admin part of the CT, not the part where data will have to be collected and associated with one\. \(the "only" is still rather detailed :\-\) \) >> 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\. Correct\.\.\.That's a byproduct of focusing so hard on Archetypes :\-/ All the best Athanasios Anastasiou --- ## Post #4 by @Colin_Sutton A few related comments: \* Much of the study metadata should already be in the clinical trials registry \- so store a reference to that in the local trial metadata \(the trial design details and other items needed to classify the patient that are specific to the trial\); \* If the study is not blinded, the patient details do not need any special treatment in the EHR; they could be accessible by the same means as any subject data\. If that data is public, of course, anyone could analyse it\.\.\.\. \* if the study is blinded, any data that could possible unblind, including the patient identifier, should be in a private database\. The public data about the subject should be stored in parallel to the private data\. Any blinded treatment should be shown in the public data as \[study treatment name\]\.T his is particularly important to ensure the patient is not accidentally enrolled in more than one trial \(or the same trial twice\!\); \* when the study is completed or terminated, it would be useful that the previously blinded data is publicly accessible\. That would be eased by using archetypes to store the private data\. Colin Sutton NHMRC Clinical Trials Centre Sydney, Australia \(These are my own opinions, not necessarily those of the CTC\) --- ## Post #5 by @thomas.beale I would expect that at some point openEHR should add some more aggregating top-level structures to the Reference Model to take care of grouped data from clinical trials, particularly in cases where there are multiple 'studies', or multiple concurrent 'trials'. Probably experts like Colin could help devise the correct structures (CDISC models should be looked at as well). - thomas --- ## Post #6 by @ANASTASIOU_A1 Dear all Thank you very much for the helpful comments\. Very briefly, in addition to the work carried out by CDISC \(that has its own quirks\), i have found the "Ontology of Clinical Research" http://bioportal.bioontology.org/ontologies/46936?p=terms very helpful when thinking about archetypes for Clinical Trials\. \(The "value set" and "Statistical Concept" concepts are very detailed\) All the best Athanasios Anastasiou --- **Canonical:** https://discourse.openehr.org/t/clinical-trials-representing-specific-data-items/15175 **Original content:** https://discourse.openehr.org/t/clinical-trials-representing-specific-data-items/15175