Presentation is loading. Please wait.

Presentation is loading. Please wait.

Semantic Metadata Registry/Repository

Similar presentations

Presentation on theme: "Semantic Metadata Registry/Repository"— Presentation transcript:

1 Semantic Metadata Registry/Repository

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


Download ppt "Semantic Metadata Registry/Repository"

Similar presentations

Ads by Google