Adding ID data type and associated impact analysis
Return to BRIDG
Download Slide Deck
Please download the slide deck describing this issue in detail and add your comments below.
Before beginning a detailed analysis of the possible impact of such a change on BRIDG we need to understand exactly what is being proposed. The following description is taken from the vendor making the proposal and reflects their practical experience. These definitions can be further refined.
ID Data Type - draft definition
The ID data type contains the standard II data type provided by ISO21090, but in BRIDG on many occasions where an identifier is required there is also a requirement for a type code to make it clear what sort of identifier we are looking at. For example is this a system identifier or a user entered identifier?
In cases where both a system identifier and a user entered identifier are required the only way to manage this at present is to put the identifier and the type code into a separate class and provide an association with a cardinality upper limit of >1. Using this class as if it were a data type allows us to have an identifier attribute rather than a complete class.
A further issue arises when the provenance of an identifier is required: "what sort of system provided the system identifier?" and even: "exactly which system provided the system identifier?". To meet these needs a sourceCode and sourceIdentifier attribute are provided. The relationship of these to the BRIDG concept of SystemOfRecord needs further thought.
Finally when BRIDG puts an identifier into a separate class it often has a primaryIndicator and an effectiveDate associated with them.
|dentifier ||II ||The actual identifier - composed of an optional root value to guarantee uniqueness and an extension value which is what would commonly be thought of as the "identifier"|
|typeCode||CD ||A value specifying the kind of identifier that this is. This is used to distinguish a system generated identifier from (say) a user entered identifier.|
|sourceCode ||CD||A code representing the kind of system that provided the identifier. Note that this is what provided the identifier to the application and is not by definition the initial creator/issuer of the identifier.|
|sourceIdentifier ||II||An identifier representing a specific instance of of a system (as specified in sourceCode) that provided an identifier to the application. Note that this is not by definition the originator of the identifier merely the one that provided it to the application.|
|effectiveDateRange ||IVL_TS_DATETIME ||The date interval when the ID is valid. Before the start date and after the end date the ID is not valid and should not be used.|
|primaryIndicator ||BL ||Set to true if this is the main identifier in cases where multiple identifiers are given. While this is close in concept to a Primary Key is actually a somewhat looser concept.|
Smart Pharma have purchased a Whizz-CTMS and are using this to manage all of their studies. Whizz-CTMS has a staff and investigator module that provides "master data" for these business entities, and includes uploading and de-duplication of commerically available investigator lists. Other systems within Smart Pharma need to be able to identify staff, and particularly investigators - for payment, for document management (e.g. investigator CVs and qualification documentation) andare using the Whizz-CTMS as the "master" for identification.
Elspeth Louise Smith is on the Smart investigator list in Whizz-CTMS with an identifier of abc123. She is a consultant cardiologist at Good Health Hospital and has participated in several studies.
When sharing Dr Smith's information from the Whizz-CTMS to other systems, the Staff Member and RegistryContext classes are used:
- extension: abc123
- displayName: Whizz-CTMS (code)
- displayName: Pharma assigned Identifier
Ace CRO is managing a trial for Smart Pharma that will run in 2 countries (UK and Germany). Smart has a consolidated investigator list across all 12 countries it operates in and a site list for the UK, but nothing for Germany. Smart have asked Ace to recruit additional investigators and sites and Ace have their own investigator and site lists. Both Smart and Ace have quality measures against the investigators so that some are effectively blacklisted. The trial will therefore have a consolidated investigator list and an investigator will be blacklisted on the consolidated list if they are blacklisted on either of the individual lists. Investigator recruitment and monitoring during the conduct of the trial will result in additional investigators being added and may result in additional blacklisting.
Elspeth Louise Smith is on the Smart investigator list with an identifier of abc123. She is a consultant cardiologist at Good Health Hospital.
The Ace list has L Smith with an identifier of 991122 who is also a consultant cardiologist at Good Health Hospital.
De-duplication of the lists identifies these two records as being for the same person.
To run the trial Ace use the A-CTMS software package to manage the trial and A-EDC to capture the actual clinical data. In both cases the consolidated investigator list is loaded. Each package assigns its own internal identifier for each investigator.
Ace are also running a trial for Exoto Pharma and there are some sites where both trials are running. A-CTMS is a cloud based application and a single instance of the package can handle multiple trials on multiple sites. To provide adequate capacity multiple instances of A-CTMS can be running at any one time. In this example the instance identifier in use is 990-88-3
Where do all these bits of identifier data go in the structures? We use the same simple model to illustrate the use.
StaffMember.identifier.ID identifier extension: abc123 sourceCode displayName: Smart investigator list typeCode displayName: Pharma assigned Identifier identifier extension: 991122 sourceCode displayName: Ace investigator list typeCode displayName: CRO assigned Identifier identifier extension: a-11-bb-22 sourceCode displayName: A-CTMS typeCode displayName: System assigned identifier sourceIdentifier extension: 990-88-3
Ace use a master data management system (AceMDM) for all the identifiers (this is how the deduplication was done) and it can be used to query any identifier. To manage this we need a slightly more complex model
Taking the example from above (with … in place of some details) we get the following.
StaffMember.identifier.ID Identifier ... Identifier ... Identifier ... RegistryContext contextCode displayName: Investigator typeCode displayName: AceMDM