a demo of an initial prototype of project idea

A demo of an initial prototype of project idea

Mustafa Yuksel & Gokce B. Laleci, SRDC

SALUS Technical Kickoff Meeting 2

Motivation

April 17-18, 2012

Currently, the clinical research and the clinical care domains are quite disconnected because each use different standards and terminology systems. In contrast to CDISC standards used in the clinical research domain, in the

clinical care domain, the most widely used content and messaging standards are by HL7

The terminology systems are quite different as well: While MedDRA, WHODD and CDISC Terminology are commonly used in the clinical research domain; the prominent terminology systems in clinical care domain include SNOMED CT, LOINC, ICD-9 and ICD-10

The available integration efforts are mostly proprietary, custom developed for a specific use-case and depend on hard-coded n x n mappings among standards

For example, the Electronic Data Capture (EDC) systems are usually not connected to the EHR systems that are used by the health care providers. The clinicians have to manually copy the results of therapeutic procedures and

examinations from an EHR system into the Case Report Form (CRF), which causes errors and work disruption as well as delays in reporting data.


Visionary Scenario A new Calcium Channel Blocker is marketed after a successful clinical trial

period The regulatory body receives Adverse Event reports indicating that this

new drug causes swelling of legs The regulatory body decides to conduct a more extended post market

safety study (or asks the Pharmaceutical Company to do so) Prepares the Study Protocol in CDISC SDM

Eligibility criteria: Patients who have recently been treated with this new Calcium Channel Blocker

Collect all of the other symptoms, diagnoses, allergies, medications of this patient in the first visit

This protocol definition is sent to the health care providers that are in SALUS cslinical research community Patient history documents conforming to the protocol definition, and in different schemas

such as HL7 CDA and CEN EN 13606 are sent by the hospitals to the regulatory body This patient histories in CDA and 13606 are translated to BRIDG Model Form Manager processes the Study Design, identifies the items requested in CRF Forms

from their annotation in CDASH The patient history in BRIDG is queried through the predefined queries defined for each

CDASH variable (they can be used for semi-autmatically filling in CRF forms)

April 17-18, 2012


Visionary Scenario (continued) After collecting significant data from some patients, the

regulatory body prepares the statistical analysis data by semantically querying the collected data represented in BRIDG Model Number of patients who have experienced edema in legs (represented

through MedDRA term 10014239) have also Condition of heart failure (represented through MedDRA term 10019279) Condition of primary pulmonary hypertension (represented through MedDRA

term 10036727) Has already been treated through a vasodilating agent (represented

through SNOMEDCT term 58944007) Participating health care providers code observations through

ICD-9, SNOMED CT terms, record adverse events through Who-Art, and record the medications provided through RxNorm

After the analysis, it has been clarified that the adverse event incidents are mostly related with the underlying condition or current treatment of the patients…

April 17-18, 2012


Exploiting the Initial SALUS Semantic Framework

We have envisioned two use cases to1. automatically fill in eCRFs2. facilitate safety studies on EHR

systems

April 17-18, 2012


The Components of the initial Demo

April 17-18, 2012

i. the BRIDG DAM ontology expressed in RDF as the core ontology hosted in a knowledge base

We have developed the RDF representation of the BRIDG DAM v3.0.3 to be used as the core ontology to make the common shared semantics available in a formal, machine processable form.

ii. tools for semantic lifting of the content standards harmonized by the BRIDG initiative including HL7 RIM based models, CDISC ODM based models and for aligning these semantic models with the core ontology in the knowledge base

iii. tools for importing semantic representations of the terminology systems and biomedical ontologies as well as aligning these models with the core ontology

iv. tools to import clinical documents/messages to the SALUS knowledge base by automatically translating them to the instances of the core ontology

v. a library of SPARQL queries to retrieve clinical data corresponding to the CDASH data sets from the knowledge base

vi. tools for semantically mediating the documents/messages represented in different clinical research and care standards to one another

SALUS Technical Kickoff Meeting 7April 17-18, 2012


(A) BRIDG DAM as the common “model of meaning”

April 17-18, 2012

The BRIDG DAM is an implementation independent UML model to represent common shared semantics of regulated clinical research studies which may have different implementations In 2003, CDISC, and HL7 signed a 2-year-old Memorandum of Understanding

(MoU) to work collaboratively on the data exchange standards in domains that are of interest to both organizations and to create a Domain Analysis Model (DAM) as an implementation independent model of the shared semantics Later NCI through their CaBIG Project, and FDA joined the group

A reverse engineering effort to create the DAM is initiated From the already existing HL7 RCRIM messages From the CDISC CDASH, SDTM Data sets and ODM Models

BRID DAM is composed of five sub-domains: Protocol Representation, Study Conduct, Adverse Event, Regulatory and Common

Implementation independent UML Model CDISC SDM and HL7 Study Design RMIM are both implementations of Protocol

Representation Sub Domain Hence, it is the best alternative to be the starting point for core of our

Semantic Framework


Sample UML Model from BRIDG Study Conduct Sub Domain

class View CM: Comm...

Activity

+ identifi er: II+ reasonCode: DSET<CD>+ comment: ST

constraints{Is Partici pated In By Quali fier}

BiologicEntity

+ name: DSET<EN>+ admini strativeGenderCode: CD+ birthCountryCode: CD+ birthOrder: INT.POS+ birthDate: TS.DATETIME+ deathDate: TS.DATETIME+ deathIndicator: BL+ actualIndicator: BL

View Description: The Common sub-domain represents the semantics that are common to all (or most) of the other sub-domains. For example, it includes semantics for such things as people, organizations, places and materials.

BiologicEntityGroup

+ name: EN.TN+ typeCode: CD+ quantity: INT.NONNEG+ actualIndicator: BL

BiologicEntityIdentifier

+ identifi er: II+ typeCode: CD+ effectiveDateRange:

IVL<TS.DATETIME>

BiologicEntityPart

+ anatomicSiteCode: CD+ anatomicSiteLateralityCode: CD

Document

+ typeCode: CD

DocumentAuthor

constraints{Is a Functi on Performed By Qual ifier}{Study Author Performed By Qual ifier}{Is a Functi on Performed By Exclusi ve Or}

DocumentIdentifier

+ identifi er: II+ typeCode: CD+ primaryIndicator: BL

constraints{Is Assigned By Exclusive Or}

ReportReceiv er

+ receivedIndicator: BL+ receivedDate:

TS.DATETIME

constraints{Is a Function Performed By Exclusi ve Or}

DocumentVersionRelationship

+ typeCode: CD+ pri orityNumber: INT.NONNEG

AssociatedBiologicEntity

+ typeCode: DSET<CD>

Ex perimentalUnit

+ identifi er: DSET<II>+ subgroupCode: CD+ statusCode: CD+ statusDate: TS.DATETIME

constraints{Is a Function Performed By Exclusive Or}

Animal

+ speciesCode: CD+ breedCode: CD+ strain: ST+ description: ED+ reproductiveOrgansPresentIndicator: BL::Biologi cEntity+ name: DSET<EN>+ admini strativeGenderCode: CD+ birthCountryCode: CD+ birthOrder: INT.POS+ birthDate: TS.DATETIME+ deathDate: TS.DATETIME+ deathIndicator: BL+ actualIndicator: BL

AdministrativeMemberCRA

AdministrativeMemberPI

Biologic

+ riskCode: CD+ handlingCode: CD+ stabilityDurati on:

IVL<TS.DATETIME>::Product+ codeModi fiedText: ST+ typeCode: CD+ classCode: DSET<CD>+ lotNumberText: ST.SIMPLE+ expirationDate: TS.DATE.FULL+ pre1938Indi cator: BL::Material+ code: CD+ formCode: CD+ descripti on: ST+ actualIndi cator: BL+ effectiveDateRange:

IVL<TS.DATETIME>

ResearchStaff

+ identif ier: II+ jobTi tle: ST+ postalAddress: AD+ telecomAddress: BAG<TEL>+ effectiveDateRange: IVL<TS.DATETIME>

constraints{ Person-ResearchOrganization Pair Unique}

Cooperativ eGroup

Cosmeti c

+ stabil ityDuration: IVL<TS.DATETIME>

::Product+ codeModifiedText: ST+ typeCode: CD+ classCode: DSET<CD>+ lotNumberText:

ST.SIMPLE+ expi rationDate:

TS.DATE.FULL+ pre1938Indicator: BL::Material+ code: CD+ formCode: CD+ description: ST+ actualIndicator: BL+ effectiveDateRange:

IVL<TS.DATETIME>

Device

+ reprocessedDeviceCode: CD+/ age: PQ.TIME+ manufactureDate: TS.DATETIME+ returnedToReprocessorDate:

TS.DATETIME+ availableForEvaluationIndi cator: BL+ overTheCounterProductIndi cator: BL+ singleUseDeviceIndicator: BL+ riskCode: CD+ handli ngCode: CD::Product+ codeModifi edText: ST+ typeCode: CD+ classCode: DSET<CD>+ lotNumberText: ST.SIMPLE+ expirationDate: TS.DATE.FULL+ pre1938Indicator: BL::Material+ code: CD+ formCode: CD+ description: ST+ actualIndicator: BL+ effectiveDateRange: IVL<TS.DATETIME>

Distributor

Drug

+ riskCode: CD+ handlingCode: CD+ stabil ityDuration:

IVL<TS.DATETIME>::Product+ codeModifi edText: ST+ typeCode: CD+ classCode: DSET<CD>+ lotNumberText:

ST.SIMPLE+ expi rationDate:


IVL<TS.DATETIME>

FoodProduct

+ stabilityDurati on: IVL<TS.DATETIME>

::Product+ codeModi fiedText: ST+ typeCode: CD+ classCode: DSET<CD>+ lotNumberText:

ST.SIMPLE+ expirationDate:

TS.DATE.FULL+ pre1938Indi cator: BL::Material+ code: CD+ formCode: CD+ descripti on: ST+ actualIndi cator: BL+ effectiveDateRange:

IVL<TS.DATETIME>

HealthcareFacility

+ identifier: II+ postalAddress: AD+ telecomAddress: BAG<TEL>+ effectiveDateRange:

IVL<TS.DATETIME>

HealthcareProv ider

+ identifi er: II+ postalAddress: AD+ telecomAddress: BAG<TEL>+ effectiveDateRange: IVL<TS.DATETIME>

HealthcareProv iderGroup

+ effectiveDateRange: IVL<TS.DATETIME>

HealthcareProv iderGroupMember


Processor

ProcessingSite

Material

+ code: CD+ formCode: CD+ description: ST+ actualIndicator: BL+ effectiveDateRange:

IVL<TS.DATETIME>

CooperativeGroupMember

Organization

+ name: DSET<EN.ON>+ typeCode: CD+ description: ST+ postalAddress: AD+ telecomAddress: BAG<TEL>+ actualIndicator: BL

Person

+ initi als: ST+ raceCode: DSET<CD>+ ethnicGroupCode: DSET<CD>+ maritalStatusCode: CD+ educationLevelCode: CD+ postalAddress: AD+ telecomAddress: BAG<TEL>+ primaryOccupati onCode: CD+ occupationDateRange: IVL<TS.DATE>::Biol ogicEntity+ name: DSET<EN>+ admini strativeGenderCode: CD+ birthCountryCode: CD+ birthOrder: INT.POS+ birthDate: TS.DATETIME+ deathDate: TS.DATETIME+ deathIndicator: BL+ actualIndicator: BL

ReportVersion

+ communicationModeCode: CD+ dueDate: TS.DATETIME+ physicianSignOffIndi cator: BL::DocumentVersion+ offici alTitle: ST+ text: ED+ keywordCode: DSET<CD>+ keywordText: DSET<ST>+ numberText: ST.SIMPLE+ revisionReason: ST+/ uniformResourceLocator: URL+ bibl iographi cDesignati on: ST+ date: TS.DATETIME

TreatingSite

constraints{Is a Member Of Exclusive Or}

QualifiedPerson

+ identifi er: II+ typeCode: CD+ certif icateLicenseText: ST+ effectiveDateRange:

IVL<TS.DATETIME>

OrganizationRelationship

+ typeCode: CD+ effectiveDateRange:

IVL<TS.DATETIME>

OrganizationalContac t

+ titl e: ST+ typeCode: DSET<CD>+ postalAddress: BAG<AD>+ telecomAddress: BAG<TEL>+ effectiveDateRange:

IVL<TS.DATETIME>+ primaryIndi cator: BL

OversightCommittee


IVL<TS.DATETIME>

Performe r

+ identifier: II+ typeCode: CD+ postalAddress: AD+ telecomAddress: BAG<TEL>+ effectiveDateRange:

IVL<TS.DATETIME>


Plac e

+ identifi er: DSET<II>+ name: EN.TN+ typeCode: CD+ code: CD+ physicalAddress: AD

constraints{physicalAddress Qualifier}

Product

+ codeModifi edText: ST+ typeCode: CD+ classCode: DSET<CD>+ lotNumberText: ST.SIMPLE+ expi rationDate: TS.DATE.FULL+ pre1938Indicator: BL::Material+ code: CD+ formCode: CD+ description: ST+ actualIndicator: BL+ effectiveDateRange: IVL<TS.DATETIME>

constraints{Distributor Quali fier}{Processor Qualif ier}{ProcessingSite Qualifier}

ProductGroup

+ identifi er: II+ quantity: INT.NONNEG+ actualIndicator: BL

StudyRegistry

+ name: ST+ acronym: ST

ResearchOrganization


IVL<TS.DATETIME>

ResourceProv ider

+ identifier: II+ effectiveDateRange:

IVL<TS.DATETIME>


Subj ect

constraints{Is a Functi on Performed By Exclusi ve Or}

StudySubject

+ paymentMethodCode: CD+ statusCode: CD+ statusDate: TS.DATETIME+ confi dentiali tyIndicator: BL

Pack age

+ capTypeCode: CD+ capacityQuantity: PQ+ handlingCode: CD::P roduct+ codeModifiedText: ST+ typeCode: CD+ classCode: DSET<CD>+ lotNumberText:

ST.SIMPLE+ expirationDate:


IVL<TS.DATETIME>

Study Conduct Sub-Domain::StudySite

+ identifier: II+ leadIndi cator: BL+ targetAccrualNumberRange:

URG<INT.NONNEG>+ accrualStatusCode: CD+ accrualStatusDate:

TS.DATETIME+ plannedDuration: PQ.TIME+ dateRange:

IVL<TS.DATETIME>+ statusCode: CD+ statusDate: TS.DATETIME


DocumentVersionWorkflow Status

+ code: CD+ date: TS.DATE.FULL+ comment: ST

ProductRelationship

+ identif ier: II+ typeCode: CD+ quanti ty: RTO<PQ,PQ>+ confidentialityCode:

DSET<CD>+ activeIngredientIndicator: BL+ effectiveDateRange:

IVL<TS.DATETIME>

Regulatory Sub-Domain::

Ov ersightAuthority

Adverse Event Sub-Domain

Common Sub-Domain

Protocol Representation Sub-Domain

Regulatory Sub-Domain

Study Conduct Sub-Domain

Legend

Subj ectIdentifier

+ identif ier: II+ typeCode: CD+ effectiveDateRange:

IVL<TS.DATETIME>+ primaryIndi cator: BL

constraints{Is Assigned By Exclusive Or}

OrganizationIdentifie r

+ identif ier: II+ typeCode: CD+ primaryIndi cator: BL

constraints{Is Assigned By ExclusiveOr}

NotificationReceiv er

constraints{Is a Functi on Performed By Exclusive Or}

DocumentVersion

+ offici alTitle: ST+ text: ED+ keywordCode: DSET<CD>+ keywordText: DSET<ST>+ numberText: ST.SIMPLE+ revisionReason: ST+/ uniformResourceLocator: URL+ bibl iographi cDesignati on: ST+ date: TS.DATETIME

Manufacturer

Reprocessor

MaterialIdentifier

+ identif ier: II+ typeCode: CD

MaterialName

+ name: EN.TN+ typeCode: CD

SystemOfRecord

+ name: ST

ReportSubmitter

ProcessedProduct

+ identifier: II

Serv iceDeliv eryLocation

+ code: CD+ postalAddress:

BAG<AD>+ telecomAddress:

BAG<TEL>

Regulatory Sub-Domain::RegulatoryAuthority

+ jurisdictionAuthorityCode: CD


0..1

is a functionperformed by

{functions as}

1

0..*ov ersees

{is overseen by}

0..*

0..*


{functions as}

0..1

0..*

is assigned by

{assigns}

0..1

0..*

is a function performed by

{functions as}

0..1

0..1


{functions as}

0..1

0..*

is credentialed by

{credentials}

1

0..*


{functions as}

1

0..*

has as source

{is the source for}

1

0..1


{functions as}

1

0..*

has as target

{is the targetfor}

1

+identifyi ng 0..*

identif ies

{is identified by}

+identifi ed 1

0..1


{functions as}

1

0..*

is assigned by

{assigns}

0..1

0..*

produces

{is produced by} 1

+assigned 0..*

is assigned by

{assigns}

+assigning 0..1

0..*

handles communicati on for

{has communicationshandled by}

1

0..*


{functions as}

0..1

0..*

is managed by

{manages}

1

0..*


{functions as}

0..1

0..*


{functions as}

0..1

0..*

is assigned by

{assigns}0..1

0..*

identif ies

{is identified by}

1

1.. *

name s

{is named by}

1

0..*

is qualified in

{is the location inwhich thequalifi cation isgranted for}

0..1

0..*


{functions as}

0..1

+target

0..*

has as source

{is thesource for}

+source

1

0..*

is located at

{is location for}

0..1

0..*is del ivery location for

{receives deli very at}0..1

0..*

is the location for

{has jurisdicti on over}

0..1

0..*

is approv ed by

{approves}0..1

0..*

is assigned by

{assigns} 0..1

0..*

identif ies

{is identified by}1

0..*

st aff s

{is staffed by }

1

1.. *

is produced by

{produces}

1

0..*

receives{is received by}

10..*


{functions as}0..1

+sourc e

0..*

has as target

{is the targetfor}

+target

1

0..*


{functions as} 0..1

0..*

gr oups

{isgroupedby}

1.. *

0..*

fabricates

{is fabricated by} 1.. *

0..*

manufacturesfor

{manufactures at}

1.. *

0..*


{functions as}1

+contained0..*

{contains} iscontained i n

+containing0..1

0..*


{functions as}1

0..*


{functions as}0..1

0..1


{functions as}

0..1

0..*


{functions as}

1

0..*

is a function performed by{functions as}

1

0..*


{functions as}

1

0..*


{functions as}0..1

1.. *

is amember of

{has as amember}

0..1

0..*


{functions as}

1

0..*

is a member of

{has as a member}

0..1

0..*

is a member of

{has as a member}

1

0..*

is credentialed by

{credentials}

1

0..1


{functions as}

1

0..*


{functions as}0..1

0..*

is assigned by

{assigns}

1

0..*


{functions as}0..1

0..*

identifi es

{is identified by}1

1.. *

belongs to

{contains}1

0..*


{functions as}0..1

0..1


{functions as}

1

0..*

is part of

{has}1

0..*


{functions as}0..1

+performed

0..*


{functions as}

+performing

1

+scoped

0..*

is scoped by

{scopes}

+scoping

1

0..*


{functions as}

1

1

st aff s

{is staffed by}

1

1

staff s

{is staffed by}

1

0..*


{functions as}

1

0..*

performs

{is performed by}

1.. *

0..*

is participated in by

{participates in}

0..10..*

gr oups

{isgroupedby}

1.. *

+target

0..*

has as source

{is the source for}

+source

1

0..*


{functions as}0..1

0..*

belongs t odepartment at

{is thedepartmentfor}

0..1

0..*


{functions as}1

0..*

is a functionperformedby

{functions as}

0..1

0..*

oversees{is overseen by}

1.. *

0..*

st aff s

{is staffed by}

1

0..*

is used t o group staff for

{groups staff int o}

1

0..*


{functions as}1

0..1


{functions as}

1

0..*


{functions as} 0..1

0..*


{functions as} 0..1

0..*


{functions as} 0..1

+source

0..*

has as target

{is the target for}

+target

1

0..*

functions as an outlet for

{has as an outlet }

1.. *

0..*

describes

{is described by}1

0..*

is assignedby {assigns}

0..1

0..*

is assignedby

{assigns}

0..1

0..*

is assigned by

{assigns}0..1

0..*


{functions as}

0..1

0..*


{functions as}0..1

1.. *

aut hors

{is authored by} 1

0..*


{functions as}0..1

0..*


{functions as}0..1

1.. *

is a version of

{has as aversion}

1

0..*

identif ies

{is identified by} 1

0..*

prov ides

{is provided by} 1.. *

0..*

is participated in by

{participates in}0..1

April 17-18, 2012


Sample UML Model from BRIDG Study Conduct Sub Domain

April 17-18, 2012


Creating BRIDG Ontology

April 17-18, 2012

We have created a complete RDF representation of the latest BRIDG DAM (v3.0.3) UML -> XMI -> XSD -> RDF conversion Utilization of several tools (Enterprise Architect,

Visual Paradigm, Topbraid Composer) Manual fine-tuning It was quite an effort…

In the end, the RDF representation of the BRIDG DAM is the core of the initial SALUS Semantic Framework, which we call SALUS core ontology Note that SALUS core ontology has a living and

expanding nature


BRIDG Ontology

April 17-18, 2012


(B) Mapping Different Content Models to BRIDG DAM Ontology (Common Ontology)

April 17-18, 2012

Medical summaries available through XML files Schemas provided through XSD

First we need to create semantic models of these content models XSD2RDF Normalization Tools can be used We created RDF model of HL7 CDA and CEN 13606

Then this semantic model of the Content Models need to be mapped to the Common Ontology So that mapping definitions can be used to

translate medical summary instances as individuals f SALUS Common Ontology


(B) Mapping CCD “Past Medical History” section to “PerformedMedicalConditionResult” class in BRIDG

April 17-18, 2012


SPINMap Formalism

April 17-18, 2012

SPINMap SPARQL-based language to represent mappings between RDF/OWL ontologies mappings can be used to transform instances of source classes into instances of

target classes Mainly uses the SPARQL CONSTRUCT

particularly useful to define rules that map from one graph pattern (in the WHERE clause) to another graph pattern

Based on SPIN (SPARQL Inferencing Notation) W3C Submission makes it easy to associate mapping rules with classes, and SPIN templates and functions can

be exploited to define reusable building blocks for typical modeling patterns Provides a vocabulary: collection of properties and classes that can be used to link RDFS and

OWL classes with SPARQL queries the class ex:Rectangle can define a property spin:rule that points to a SPARQL CONSTRUCT query

that computes the value of ex:area based on the values of ex:widthand ex:height. the property spin:constraint may link the class ex:Square with a SPARQL ASK query that verifies that

the width and height values are equal SPINMap vocabulary (http://spinrdf.org/spinmap)

A collection of reusable design patterns that reflects typical best practices in ontology mapping

Can be executed in conjunction with other SPARQL rules with any SPIN engine

http://spinrdf.org/spinmap


SPINMap vocabulary

April 17-18, 2012

Context: Groups together multiple mappings so that they have a shared target

resolution algorithm The source class of the mapping The target class of the mapping The expression that delivers the target of the mapping. This expression can

reference the variable ?source for the source resource, and the variable ?targetClass for the type of the target Usually expressed through a TargetFunction

TargetFunction Class of SPIN functions used to get the target resource of a mapping

Conditional Construct Statements… SPIN Rules

Bound to classes and contexts To map the datatype/object properties of the source-target classes Can make use of SPIN: Functions

Can make use of the results of the mappings defined through other contexts..


Sample MappingRecordTarget

-hasPatientRole

PatientRole

-hasPatient

Patient

-hasRaceCode [CE]-hasBirthTime [TS]-hasAdministrativeGenderCode[CE]

CE

-hasCodeSystem [UID]-hasCode [CS]-hasCodeSystemName [string]

CE

-hasCodeSystem [UID]-hasCode [CS]-hasCodeSystemName [string]

TS

-dtype:Value [string]

CS

-dtype:Value

UID

-dtype:Value

CS

-dtype:Value

UID

-dtype:Value

CD

-codeSystem-code-codeSystemName

Class1

-dtype:value

Code

-dtype:Value

Person

-raceCode-birhDate-administrativeGenderCode

StudySubject

-performingBiologcal Entity

TS

-value

Uid

-dtype:Value

RecordTarget-StudySubject

RecordTarget-Person

RecordTarget-CD-1

performingBiologicalEntity = targetRecource(RecordTarget, RecordTarget-Person)

• raceCode= targetRecource(RecordTarget, RecordTarget-CD-1)•administrativeGenderCodeCode= targetRecource(RecordTarget, RecordTarget-CD-2)•birthDate=targetRecource(RecordTarget, RecordTarget-TS)

• code= targetRecource(RecordTarget, RecordTarget-Code)• codeSystem= targetRecource(RecordTarget, RecordTarget-Uid)• codeSystemName= copy((RecordTarget.hasPatientRole.hasPatient.hasRaceCode.hasCodeSystemName)

•dtype:Value= copy((RecordTarget.hasPatientRole.hasPatient.hasRaceCode.hasCode.dtype:value)

RecordTarget-Code

RecordTarget-Uid

•value=targetRecource(RecordTarget, RecordTarget-Class1)

RecordTarget-TS

•dtype:Value= copy((RecordTarget.hasPatientRole.hasPatient.hasRaceCode.hasCodeSystem.dtype:value)

•dtype:Value= copy((RecordTarget.hasPatientRole.hasPatient.hasBirthTime.dtype:value)

RecordTarget-Class1

April 17-18, 2012


(D) Clinical data instance translation procedure

April 17-18, 2012


SPIN Map (SPARQL Queries

attached to Classes)

HL7 Study Design RMISMas an Ontology

Source Ontology

BRIDG DAM Ontology

Target Ontology

Ontology Mapping Definition

CDISC Study DesignOntologyInstance

Ontology Mapping Engine (SPIN

Engine)

Target Ontology Instance

(Study Design in the CDISC SDM

Ontology)

1. Defining the Mapping 2. Instance Translation

CEN 13606 XSDInstance

Study Design (Native XML

conformant to CDISC SDM ODM)

(D & F) Importing & Exporting Clinical Documents

CDISC Study Design ODMas anOntology

Source Ontology

BRIDG DAM Ontology

Target Ontology

Ontology Mapping Definition

HL7 StudyDesign XSD Instance

HL7 StudyDesign Ontology Instance

Source Ontology Instance

(Study Design in HL7 study Design

Ontology)

Study Design (Native XML

conformant to HL7 study

Design RMIM)

BRIDG StudyDesign DAM Ontology Instance

BRIDG StudyDesign DAM Ontology Instance

Ontology Mapping Engine (SPIN

Engine)

April 17-18, 2012


(E) Aligning the standards harmonized by BRIDG (Data Sets) with the SALUS Core Ontology Clinical Data Acquisition Standards Harmonization

a link between the study data collected through eCRF Forms and the study data submitted to the regulatory bodies as SDTM datasets

a limited set of structured data used for any Clinical Trial, regardless of research sponsors or therapy areas 16 domains

Adverse Events (problems) Medications (prior and concomitant) Demographics and subject characteristics Medical History Vitals/ Physical Exam ECG test results Lab results

Sites have always been asked to complete non-standard CRFs while patients are performing daily assessments, and CRFs are expected to be completed on time and accurately by the site variety of CRF questions and layouts is almost unlimited

The current 16 CDASH CRFs are associated with standard SDTM mappings and standard CDISC controlled terminology The eCRF design time is shortened as CDASH eCRF forms can be pulled out of the EDC library

as and when they are needed Standard CDASH CRFs can be transformed to standard SDTM datasets using standard extract

transform load (ETL) code

April 17-18, 2012


CDASH Data set example

April 17-18, 2012


How CDASH Variables can be used within ODM messages

April 17-18, 2012


(E) Aligning the standards harmonized by BRIDG with the SALUS Core Ontology

April 17-18, 2012

In the first case, the mappings between vocabularies termed as “data sets” (as in the case of CDASH variables) and the BRIDG based core ontology is addressed This is quite straightforward, since it is possible to write

SPARQL queries on top of BRIDG DAM to retrieve the requested CDASH variable

We have developed a library of sample SPARQL queries to extract several CDASH variables


An example SPARQL to collect fields in Medical History Data set in CDASH

April 17-18, 2012

PREFIX sp: <http://spinrdf.org/sp#>PREFIX fn: <http://www.w3.org/2005/xpath-functions#>PREFIX bridg: <http://bridgmodel.org/dam/3.0.3#>PREFIX bfn: <http://www.salus.eu/bridg-functions#>SELECT ?MHONGO ?MHSTDAT ?MHENDAT ?MHTERM ?MHTERM_CD ?MHTERM_CS ?MHTERM_CS_NAMEWHERE {

?p a bridg:PerformedMedicalConditionResult .OPTIONAL {

?p bridg:medicalHistoryIndicator ?mhi .?mhi bridg:value ?MHONGO .

} OPTIONAL {

?p bridg:occurrenceDateRange ?odr .?odr bridg:low ?odrlow .BIND (bfn:getTSValue(?odrlow) as ?MHSTDAT) .?odr bridg:high ?odrhigh .BIND (bfn:getTSValue(?odrhigh) as ?MHENDAT) .?odr bridg:value ?odrval .BIND (bfn:getTSValue(?odrval) as ?midval) .BIND (if( (!bound(?MHSTDAT) && !bound(?MHENDAT)), ?midval, ?MHSTDAT) as ?

MHSTDAT) . }OPTIONAL {

?p bridg:value ?val .BIND (bfn:getCDCode(?val) as ?MHTERM_CD) .BIND (bfn:getCDDisplayName(?val) as ?MHTERM) . BIND (bfn:getCDCodeSystem(?val) as ?MHTERM_CS) . BIND (bfn:getCDCodeSystemName(?val) as ?MHTERM_CS_NAME) .

}}


How and Where these SPARQLs can be exploited

April 17-18, 2012

Study Design Model is represented in CDISC ODM where it is also annotated with CDASH variables to specify the data to be collected through CRFs

The Medical Summaries are collected through SALUS They are mapped to SALUS Common Ontology instances

The EDC system can automatically parse the Study Design Model annotated with CDASH variables query the knowledge base already containing the medical

history of the patient in the common ontology This is achieved using the pre-defined SPARQL queries for

CDASH variables This eliminates static XSLT based mappings between

Medical Histories and CDASH annotated ODM messages representing CRFs (as proposed by IHE CRD)…


(D) Exploiting terminology systems within the SALUS Semantic Framework

April 17-18, 2012

Imported the following terminology systems from BioPortal into the SALUS Knowledge Base ICD-9: 21,669 terms ICD-10: 12,318 terms WHO-ART: 1,724 terms MedDRA: 69,389 terms National Drug File (NDFRT): 40,104 terms SNOMEDCT Clinical findings (97,139 terms) + Pharmaceuticals / biologic products

(17,100 terms) RxNorm: 194,176 terms Human Disease Ontology (DOID): 8,574 terms

It has references to other Ontologies such as ICD and SNOMED CT through DbXref property to indicate equivalances

Those are processed to create additional Mapping Definitions And, 133,825 unique code mappings Not very straight forward

Usually it is not possible to download the full ontology through a singe Rest Service due to timeouts The class names in an ontology are collected These classes are retrieved from Bioportal seperately (100 class each time) Then these subontologies are merged

Some of the Class UIDs were incorrect (for ICD), they are corrected manually


(D) Aligning the Common Ontology with Terminology Ontologies

April 17-18, 2012

To be able to automatically map the clinical data using different terminology systems to one another, it is necessary to link the coded terms in SALUS core ontology instances representing clinical data collected from participating sites with the SALUS terminology ontology resources, and to utilize terminology reasoning while querying the collected clinical data.

Two heuristics that we have adapted on top of BioPortal ontologies: We automatically create the instances of BioPortal ontology classes and copy all

non-rdfs and non-owls properties from the class definitions to the instances, to prevent OWL-Full ontologies

Within a term present in a terminology ontology retrieved from BioPortal, the original terminology system name is implicitly given in the full URL of the term However, we need to immediately get the encapsulating terminology system of any term Therefore, we automatically run a SPARQL rule to add a “skos:inScheme” property to each

instance in the terminology ontologies that we retrieve from BioPortal. We maintain an upper ontology (SALUS Terminology Upper Ontology), in which the major

terminology systems used in our system are represented as the individuals of “skos:ConceptScheme” class.

This way, we are able to execute a SPARQL rule to automatically bind a “CD” instance (a coded value) in BRIDG model to the corresponding BioPortal ontology instance via “salus:terminologyRef” property


CD

Code dtype:value: 102574007

dtype:value: 2.16.840.1.113883.6.96

Uid

PerformedMedicalConditionR

esultvalue

code

codeSystem

SNOMEDCT

<http://purl.bioontology.org/ontology/SNOMEDCT/

102574007>

<http://purl.bioontology.org/ontology/SNOMEDCT/

102572006 >rdfs:subClassOf

<http://purl.bioontology.org/ontology/

SNOMEDCT#Ins_102574007>

rdf:type

skos:notation: 102574007

????

salus:SNOMEDCT

skos:inScheme

salus:oid: 2.16.840.1.113883.6.96

CONSTRUCT { ?this salus:terminologyRef ?codeRef .}WHERE { ?this p3.0:code ?code . ?code dtype:value ?codeValue . ?this p3.0:codeSystem ?codeSystem . ?codeSystem dtype:value ?codeSystemRef . BIND (str(?codeSystemRef) AS ?csr) . ?codeOIDRef salus:oid ?csr . ?codeRef skos:inScheme ?codeOIDRef. BIND (str(?codeValue) AS ?cv) . ?codeRef skos:notation ?cv .}

salus:terminologyRef

Attached to CD class

Part A: A part of the SALUS core ontology based on BRIDG DAMPart B: A part of SNOMED CT ontology from Bioportal

skos:ConceptScheme

rdf:type

salus:LOINC

salus:ICD9salus:Med

DRA

rdf:type

rdf:type

rdf:type

√

April 17-18, 2012


Exploiting the Initial SALUS Semantic Framework

We have envisioned two use cases to1. automatically fill in eCRFs2. facilitate safety studies on EHR

systems

April 17-18, 2012


The Knowledge Base

April 17-18, 2012

All the semantic artifacts are hosted in a knowledge base The main consideration for the choice of the SALUS knowledge base is

its performance, which is related directly to the complexity of the reasoning process

Our reasoning requirements: Subsumption reasoning: Crucial to deduce matching coded terms that are

aligned with different terminology ontology class instances, which in fact have the same ancestor in the terminology ontology “Acute heart failure” is a child of “heart failure” in SNOMED CT

Reasoning on equivalence of classes: In SALUS, the mappings of the terms in different terminology ontology classes to each other are represented through “owl:equivalentClass” property. We should be able to classify individuals of a class also as the individuals of its equivalent classes. Both MedDRA:10019279 and SNOMEDCT:84114007 mean “heart failure”

Reasoning on transitivity of properties: “owl:equivalentClass” property is inherently a transitive property. It should be possible for us to process transitive equivalences, in order to classify individuals of a class also as the individuals of its equivalent classes that are deduced to be equivalent through transitivity. When we calculate the transitive closure of the 133,825 unique code mappings that we

retrieved from the BioPortal, the number of mappings increase to 186,712


The Knowledge Base

April 17-18, 2012

Clearly all the RDF and OWL-DL reasoners support all our reasoning requirements and much more.

However, due to the very large number of triples (around 4.7 million) to be reasoned on in the SALUS knowledge base, we have chosen Virtuoso. Virtuoso supports a limited reasoning capability when compared to

other RDF and OWL-DL reasoners; however the limited set of constructs supported includes rdfs:subClassOf, rdfs:subPropertyOf, owl:sameAs, owl:transitiveProperty and owl:equivalentClass, which fully address the SALUS Framework reasoning requirements.

In addition, we benefit from Protege with Fact++ reasoner support, for calculating the transitive closure only via the “owl:equivalentClass” property

It was not possible to run DL reasoning with other reasoners (Jena, OWLim, Fact++, Pellet, Hermit) when we load the BioPortal ontologies


define input:inference "salus5"prefix bridg: <http://bridgmodel.org/dam/3.0.3#>prefix salus: <http://www.salus.eu/ontology/clinical#>prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>prefix dtype: <http://www.linkedmodel.org/schema/dtype#>prefix skos: <http://www.w3.org/2004/02/skos/core#>SELECT ?subject ?subjectBirthDate ?ProblemCodeValue ?ProblemcodeSystemName ?ProblemDisplayName ?StartingDate ?EndDate ?ProblemDate WHERE {

OPTIONAL{?dateRange bridg:value ?datevalue. }

OPTIONAL{?datevalue bridg:value ?ProblemDate.}

OPTIONAL{?dateRange bridg:high ?high. }

OPTIONAL{?high bridg:value ?EndDate.}

OPTIONAL{?dateRange bridg:low ?low.}

OPTIONAL{?low bridg:value ?StartingDate.}

?performedObservationResult bridg:occurrenceDateRange ?dateRange.

?CodedValue bridg:codeSystemName ?ProblemcodeSystemName.

?ProblemCode dtype:value ?ProblemCodeValue.?CodedValue bridg:code ?ProblemCode.

?birthdatevalue dtype:value ?subjectBirthDate.?birthdate bridg:value ?birthdatevalue.?performingBiologicalEntity bridg:birthDate ?birthdate.?subject bridg:performingBiologicEntity ?performingBiologicalEntity.?performedObservation bridg:involvedSubject ?subject.?performedObservation bridg:resulted ?performedObservationResult.?terminologyCode <http://www.w3.org/2000/01/rdf-schema#label> ?ProblemDisplayName.?performedObservationResult bridg:value ?CodedValue.?CodedValue salus:terminologyRef ?terminologyCode.?terminologyCode rdfs:type <http://purl.bioontology.org/ontology/MDR/10014239>

}

Only condition

Rest are for binding values to variables in the results set

Q1: All patients with history of “Edema of Legs”


Available Sample Patient Documents in the Knowledge Base

April 17-18, 2012

Example Patient Summaries

edema of ankle (snomed)

edema of foot (snomed)

edema of leg (snomed)

edema (whoart)

heart failure (ICD)

heart failure unspecified (ICD)

heart failure (snomed)

acute H. F. (snomed)

chronic H. F. (snomed)

heart failure (whoart)

primary pulmonary hypertension (snomed)

pph (icd 9)

Dipyridamol 50MG TAB RxNorm

Code 26237000 102576009 102574007 401 428 428.98411400

75667500

74844700

3 496 26174007 416 1976221 X X 2 X 3 X 4 X 5 X 6 X X 7 X X 8 X X9 X X

10 (13606) X X

None of the medical histories are coded with MedDRA Term:10014239


MedDRA: 10014239 Edema of legs

SNOMEDCT:102574007 Edema of leg

SNOMEDCT:26237000 Edema of ankle

SNOMEDCT: 102576009 Edema of footMedDRA:10030105

Oedema legs

WHOART:0401Edema

equivalantClass

subclass subclassequivalantClass

equivalantClass

Medical History 1,5,6,7,8,9


SNOMEDCT: 102576009 Instance

typeSNOMEDCT:26237000

Instance

type

Medical History 2


SNOMEDCT:102574007Instance

type

Medical History 3


WHOART:0401Instance

Medical History 4


type

type

type

type

1. Through terminology system ontologies and mappings downloaded from BioPortal

2. Instances are created to avoid OWL Full reasoning

3. After Medical Histories are uploaded in SALUS Common Ontology, through the Rule attached to CD Class, these references are added…

4. Through equivalence, subsumption and transitivity reasoning supported by Virtuoso

5. SELECT ?ProblemDisplayName WHERE { ?terminologyCode <http://www.w3.org/2000/01/rdf-schema#label> ?ProblemDisplayName?performedObservationResult bridg:value ?CodedValue.?CodedValue salus:terminologyRef ?terminologyCode.?terminologyCode rdfs:type <http://purl.bioontology.org/ontology/MDR/10014239>


Facilitating safety studies on EHR systems

April 17-18, 2012

Q1: All patients with history of “Edema of Legs” Q2: All patients with history of “Edema of Legs” AND “Heart

Failure” Q3: All patients with history of “Edema of Legs” AND history

of “primary pulmonary hypertension ” Q4: All patients with history of “Edema of Legs” AND

actively using a “vasodilating agent” Vasodilating agent: SNOMEDCT 58944007 Instance 8: Patient is using DIPYRIDAMOLE 50MG

TAB (RxNorm: 197622) SNOMEDCT:58944007 <-- subClassOf – SNOMEDCT:

66859009 <- equivalentClass -> NDF: C24056--ingredientof NDF:C39726 <- equivalentClass -> RxNorm: 197622

similar


define input:inference "salus5"prefix bridg: <http://bridgmodel.org/dam/3.0.3#>prefix salus: <http://www.salus.eu/ontology/clinical#>prefix rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>prefix dtype: <http://www.linkedmodel.org/schema/dtype#>prefix owl: <http://www.w3.org/2002/07/owl#>SELECT ?subject ?subjectBirthDate ?MedicationCodeValue ?MedicationDisplayName WHERE {

?termCode rdfs:type <http://purl.bioontology.org/ontology/SNOMEDCT/58944007>.{?termCode salus:ingredientOf ?drugClassA. ?drugClassA owl:equivalentClass ?drugClassB. } UNION {?termCode salus:ingredientOf ?drugClassB}?drugClassA owl:equivalentClass ?drugClassB.

?medTerminologyCode rdfs:type ?drugClassB

?medTerminologyCode <http://www.w3.org/2000/01/rdf-schema#label> ?MedicationDisplayName.?CodedValue salus:terminologyRef ?medTerminologyCode.?classCode bridg:item ?CodedValue.?product bridg:classCode ?classCode.?agenta bridg:performing ?product.?performedSubstanceAdministration bridg:usedConcomitantAgent ?agenta.

?performedSubstanceAdministration bridg:involvedSubject ?subject.?subject bridg:performingBiologicEntity ?performingBiologicalEntity.?performingBiologicalEntity bridg:birthDate ?birthdate.?birthdate bridg:value ?birthdatevalue.?birthdatevalue dtype:value ?subjectBirthDate.

?CodedValue bridg:code ?MedicationCode.?MedicationCode dtype:value ?MedicationCodeValue.

?performedObservation2 bridg:involvedSubject ?subject.?performedObservation2 bridg:resulted ?performedObservationResult2.?performedObservationResult2 bridg:value ?CodedValue2.?CodedValue2 salus:terminologyRef ?terminologyCode2.?terminologyCode2 rdfs:type <http://purl.bioontology.org/ontology/MDR/10014239>}

Patients with History of “Edema of Legs”

Query parameters are mapped to related fields, like date of birth

Medication’s coded representation is retrieved as medTerminologyCode

Not only medication’s prodcut code, but also active ingredients are checked Through domain specific rules


Performance Evaluation

April 17-18, 2012

On an average desktop computer (Intel Core 2 Duo 3Ghz CPU and 4 GB RAM), the semantic mediation of a medical history in CCD format to SALUS core ontology takes approximately 110 seconds.

An example SPARQL query to check the underlying conditions of patients can be executed on the knowledge base hosting more than 4.7 million triples under 7 seconds.

These results are quite encouraging for a real-life deployment of the initial Semantic Framework.

Thank you...

a demo of an initial prototype of project idea

Documents

clinical research domain

clinical care domains

meddra term

cdisc terminology

ehr systems

prominent terminology

hl7the terminology systems

study protocol