1. Semantic Metadata Registry/Repository
SRDC

2. Common Data Elements… Common Data Element (CDE) Data vs. Metadata
common definitions and structures so that information can be exchanged across different domains/applications/studies
Data vs. Metadata
“John”
Patient Name
“Istanbul”
What does it mean?
Patient – City of Residence
Patient – City of Birth
Biggest city of Turkey
...

3. Semantic Meta-data Registry
SALUS Project
Semantic Meta-data Registry
CDE Repository

4. SALUS Common Data Elements
The total number of the identified CDEs is 199
Data Element
Name
Description
Patient.ID.II
Identifier of the patient
Patient.Title.String
Title/prefix of the patient
Patient.GivenName.String
Given name of the patient
Patient.FamilyName.String
Family name of the patient
Patient.Gender.CD
Gender of the patient
Allergy.AdverseEventType.CD
Coded type of the allergy / intolerance / adverse event (e.g. drug allergy, food intolerance)
Allergy.TimeInterval.IVLTS
Effective time interval of the allergy / intolerance / adverse event
Allergy.Product.CD
Product (i.e. substance) that causes the allergy / intolerance / adverse event (e.g. egg protein, dust, nifedipine)
Allergy.Reaction.Condition
The condition which occur as a reaction to the allergy / intolerance / adverse event; can be any condition

5. SALUS Semantic MDR
The design and implementation of CDE Repository go beyond the requirements of SALUS interoperability framework
Federated Semantic Metadata Repository
During the elicitation of SALUS CDEs
several other common data element models have been analysed
one of the major deficiencies is that most of them are published through PDF documents or spread sheets
not accessible in a machine-processable way
HITSP C154, C32
FHIM CIM
S&I CEDD
CDISC CDASH, SDTM
BRIDG CDM
Intermountain Healthcare CEM
Mini-Sentinel CDM
i2b2
it is not practical to expect all of these
diverse initiatives and projects to stick to
the same common model, and to
use the same set of CDE
HITSP: Health Information Technology Standards Panel
FHIM: Federal Health Information Model – Computationally Independent Model
S&I: Standards and Interoperability – Clinical Element Data Dictionary
CDISC: Clinical Data Interchange Standards Consortium – Clinical Data Acquisition Standards Harmonization, Study Data Tabulation Model
BRIDG: The Biomedical Research Integrated Domain Group – Domain Analysis Model
Intermountain Healthcare CEM: Clinical Element Models
Mini-Sentinel CDM: Common Data Model

6. ISO/IEC 11179
Family of specifications (6 parts) for metadata registries to increase the interoperability of applications with the use of data elements
A relational metamodel
Generic: any data element model can be represented through regardless of the level of granularity

7. Semantic Metadata Registry (MDR)
Metadata for Semantic Interoperability
annotate the information models of different systems
with the same set of data elements residing in the metadata registries
early approach: bottom-up
takes root from several other disciplines like linguistics, compilers etc…
Patient
Name
Surname
Birth Date
Sex
Firstname
Date of Birth
Gender
First name
Last name
MDR
ISO/IEC 11179
Any other Metadata
Metadata is very important. Even in the same company, two different applications use different metadata which creates data interoperability problems later during integration.

8. Federated Semantic MDRs
Maintain & Manage
CDEs
the relations between CDEs
the components of CDEs
the relations between the components of CDEs
Different CDEs from different Content Models
their relations and mappings are managed semantically
A set of CDEs with lots of relations – Semantic Resource Set
The relations can be through the LOD cloud
The relations may point to native representations of the Content Models
Extraction Specification
IHE DEX Profile

9. Rest Services for each MDR:
SPARQL Endpoint
CDE Endpoint
CDE search
Retrieve Semantic Links
Retrieve Extraction Specifications
Bioportal
LOINC
SNOMED-CT
ICD-10 …
WHOART
Terminology Servers
HITSP
SKOS: closeMatch
FDA
Semantic MDR
WHO
CDISC SHARE
SKOS: closeMatch
SKOS:exactMatch
OMOP
Semantic MDR
Legend: Federated semantic MDR framework. Within the LOD cloud, each MDR maintains a set of CDEs together with the corresponding components and relations. The CDEs are linked to CDEs of other MDRs through KOSs and annotated with terminology systems.

10. CDE
classifiedBy CS
name
CCD/ICSR
type
ExtractionSpecification
Result.value.PQ
containing OC
Result
CSI
type
XPATH
value
Xpath Expression
= ' '] /cda:value
classifiedBy
LOD CS
name
SNOMED-CT
type
BioPortal
containing
CSI
type
owl:sameAs
value
URI
HITSP Semantic MDR
LOD
CDE
Legend: Annotations and links of a CDE and its OC inside a semantic MDR. The OC is annotated with a concept from SNOMED-CT which is maintained under BioPortal through owl:sameAs property. The CDE has an “Extraction Specification” which is an XPATH expression pointing the exact place of the CDE in HL7 CCD models. These annotations and links are modeled through Classification Scheme and Classification Scheme Item elements of ISO/IEC model.
LB.LBORRES.Char is a CDE residing in the CDISC Semantic MDR and represents an item from the SDTM vocabulary. It links to a CDE in the HITSP Semantic MDR as show in the figure.
Result.Value.PQ is a CDE which is classified by a CSI of type XPATH. This CSI is from a CS whose type is “ExtractionSpecification” and it goes to CCD/ICSR. This means the CDE has a corresponding Xpath expression which gives the exact path of the element from CCD, and this element is the direct mapping of the CDE to the element which can be extracted by the given Xpath expression. As given in the figure, the Xpath expression gives the CCD template id for the mapped entry element. A CDE may map to more than one element which can be understood from the given Xpath expression. That means, the extraction specification returns a selection of corresponding CCD element which are linked from the CDE.
Result.value.PQ has “Result” as its Object Class. Semantic MDR allows linking components of CDEs. Hence, in this example, the Result is classified by a CSI which comes from a CS which represents SNOMED-CT. As the type of the CS indicates, it uses the BioPortal ontology for the semantics of the links. The corresponding CSI indicates the type of the link (same_as) and the URI of the resource. BioPortal published ontological representations of several terminology systems such as SNOMED-CT, ICD-10, LOINC… These interactions are in compliance to LOD principles since each resource has a unique, dereferenceable URI, and the interactions return appropriate RDF representations of the resources.
LB.LBORRES.Char

11. BRIDG Semantic MDR
DEC AE OC
AEREL P
Text VD
CDE
classifiedBy CS
name
BRIDG
type
SKOS
CDE OC P
CDE
containing
LOD OC P
classifiedBy
CDE
CSI
type
skos:exactMatch
value
Context{…;URI;…}
CSI
type
skos:closeMatch
value
Context{…;URI;…} …
Context = {AdverseEvent > AdverseEventCausalRelationship > EvaluatedActivityRelationship; WHERE EvaluatedActivityRelationship > PerformedActivity > PlannedActivity > DefinedActivity.nameCode=“administer treatment”}
CSI
type
skos:exactMatch
value
Context{…;URI;…}
CDISC Semantic MDR
Legend: The components of a CDE together with their classifications for the LD links to other CDEs and components residing in a different semantic MDR. The CDE, AE.AEREL.Text, has a skos:exactMatch relation with the CDE, AdverseEventRelation, in the semantic MDR which holds the BRIDG CDEs. If needed, CDE mappings to other CDEs can be given through a Context in which some pre-conditions and rules can be specified.
AE.AEREL.Text is a CDE in the Semantic MDR of CDISC where
AE is the Object Class which means domain of Adverse Events
AEREL is the Property which means the relation indicating whether the study treatment had a causal effect on the adverse event or not.
Text is the Value Domain in which the data type is a character string
Each component of the CDE can be classified by a Classification Scheme Item which resides in a Classification Scheme. In this example, CDE of CDISC are related to CDEs of BRIDG by their classification type (i.e. skos:closeMatch) and value (i.e. a Context which includes the URI of the corresponding CDE). Since ISO/IEC model allows re-use of CDE components, they can also be linked to their corresponding components in other MDRs.
A Context is retrieved from the value of a Classification Scheme Item. It has a Semantic MDR specific format to be able to reflect all semantics in a link. For the example in this figure, the first part of the Context points to the place of the linked CDE in the remote MDR. Content model specifications do not only maintain the CDEs as a data dictionary, but also exhibits a data model which can be reflected as a UML diagram or a database schema or an XML schema or even in tables in a text document. The exact place of the CDEs can be specified in this field of the Context. The second part is the dereferencable URI of the linked CDE (or the OC, or any other component). The third and the last part of the Context is the condition which applies on the link. That is, the link is applicable only the precondition is supplied. The format of the precondition is the same as BRIDG’s condition format which resembles to SQL.

12. Design & Implementation
JENA RDF/OWL API