This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Adding ID data type and associated impact analysis

From HL7Wiki
Revision as of 16:19, 20 September 2016 by Hugh Glover (talk | contribs) (→‎Example 2)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Return to BRIDG

Download Slide Deck

Please download the slide deck describing this issue in detail and add your comments below.

Media:Adding_ID_data_type_and_associated_impact_analysis_v3.pptx

Comments

Impact Analysis

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.

​ ​
Field​ Data Type Comments
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.


Examples

Example 1

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:

ID Example 2.png

StaffMember.identifier.ID
identifier
extension: abc123
sourceCode
displayName: Whizz-CTMS (code)
typeCode
displayName: Pharma assigned Identifier

Example 2

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.

ID Example 2.png

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

ID Example 1.png

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