CDISC MDR PilotSpecification v0 4 by FB30lmK

VIEWS: 4 PAGES: 20

									                                                            CDISC MDR
                                                            Pilot Specification




              CDISC Meta data Repository
        Enrichment & integration of CDISC Data
      Standards toward semantic interoperability

                               Pilot Specification:
                               Business Scenarios


                    Prepared by the CDISC MDR Team




                                  Notice to Readers


This is a working document describing the business scenarios to be demonstrated in the
pilot CMDR in February 2009.




Revision History


    Date           Version                   Summary of Changes




                                                                                  Page: 1 / 20
CDISC MDR
Pilot Specification




                      Page: 2 / 20
                                                                                                             CDISC MDR
                                                                                                             Pilot Specification



                                                      Table of Contents

1.      INTRODUCTION ............................................................................................................................... 4
2.      SCENARIOS DESCRIPTION ........................................................................................................... 6
     2.1.    SCIENTIFIC/SEMANTIC DOMAIN IN SCOPE OF PILOT ........................................................................ 6
     2.2.    SCENARIO 1. IMPORT & DATA CURATION....................................................................................... 7
        2.2.1 Objectives ................................................................................................................................. 7
        2.2.2 Description ............................................................................................................................... 7
     2.3.    SCENARIO 2. EXPORT/DOWNLOAD OF VARIABLES IN ODM ........................................................... 9
        2.3.1 Objectives ................................................................................................................................. 9
        2.3.2 Description ............................................................................................................................... 9
     2.4.    SCENARIO 3. EXPORT/DOWNLOAD OF CONCEPTS IN ODM ............................................................10
        2.4.1 Objectives ................................................................................................................................10
        2.4.2 Description ..............................................................................................................................10
3.      ACTION PLAN TO IMPLEMENT SCENARIOS ..........................................................................11
     3.1.       PRE-REQUISITE FOR ALL SCENARIOS .............................................................................................11
     3.2.       SCENARIO 1. IMPORT & DATA STANDARD CURATION ...................................................................12
     3.3.       SCENARIO 2. EXPORT/DOWNLOAD OF VARIABLES IN ODM ..........................................................12
     3.4.       SCENARIO 3. EXPORT/DOWNLOAD OF CONCEPTS IN ODM ............................................................12
4.      APPENDIX. COMPANY SPECIFIC MDR IN ODM FORMAT ..................................................14
     4.1.       DESCRIPTION OF COMPANY SPECIFIC MDR ..................................................................................14
     4.2.       DESCRIPTION OF EXPECTED ODM FORMAT FOR DOWNLOADING CMDR CONTENT ......................17




                                                                                                                                             Page: 3 / 20
                                                                  CDISC MDR
                                                                  Pilot Specification




1. Introduction
The CMDR pilot has the following objectives
 Support definition and validation of what is needed i.e. business requirements (what
   CMDR will, and will not, deliver)
 Show that content can be created quickly (speed)
 Show that we can easily define/store/manage the content
   (simplicity/practicality/logistics)
 Show what the users will get from the CMDR (quality/fit for purpose)
 Check if the envisioned technical solution - based on BRIDG, ISO 11179/caDSR and
   EVS, ISO 21090 HealthCareAbstract Data Type- is the right approach to support the
   requirements

Following input from the requirements stream we can envisage the following scenarios for
the pilot.

Scenario                              Priority    Expected Benefit
Import and standard curation.         High        Show what needs to be done (process,
Import existing dictionaries from                 workload) to build the content of the
different companies, harmonize                    CMDR in a “industrial” way (100 variables
the content by linking to concept                 harmonized per day, rather than 1 a day).
and define a industry wide
standard variable.
 how to take the myriad of
    company specific data
    dictionaries and "merge" them
    into a single standard
 show that the format and
    content of an individual
    standard (concept + variables)
    is simple to define and capture
Export/download                       High        Show to data manager that what they
Download variables with related                   need today in terms of data dictionary is
attributes in a ODM1 format                       available – but with industry wide
                                                  definition rather than company specific
                                                  ones and with fully disambiguated
                                                  definitions
Export/download                       High        Show how we could change the way we
Download concepts descriptions,                   think about data standards – starting
linked with variables, in an ODM                  from concept at protocol level and then
format                                            linked to variables in data dictionary

1
 It could be done as well in a simple XML format. ODM has however the advantage to be an
already accepted/used standards for this purpose.

                                                                                        Page: 4 / 20
                                                               CDISC MDR
                                                               Pilot Specification



(note: this is similar than the
previous one for variables, but it
allows to provide more
information on concepts and their
relationships)
Content – usage                        Medium   Show how CMDR would be used to
 How to use while building                     ensure full semantic interoperability for
    HL7 CDISC content message                   HL7 CDISC content messages.
    at sponsor side, and reading at             Value conditional to successful pilot of
    FDA side                                    high priority scenarios
 How to extract SDTM from
    HL7 CDISC content message
Content – usage                        Medium   Show how CMDR would be used to
How to use to support data                      ensure full semantic interoperability
integration                                     within organization
                                                Value conditional to successful pilot of
                                                high priority scenarios
Content – usage                        Medium   Show how CMDR would be used to
How terminologies such as                       ensure full semantic interoperability
MEDDRA (used in                                 within organization and for submissions
pharmacovigilance), SNOMED,                     to different authorities by supporting
LOINC (increasingly used in                     mapping of existing terminologies
Healthcare in US – as HISTP                     Value conditional to successful pilot of
official standards – and in EU)...              high priority scenarios
can be linked together
Content - Search                       Low      Show user interface and how to access
How to navigate through CMDR                    information.
to search for a concept, a variable,
a code


This document describes the “high” value scenarios that should be implemented within
the pilot being built for the CDISC Meta Data Repository (CMDR) and clarifies the needed
steps that are required from a business point of view to implement the pilot.




                                                                                     Page: 5 / 20
                                                                        CDISC MDR
                                                                        Pilot Specification




2. Scenarios Description
2.1.     Scientific/semantic domain in scope of pilot
In production, CMDR should be able to handle areas such as clinical trial safety & efficacy
domains , HEOR, epidemiology, non-clinical….. The capacity of CMDR to handle these
different areas is linked to the availability of an underlying information model/ontology of
concepts2.

The first releases of CMDR will be based on the BRIDG model which has a well defined
scope3. The full scope of BRIDG is far too big for the pilot, so we propose to narrow it
down to the following areas
 STDM safety domains: VS, AE and Concomitant medication
 One therapeutic area: CV – anti-hypertension4
 One validated rating scale such as the Hamilton Depression Scale


While populating the CMDR in the aforementioned area we need to ensure that there is
enough information / attributes populated in BRIDG – and in CMDR to demonstrate how
1. a physician could use the information in normal practice (e.g. for blood pressure you
   need to know whether it is systolic or diastolic, whether it was taken in a supine or
   standing position etc)
2. to "flip" seamlessly between horizontal and vertical5 storage forms

The pilot should be able to handle complex and simple concept. But we should avoid
defining complicated/composite variables (e.g. serum glucose at 2 hours post challenge
with 50mg sucrose), instead having several variables contain the constituent parts of this
(e.g. test, timing variable, challenge, challenge substance, challenge dose).
Complex/composite variables should be defined in a second stage; the same comment
applies for derived variables.



2
  An ontology is multi-axial organizational framework of concepts. BRIDG with binding to
controlled terminology can be considered as an ontology for protocol-driven research.
See as well BRS document for more detailed definition of concept and ontology.
3
  Protocol-driven research and its associated regulatory artifacts, i.e. the data, organization,
resources, rules, and processes involved in the formal assessment of the utility, impact, or other
pharmacological, physiological, or psychological effects of a drug, procedure, process, or device on a
human, animal, or other biologic subject or substance plus all associated regulatory artifacts required
for or derived from this effort
4
  This will allow to evaluate the added value of the HL7 CIC/Duke/CDISC CV “Disease” analysis
model - http://www.cdisc.org/standards/cardio/index.html - and to check on how we can
integrate BRIDG, controlled terminology and “Disease” analysis model like CV.



                                                                                              Page: 6 / 20
                                                                           CDISC MDR
                                                                           Pilot Specification




2.2.       Scenario 1. Import & data curation

2.2.1      Objectives
     Test, evaluate and refine process for building CMDR content from data dictionaries
      existing in different pharma companies/CROs
     Understand complexity of building a “ontology” of concept, starting from BRIDG with
      related code lists – understand the need for extension of BRIDG
     Evaluate workload & time frame for building the content of different therapeutic areas

2.2.2      Description

2.2.2.1 Scenario description
As a pre-requisite, the CMDR needs to be populated with the set of relevant concepts for
the area in scope. For this, the CMDR pilot team - with the support of NCI and CDISC
vocab team need to
 identify the part of BRIDG that is relevant for the area in scope
 for all the BRIDG attributes which are coded concepts (CD), agree on the code list to
    be used and implemented
 register the part of BRIDG and related code lists in pilot CMDR area in caDSR and EVS

Possibility 1.
A few companies extract from their respective data dictionaries an ODM file with the
agreed attributes for variables (see Section 4.2 Information Content in the BRS document),
for the variables belonging to the safety and efficacy domains in scope of the pilot. They
forward the resulting ODM6 file to the CMDR pilot team, with the agreed structure7.
The CMDR pilot team takes the ODM file – and ensure all the variables are registered
within the CMDR. Then they manually look at each variable and link it to the relevant
concept in CMDR. This is done for each of the variable from each company participating
to the pilot.
When all variables from all participating companies are linked to concepts, the CMDR
pilot team looks at all the variables from the different companies and then decide on one
(can be a new one) variable name as the “CMDR golden standard” variable. This variable is
marked as “golden standard” with a “synonym” link to the other variables with the same
meaning.


6
    Many companies do not use ODM at present so supplying an ODM file will take work
7
    In terms of structure,
        We need to clarify whether the structure should be horizontal or vertical. The company
           with a vertical structure will have to adapt if the horizontal structure is chosen, and vice-
           versa.
        Most pharma have similar structures for AEs.
        Companies should include all the variables/attributes associated with each standard (e.g.
           vitals).
           .

                                                                                                 Page: 7 / 20
                                                               CDISC MDR
                                                               Pilot Specification



Note:
 It is not the purpose of the pilot to document how a decision on a “golden standard
   variable” is taken. This is part of the governance stream.
 It is not the purpose of the pilot to decide what to do with the “synonym” variables.
   The governance stream may decide that, once the “golden standard variable” is
   defined, the industry legacy variables should be deleted. The possibility to have
   synonyms is however important for supporting different variables still existing across
   CDISC data standards

Possibility 2
(accelerated case – more input from companies; differernce with previous scenario
underlined).
A few companies extract from their respective data dictionaries an ODM file with the
agreed attributes for variables (see Section 4.2 Information Content in the BRS document),
for the variables belonging to the safety and efficacy domains in scope of the pilot. In
addition they also included in the ODM file, the link between the variables and the
concepts (need to check how to do this practically as this means that companies should
have access to the concepts defined in CMDR ). They forward the resulting ODM file to
the CMDR pilot team.
The CMDR pilot team takes the ODM file – and ensure all the variables are registered
within the CMDR, together with the link to the concept (no need to do a manual link !).
When all variables from all companies are linked to concepts, the CMDR pilot team is
looking at all the variables from the different companies and then decide on one (can be a
new one) variable name as the “CMDR golden standard” variable. This variable is marked
as “golden standard”




                                                                                     Page: 8 / 20
                                                                    CDISC MDR
                                                                    Pilot Specification




2.3.      Scenario 2. Export/download of variables in ODM

2.3.1     Objectives
     Show to pharma companies/CROs what could be extracted from the CMDR to
      build/maintain their local dictionary with the industry wide one (i.e. do we what we
      already do today but in a more efficient way as there will be much less maintenance
      work in each organization)
     Link variables simple concepts which allow to fully define the semantic of a variable,
      at the most atomic level.
          o Interpretation of a concept/related variable remains dependent of the context
              of use
          o Potential context of use – i.e links across concepts – are not solved here

2.3.2     Description
Some companies may be interested in CMDR for downloading the description of variables
- grouped into forms - for usage in study management and reporting8. There is no interest
in the ontology of concepts and ISO abstract data type (see Section Error! Reference
source not found.4. Error! Reference source not found.Company specific MDR in
ODM format).

All information will be downloaded in an ODM format (see Section 4.2. Description of
expected ODM format for downloading CMDR content). By getting input from the CMDR
into ODM, companies are sure that the variables (and related forms) are unique,
unambiguous, and valid across the industry but the complexity to ensure this is hidden.
However ODM will not allow to transfer information
 containing relationship across concepts/forms and items group, that may be needed to
    search for precise definition and context of variable,
 or ISO abstract data type that may be needed for building HL7 compliant message




8
    Company may have a MDR which is ODM compliant – but this is not the case for all companies

                                                                                          Page: 9 / 20
                                                              CDISC MDR
                                                              Pilot Specification




2.4. Scenario 3. Export/download of concepts in ODM

2.4.1   Objectives
       Show what is the content of the CMDR in terms of ontology/concept and how they
        relate to variables; this would help end user to understand which variable is used
        in which concepts – explaining all contexts of use of a variable
       Show how concepts could be used in building a protocol (would require link with a
        tool such as Medidate ???)
       ?????


2.4.2   Description
Display in graphical form
    Concepts related to each domain
    How they are related to each other
    Which are the related variables


(Ed Seguine ??)




                                                                                    Page: 10 / 20
                                                                 CDISC MDR
                                                                 Pilot Specification




3. Action plan to implement scenarios
3.1.    Pre-requisite for all scenarios
What                                          When      Proposed             Expected Total
                                                        participants         workload
Set up pilot area for CMDR pilot in caDSR     Dec       D Iberson-Hurst      ?
                                                        (CDISC)
                                                        D. Warzel (NCI)
Confirm scientific area for pilot             Dec       BRS substream        NA
(proposed: 3 STDM domain + CV_
Identify the part of BRIDG that is relevant   Dec       D. Wold (GSK)        2 days
for the area in scope                                   J. Evans (CDISC)
for all the BRIDG attributes in scope and     Dec-Jan   Coord: B. Kisler     A LOT !
which are coded concepts (CD), agree on                 (CDISC) + NCI ?
the code list to be used and implemented
register the part of BRIDG and related        Dec-Jan                        ???
code lists in pilot CMDR area in caDSR
and EVS

Agree on ODM content/attributes for                     BRS substream
downloading variables
Define & Test format/ provide template
for ODM variable to all participating
companies – provide short instructions on
how to fill
(note: this ODM template should bi-
directional i.e. support
 uploading of existing legacy variables
    to CMDR and
 downloading of “golden standard”
    variable + related concept to
    companies/CROs)

Agree on ODM content for downloading
concepts (including their relationships
and the link with variables)
Test format/ provide template for ODM
concept to all participating companies –
provide short instructions on how to fill




                                                                                       Page: 11 / 20
                                                                CDISC MDR
                                                                Pilot Specification



3.2.    Scenario 1. Import & data standard curation
What                                     When            Proposed           Expected Total
                                                         participants       workload
Possibility 1 (manual linking of variables to concept at CMDR level)
Download content into CMDR
Link each variable with concept -
manually
Define “golden standard” variable and
link with others as synonyms
Evaluate workload for company staff and
for CMDR staff
Possibility 2 (manual linking of variables to concept at company level)
Each pharma company to extract an ODM                    GSK ?
message for the 4 areas identified (VS, AE,
ConconMed, CV)
 Extract variables
 Check on CMDR to identify relevant
     concept; add manually the link into
     ODM message
Download content into CMDR
Define “golden standard” variable and
link with others as synonyms
Evaluate workload for company staff and
for CMDR staff
Consolidation
Compare workload between possibility 1
and 2


3.3.    Scenario 2. Export/download of variables in ODM
What                                     When          Proposed             Expected
                                                       participants         Total
                                                                            workload




3.4.    Scenario 3. Export/download of concepts in ODM
What                                     When          Proposed             Expected
                                                       participants         Total
                                                                            workload




                                                                                      Page: 12 / 20
CDISC MDR
Pilot Specification




                      Page: 13 / 20
                                                                                                           CDISC MDR
                                                                                                           Pilot Specification




4. Appendix. Company specific MDR in ODM format
4.1.   Description of company specific MDR
Lilly is building a data standard library in an ODM compliant format. The library contains 493 Forms, 1229 Variable Groups, 18434
Variables, 1994 CodeLists.
Figure 1 below shows the Lilly library, opened on the list of forms.




                                                                                Page: 14 / 20
                                                                                                             CDISC MDR
                                                                                                             Pilot Specification




Figure 2 shows how the library is used in the context of a study and how forms would be added within a specific studies.
The top right part of the figure below shows the list of forms already used within the study. The bottom right part of the figure shows
additional forms – present in the Lilly library and synchronized with the CMDR – that can be added to the study by selecting them .




                                                                                  Page: 15 / 20
                                                                                                              CDISC MDR
                                                                                                              Pilot Specification




The figures shows – on the right hand side – the forms selected previously being added to the set of forms to be used for a specific
study.




                                                                                   Page: 16 / 20
                                                                                                       CDISC MDR
                                                                                                       Pilot Specification




4.2.   Description of expected ODM format for downloading CMDR content
The Lilly library needs to be synchronized with the CMDR. For this it requires a download from the CMDR in an ODM format.



                                                                              Page: 17 / 20
                                                                                                         CDISC MDR
                                                                                                         Pilot Specification



The basic ODM XML hierarchy is:
    Form
           o ItemGroup
                  Item (e.g. Variable)
                        CodeList

In the context of CMDR
     Form and ItemGroup are represented by concepts
     Item are represented by variables
     CodeList are code list
The attributes defined in CMDR for Concepts, variables and codelist need to be mapped the ODM attributes

ODM attributes                     CMDR attributes              Comments
FormDef.Name                       ConceptLongName
ItemGroupDef.SASDatasetName        ConceptShortName
ItemGroupDef.Domain                ????                         Relates to an SDTM domain – it will be possible to retrieve this from
                                                                CMDR, assuming that forms (which are concepts) are linked to
                                                                SDTM domains (which are also concepts)
ItemDef.Name                       VariableLongName
ItemDef.DataType                   VariableDataType             Data types in CMDR at variables level are the ISO primitive data
                                                                types, not the ODM data types
ItemDef.Length                VariableLength
ItemDef.SASFieldName          VariableShortName
Question                      VariableQuestion
CodeListRef.CodeListOID       CodeSystemOID
CodeList.OID                  CodeSystemOID
CodeList.Name                 CodeSystemName
CodeLisItem.CodedValue        code                        This is not a CMDR attribute of a concept or variable, but an
CodeListDecode                displayName                 attribute of CD (concept descriptor – an ISO abstract data type)
To download ODM XML from the CMDR for the Hamilton Depression Scale we should have something like this:



                                                                              Page: 18 / 20
                                                                                                 CDISC MDR
                                                                                                 Pilot Specification




<FormDef OID="F.HMD1001" Name="Hamilton Depression Scale">
      <ItemGroupRef ItemGroupOID="IG.HMD1001" Mandatory="Yes"/>
             Etc.
</FormDef>

      <ItemGroupDef OID="IG.HMD1001" Name="Hamilton Depression Scale" SASDatasetName="HAMD" Domain="QS">
             <ItemRef ItemOID="I.HMDASR" Mandatory="No"/>
             <ItemRef ItemOID="I.HMDS1" Mandatory="No"/>
                    Etc.
      </ItemGroupDef>

             <ItemDef OID="I.HMDASR" Name="HAM-D Assessor" DataType="integer" Length="8" SASFieldName="HMDASR">
                    <Question>
                           <TranslatedText>HAM-D Assessor</TranslatedText>
                    </Question>
                    <CodeListRef CodeListOID="CL.MSTR_ASR"/>
             </ItemDef>

             <ItemDef OID="I.HMDS1" Name="HAM-D Item Score 1" DataType="integer" Length="8" SASFieldName="HMDS1">
                    <Question>
                           <TranslatedText>Depressed Mood: (Sadness, hopeless, helpless, worthless).</TranslatedText>
                    </Question>
                    <CodeListRef CodeListOID="CL.MSTR_HAMDSDESC1"/>
             </ItemDef>
                           Etc.

             <CodeList OID="CL.MSTR_HAMDSDESC1" Name="Master view of HAMD Item SDESC 1" DataType="integer">
                    <CodeListItem CodedValue="0">
                           <Decode>
                           <TranslatedText>Absent</TranslatedText>
                           </Decode>
                    </CodeListItem>
                    <CodeListItem CodedValue="1">



                                                                       Page: 19 / 20
                                                                                                           CDISC MDR
                                                                                                           Pilot Specification



                              <Decode>
                              <TranslatedText>These feeling states indicated only on questioning</TranslatedText>
                              </Decode>
                      </CodeListItem>
                      <CodeListItem CodedValue="2">
                              <Decode>
                              <TranslatedText>These feeling states spontaneously reported verbally</TranslatedText>
                              </Decode>
                      </CodeListItem>
                      <CodeListItem CodedValue="3">
                              <Decode>
                              <TranslatedText>Communicates feeling states non verbally, i.e., through facial expressions,
posture…weep</TranslatedText>
                              </Decode>
                      </CodeListItem>
                      <CodeListItem CodedValue="4">

                            <Decode>
                            <TranslatedText>Patient reports VIRTUALLY ONLY these feeling states in his
…communication</TranslatedText>
                            </Decode>
                     </CodeListItem>
             </CodeList>
                            Etc.




                                                                              Page: 20 / 20

								
To top