10.4 OIDs and Clinical Data Keys

OpenClinica uses Object Identifiers (OIDs, sometimes referred to as OpenClinica IDs) to link objects to one another, and enforce uniqueness within an instance of OpenClinica (with the exception of Rule OIDs, which must only be unique within a study).  We currently utilize OIDs for the following objects in OpenClinica:

• CRFs
• CRF Versions
• Item Groups
• Items
• Measurement Units
• Rules
• Study Event Definitions
• Studies
• Sites
• Study Subjects

Each OID generated by OpenClinica starts with a prefix based on the type of entity, followed by n characters taken from the start of the proper name of the object (alpha-numeric only and converted to all caps), plus a random number at the end if the OID already exists in the database. This random number is generally 3-4 characters long (345, 5678, etc). Each part of the OID is separated by underscores. Using this scheme, we generate the following OIDs for objects:

• CRF: F + first 12 alpha-numeric characters in the CRF Name + random number if necessary (e.g. F_PHYSEXAM_7133)
• CRF Version: the CRF OID + the first 10 alpha-numeric characters in the CRF Version Name + random number if necessary
• Item Group: IG + first 5 alpha-numeric characters in the CRF Name + all the alpha-numeric characters in the Item Group Label + random number if necessary
• Item:  I + first 5 alpha-numeric characters in the CRF Name + first 26 alpha-numeric characters in the Item Label + random number if necessary
• Measurement Unit: MU + first 37 alpha-numeric characters in the measurement unit name + random number if necessary
• Rule: generated by user input at the Import Rules stage of OpenClinica. Must be alpha-numeric and all caps (underscores allowed) with a maximum 40 characters. Each Rule OID must be unique within the study that it is uploaded to.
• Study Event Definition: SE + first 28 alpha-numeric characters in study event definition name + random number if necessary
• Study: S + first 8 alpha-numeric characters in the Studys Unique Protocol ID + random number if necessary
• Site: S + first 8 alpha-numeric characters in the Studys Unique Protocol ID + random number if necessary
• Study Subject: SS + all alpha-numeric characters in the Study Subject ID + random number if necessary. Each Study Subject OID will be unique within the entire OpenClinica instance. In ODM, Study Subjects are given a SubjectKey to identify a specific subject that is unique within the study, while OpenClinica Study Subject OIDs are unique across all studies in the instance.

ODM defines a system of OID uniqueness constraints for Element Identifiers and references, which only require uniqueness within certain contexts.  For example, the Study OID has to be unique within a series of ODM documents, while an OID for ItemGroup has to be unique within its Study only.  Aside from that, notable requirements for ODM OID uniqueness include the following:

• ODM OIDs for each element type inside a MetaDataVersion must be unique for that scope of the MetaDataVersion.
• MetaDataVersion OIDs must be unique within the containing Study.
• ArchiveLayout OIDs, while not used in OpenClinica yet, must be unique within a single FormDef.
• Study OIDs must be unique within the containing ODM.
• Measurement Unit OIDs must be unique within the containing Study.
• User, Location and Signature OIDs, while not used in OpenClinica yet, must be unique within the containing AdminData.

OpenClinica generally adheres to these contraints, but OpenClinica OIDs are also unique across all studies in a single instance of OpenClinica. Because of this, an entity (such as a CRF) loaded into a separate instance of OpenClinica may not have the same OIDs in the new instance since those OIDs may already be assigned. This has drawbacks for reuse of CRFs and Rules across instances (such as porting a study definition from test to production) because the OIDs of items, groups, forms, and events that are referenced in the Rules may change when loaded into the new instance.

The ODM standard uses the concept of Internal Clinical Data Keys to uniquely address clinical data entities within the model. The following table details the key, or combination of entity identifiers, that you would need to uniquely and specifically address a clinical data entity.

For example, an XPath query to retrieve a specific item data value in an OpenClinica ODM Extract would be of the form:

/odm:ODM/odm:ClinicalData[@StudyOID=’S_P12345_2818′]/odm:SubjectData[@SubjectKey=’SS_101′]/odm:StudyEventData[@StudyEventOID=’SE_INITIALT’ and  @StudyEventRepeatKey=’1′]/odm:FormData[@FormOID=’F_AGEN_V10′]/odm:ItemGroupData[@ItemGroupOID=’IG_AGEN_DOSETABLE-F_AGEN_V10′ and @ItemGroupRepeatKey=’1′]/odm:ItemData[@ItemOID=’I_AGEN_AGENT_NAME’]/@Value

In the image below you can see that the latter half of the XML file (the part  contained in the <ClinicalData> tags) links to specific tables in the OpenClinica database. We then link back to the Study metadata through those OIDs. Internally we dont use OIDs in those tables, but instead the conventional methods of primary keys and foreign keys in the database is good enough. For more on how ODM, OIDs, and Clinical Data Keys are implemented in OpenClinica see the blog post, “Thoughts on Code: OpenClinica and Open Standards with CDISC”.