ODM Tutorial: Working with AdminData

In the first ODM Tutorial I concentrated only on the study design MetaData elements of the ODM and didn't cover AdminData at all. 

 

What is AdminData?

 

The ODM AdminData element is a container for information about Users and Locations (Study sites) that have involvement in the collection of the clinical data.

 

In an ODM file AdminData appears inside the ODM element. You’ll see that AdminData appears at the same level as Study because they are logically independent, Study does not rely on AdminData and AdminData does not rely on Study.

 

<ODM xmlns="http://www.cdisc.org/ns/odm/v1.3"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"
    ODMVersion="1.3"
    FileOID="000-00-0000"
    FileType="Snapshot"
    CreationDateTime="2009-02-20T06:56:00">

  <Study OID="ST.001">
    ...study elements ...
  </Study>


  <AdminData>
  ...admindata elements...
  </AdminData>


</ODM>

 

AdminData has a single optional attribute, StudyOID which references the study which this AdminData is related to.

 

An ODM file can contain more than one Study and more than one set of AdminData. If no StudyOID is provided then it's assumed that the AdminData is relevant for all studies in this ODM file.

 

Here I'm going to be explicit and make it clear that this AdminData is related to the study:

 

<AdminData StudyOID="ST.001">
    …contents…
</AdminData>

 

AdminData may contain User, Location and SignatureDef elements. We'll look at each.

 

Users

 

A User is defined as someone who has access to the data collection system, this usually means Sponsor or Investigator users. ODM 1.3 allows the collection of various details about a user but most of them are optional. Here is the minimal valid User element:

 

<User OID="UD.MFIELDS"/>

 

A User is required only to have an OID. This is enough to identify a user in AuditRecords and Signatures that appear in the ClinicalData section of an ODM file.

 

Although enough to identify a user uniquely, you will likely want to give some other clue as to what role the user takes in the study. The ODM provides the optional UserType attribute for this purpose. It can take one of the following values: Sponsor, Investigator, Lab or Other.

 

<User OID="UD.MFIELDS"  UserType="Investigator"/>

 

That isn’t giving us much information about the user so you might want to include their LoginName, Firstname and Lastname? The ODM provides for that:

 

<User OID="UD.MFIELDS"
     UserType="Investigator"
     LoginName="mfields"
     FirstName="Martin"
     LastName="Fields">
</User>

 

If you want to provide more information about a user there are many fields that can be completed.

 

<User OID="UD.MFIELDS"
     UserType="Investigator"
     LoginName="mfields"
     DisplayName="Martin Fields"
     FullName="Martin John Fields"
     FirstName="Martin"
     LastName="Fields"
     Organization="MGH"
     <Address>
        <StreetName>Massachusetts General Hospital</StreetName>
        <StreetName>55 Fruit Street</StreetName>
        <City>Boston</City>
        <StateProv>Massachusetts</StateProv>
        <PostalCode></PostalCode>
        <Country>USA</Country>
        <OtherText></OtherText>
      </Address>
      <Email>mfields@example.com</Email>
      <Email>martyfields@home.example.com</Email>
      <Picture PictureFileName="mfields.jpg" 
               ImageType="jpeg"/>
      <Pager></Pager>
      <Fax></Fax>
      <Phone>1-999-999-9999</Phone>
      <Phone>1-888-888-8888</Phone>


      <LocationRef LocationOID="LD.MGH"/>


      <Certificate>
         <!-- Optional, reserved for future use -->     
      </Certificate>
</User>
 

Except for the OID, all the above fields are optional. Lets talk about a few of them.

 

The Address element deserves some discussion of its own. Although you can link a user to a Location via the LocationRef (and we'll get to that) a user might have separate contact information so the optional Address element provides it.

 

See that I included two StreetName elements, that's valid.

 

It's also possible to have multiple Email, Pager and Fax elements but there is currently no way to show that one is a home, cell or work contact. My advice would be to list the primary ones first, the order doesn’t have any inherent meaning in the ODM but when reading the XML file processing tools will generally read them in the order listed.

 

Before we talk about LocationRefs, a comment about Certificate elements. This element is a placeholder in the ODM 1.3, it could be used in conjunction with Public/Private key encryption to hold the users Public key. This would allow Digital Signatures made with the Private key to be verified. See the Wikipedia article on Public Key Cryptography for a full treatment of this subject.

 

LocationRefs

 

A User element can contain zero or more LocationRef elements. 

 

<User OID="UD.MFIELDS">
      <LocationRef LocationOID="LD.MGH"/>
</User>

 

These each have a LocationOID attribute which references a Location by its OID.

 

A Location is a building where something related to the study happens. Usually it will be a Physicians office where study data is collected but it can also be a Sponsor office. Each LocationRef indicates that the user has an association with that Location. The meaning of that association isn’t explicit in the ODM it’s implied by the UserType.  We don’t know if a User is a CRA or an Investigator for a site but we can probably work it out from a Sponsor or Site UserType if it’s provided.

 

Locations

 

LocationRefs relate to Locations. A Location element appears at the same level as the User elements under AdminData. Here is a complete Location example:

 

<Location OID="LD.MGH" 
         Name="MGH"            
         LocationType="Site">

   <!-- Must have at least one MetaDataVersionRef -->
   <MetaDataVersionRef StudyOID="ST.001" 
                      MetaDataVersionOID="MD.001"
                      EffectiveDate="2009-11-01"/>      

</Location>
 

 

You might find it surprising that a User can have an Address but a Location can't. I'm confused myself, maybe one of the ODM guru's will comment and explain it.

 

The LocationType for a site is optional and can be one of Sponsor, Site, CRO, Lab or Other.

 

Something that isn't optional is the MetaDataVersionRef. It references the MetaDataVersion (no Def postfix) inside the Study. In this case we're saying that the MGH location accepted MetaDataVersion MD.001 in the Study ST.001 on the 1st November 2009. The date definition follows the YYYY-MM-DD convention and not the more precise datetime e.g. 2009-11-01T09:34:01 but it is probably precise enough.

 

Anyone in this business will tell you that study amendments are common. As new MetaDataVersions are made available Locations will start to use them, maybe on different dates based on Institutional Review Board agreement. A Location might end up with a number of MetaDataVersionRef elements, each showing at what time they accepted and started using each MetaDataVersion for the study:

 

<Location OID="LD.MGH"        
         Name="MGH"          
         LocationType="Site">

     <MetaDataVersionRef StudyOID="ST.001"
                         MetaDataVersionOID="MD.001"
                         EffectiveDate="2009-11-01"/>      

     <MetaDataVersionRef StudyOID="ST.001"
                         MetaDataVersionOID="MD.002"
                         EffectiveDate="2009-12-14"/>      
</Location>
 

 

SignatureDefs

 

The final type of element that can appear inside AdminData is a SignatureDef. This element defines the meaning of signatures that can be applied to Clinical Data.

 

<SignatureDef OID="SIGD.001"
              Methodology="Electronic">
     <Meaning>Investigator Signature</Meaning>
     <LegalReason>
     The signer agrees and attests that the
     data is an accurate representation of the source.
     </LegalReason>
</SignatureDef>

 

A SignatureDef can be referenced in a Clinical Data SignatureRef as the why part of the who (UserRef), why (SignatureRef), when (Date), where (LocationRef) combination that makes up a signature.

 

The Methodology attribute can be Electronic or Digital. A digital signature is based on a cryptographic key (e.g. the Private key of a Public/Private Public Key Encryption pair).  An eclinical system that relies on the entry of a username/password combination alone to establish a signature is generally using the Electronic signature method.

 

A SignatureDef is required to have a Meaning element which contains a short description of the purpose of the signature (e.g. Approval, Review, Verification etc) and the Legalese of what the user is agreeing to when they apply that kind of a signature. An eclinical system will display the LegalReason along with the opportunity to apply a signature.

 

Wrap Up

 

There we have it. The AdminData element of the CDISC ODM 1.3 isn't too complicated and there are many optional elements.

 

Here is a partial ODM file that wraps up all the examples. Good luck in your own CDISC ODM adventures.

 

<ODM xmlns="http://www.cdisc.org/ns/odm/v1.3"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xml="http://www.w3.org/XML/1998/namespace"
    ODMVersion="1.3"
    FileOID="000-00-0000"
    FileType="Snapshot"
    CreationDateTime="2009-12-28T06:56:00">

  <AdminData StudyOID=”ST.001”>
     <User OID="UD.MFIELDS"
          UserType="Investigator"
          LoginName="mfields"
          DisplayName="Martin Fields"
          FullName="Martin John Fields"
          FirstName="Martin"
          LastName="Fields"
          Organization="M.G.H"
          <Address>
             <StreetName>
                  Massachusetts General Hospital
             </StreetName>
             <StreetName>55 Fruit Street</StreetName>
             <City>Boston</City>
             <StateProv>Massachusetts</StateProv>
             <PostalCode></PostalCode>
             <Country>USA</Country>
             <OtherText></OtherText>
           </Address>
           <Email>mfields@example.com</Email>
           <Email>martyfields@home.example.com</Email>
           <Picture PictureFileName="mfields.jpg"
                   ImageType="jpeg"/>
           <Pager></Pager>
           <Fax></Fax>
           <Phone>1-999-999-9999</Phone>
           <Phone>1-888-888-8888</Phone>

           <LocationRef LocationOID="LD.MGH"/>

           <Certificate/>
     </User>

     <Location OID="LD.MGH"        
              Name="MGH"          
              LocationType="Site">
          <MetaDataVersionRef StudyOID="ST.001"
                             MetaDataVersionOID="MD.001"
                             EffectiveDate="2009-11-01"/>      

          <MetaDataVersionRef StudyOID="ST.001"
                             MetaDataVersionOID="MD.002"
                             EffectiveDate="2009-12-14"/>      
     </Location>

     <SignatureDef OID="SIGD.001"
                  Methodology="Electronic">
          <Meaning>Investigator Signature</Meaning>
          <LegalReason>
          The signer agrees and attests that the
          data is an accurate representation of the source.
          </LegalReason>
     </SignatureDef>

  </AdminData>
</ODM>
 

Using EDC at your clinical site? Take the time for a Survey

TechTeam Global and the eClinical Forum are running a Survey to collect information about the use of EDC at clinical sites and how it has changed in the seven years since a survey of this type was last undertaken.

 

If you are using EDC at your clinical site, help them out by answering the questions here:

 

http://www.techteam.com/services/specialized-solution-support/eclinical-support-services/eclinical-survey

 

The results of the survey will be published at the DIA Clinical Forum being held in NiceOctober 19-21, 2009

 

From the Press Release, Back in July 2001:

 

•    * 52 percent of survey respondents had experience with EDC. Within that

  group, 44 percent of clinical trials used EDC.   
•    * The majority of patient data was still entered traditionally in paper patient records, with only 14 percent of data entered directly in electronic case report forms (eCRF).
• 
  * 69 percent of investigators said EDC would positively affect their decision to participate in trials.
• Have times changed? Make sure your opinion counts!
  

Oracle RDC Promotional Video

Oracle seem to be promoting Oracle RDC more actively at the moment, not that you’d know it from the Oracle RDC marketing page.

 

Those who dig further into their health sciences website will be rewarded with a link to a slickly produced video demo of Oracle RDC.

 

Be warned. Rogue elements within Oracle marketing have deviated recklessly from the standard gray, red and black of the Oracle marketing palette.

 

Here’s a screenshot and a link to the video (Flash required):

 

http://www.oracle.com/industries/health_sciences/demo/oracle-remote-data-capture.html

 

You can read more about Oracle RDC at the Oracle Health Sciences website.

SAMP-101 Jozef Aerts XML4Pharma Contribution

Jozef Aerts of XML4Pharma has been very helpful in straightening out the errors and inconsistencies that appeared in early drafts of the ODM Tutorial and the SAMP-101 example ODM file.

 

Last week my thoughts turned to visualizing ODM files and I mentioned the ODM PDF creation tool that Jozef offers at XML4Pharma.

 

Jozef has kindly run the SAMP-101 ODM sample file (now version 1.2) through his PDF creator which creates a more human-readable version of the file structure. Here’s a screenshot of the result and you can download the full file here: SAMP101_XML4PHARMA.pdf.

 

 

The ODM is a useful standard that gives at least a baseline for clinical trial specification and design but tools like this are vital to make it accessible to the non-XML reading population which is 99.9999% of us (for the record, it’s no party for the other 0.0001%).

 

You can find the PDF creator and other tools at CDISC section of the XML4Pharma website: www.XML4Pharma.com/CDISC/

 

Thanks Jozef!

Interview: Dominic Farmer, Cisiv CEO

I’ve been throwing some emails back and forth with Dominic Farmer, CEO of Cisiv,  to understand the company's position on real world patient data and EDC. Below is the email interview which came out of this correspondence, posted with Dominic’s permission.

 

Eco: What are the origins of the cisiv platform?

 

Baseline Plus developed from the requirements of a leading pharmaceutical company for a large non-interventional study. This study grew quickly from several hundred patients in one country to over 8000 patients across 18 countries, with support for multiple language versions. Different approaches to gathering data were required based on local regulation and requirements.

 

This study has run now for over six years: in that time the Health Economics and Patient Outcomes data has been used in HTA submissions throughout the world as well as in a long stream of publications. In some countries the investigators have set up study groups in which they have shared findings and developed publications.

 

Soon after this study, we were commissioned by the sponsor to deliver several more studies including a large global safety study which was a licensing requirement. We realised that our success in these projects was based on our combination of technology and consultancy specific to non-interventional studies and the ease with which customers could set up large studies of this type. The flexibility to adapt to different local environments was driving the demand for our specialised product.

 

On this basis, we took the decision that Baseline Plus could serve a wider market. We talked to existing and future customers to find out more about their needs and looked at how to reduce the complexity involved in allowing a study to accept and manage change, growth and local variation. These were all built into the platform to provide a highly streamlined, modern EDC system aimed exclusively at non-interventional studies.

 

Eco: What makes cisiv different?

 

Our expertise is based on bringing together the technology to support large-scale real world data capture programmes and making the process as easy as possible for investigators. With non-interventional studies, the number of investigators is much higher than Phase III and IV clinical trials and the typical volume of patients that each investigator works with is lower. The time and cost spent on training has to be lower to make the study economically viable, as well as getting the study up to speed faster.

 

What marks Cisiv out is that we have specialised in the capture and use of real-world patient data, looking only at non-interventional studies. Instead of trying to make traditional EDC tools fit in with real-world data capture, Cisiv’s approach is more flexible. We support a far greater variety of study programmes and designs, rather than changing the study to fit in with the technology platform.

Eco: How do you see the market for EDC maturing?

 

The pre-approval EDC market is pretty mature; where there is the greatest opportunity is in post-approval studies, such as the non-interventional studies that we are working on. This is being driven by a couple of things: firstly, the changing state of the pharmaceutical industry means that economically, proving the efficacy of treatments will be critical to reimbursement programmes.

 

Oncology medicines are already being sponsored by pharma companies on the proviso that they will be paid if the treatment is successful, which makes understanding where a treatment will succeed in a real world setting essential.

 

The success of healthcare is increasingly being measured in terms of patient outcomes rather than meeting targets. This makes for a more complex market that now includes patients as well as payers and prescribers. Understanding patients, as opposed to the subjects of clinical trials, will become increasingly important in the success of a drug in the market.

 

The second driving factor for EDC will be regulation: there are increasing moves, starting with the FDA, to require post-approval safety studies. This comes from the awareness that modern drugs are not as safe or effective for some people as they are for others. It is therefore important to understand where drugs work best to be able to deliver the best healthcare to the patient. Observational studies help us identify the epidemiological patterns behind safety issues and from these we understand better how treatments work. .

Eco: What are the challenges and needs of non-interventional studies?

 

The biggest challenge around non-interventional studies is one of knowledge. Being able to ask the right questions about how to set up and manage a non-interventional study is still very new to the pharma sector. The differences between gathering clinical trial data and real-world patient information are huge, so building awareness of these changes is key to these studies being successful in the future.

 

The other challenge that non-interventional studies face is paper: there is still a feeling that data capture processes should follow this approach of collecting information. When I speak to pharma companies about this, there is a belief that investigators will want to use paper. This is not true: one of the companies that we have run a study with used both paper and EDC alongside each other, and after three months, the paper channel was discontinued. Investigators prefer the immediacy and ease of use that the right EDC approach can offer.

 

This is an issue for the whole industry, but we expect more take-up of EDC and web 2.0 approaches as those responsible for managing these sorts of projects can gain more experience with IT. Overall, it just creates more opportunities for the pharma company as well as better value for the investigators and patients involved.

Eco: There is a lot of buzz in the EDC Market regarding EHR integration at the moment. How do you see EHR integration impacting non-interventional studies in particular?

 

Frankly, I don't know. Pulling EHR data together across a broad range of sites or health services is still a long way in the future. There are lots of different systems around the world, lots of sites still to get onto EHR and no common definition of what data constitutes a health record. In the short term non-interventional studies will still be the best way of collecting a consistent data set across multiple sites in multiple countries.

Eco: How do you define Web 2.0, and how is it affecting the pharma industry?

 

Web 2.0 is more of a movement than a technology. The original definitions include user contributions, collaboration, information sharing and interoperability. We are interested in Web 2.0 as a way to access the “long tail” – for EDC and trials, this represents a broader number of investigators and patients that it would not have been practical or economic to engage with, without using new web technologies. Using a Web 2.0 approach, studies can gather small pieces of information from a large number of people and accumulate them to provide value both to the individual and the community.

 

Ultimately, the results are the primary goal, rather than the methods used to achieve them. By focusing on engaging with investigators at the beginning, and encouraging them to collaborate, taking this Web 2.0-style approach allows study sponsors to be more creative with inclusive programmes which both gather data and provide value back to the whole community.

 

Eco: Thank you Dominic.

 

If you are interested in anything more around handling the collection of real-world patient data, then go to www.cisiv.com.

 

[ Here is the EDC Survey result for Cisiv ]