a demo of an initial prototype of project idea
DESCRIPTION
A demo of an initial prototype of project idea. Mustafa Yuksel & Gokce B. Laleci , SRDC. Motivation. C urrently , the clinical research and the clinical care domains are quite disconnected because each use different standards and terminology systems. - PowerPoint PPT PresentationTRANSCRIPT
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.
SALUS Technical Kickoff Meeting 3
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
SALUS Technical Kickoff Meeting 4
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
SALUS Technical Kickoff Meeting 5
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
SALUS Technical Kickoff Meeting 6
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
SALUS Technical Kickoff Meeting 8
(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
SALUS Technical Kickoff Meeting 9
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:
TS.DATE.FULL+ pre1938Indicator: BL::Material+ code: CD+ formCode: CD+ description: ST+ actualIndicator: BL+ effectiveDateRange:
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
+ effectiveDateRange: IVL<TS.DATETIME>
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
+ typeCode: CD+ effectiveDateRange:
IVL<TS.DATETIME>
Performe r
+ identifier: II+ typeCode: CD+ postalAddress: AD+ telecomAddress: BAG<TEL>+ effectiveDateRange:
IVL<TS.DATETIME>
constraints{Is a Function Performed By Exclusive Or}
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
+ typeCode: CD+ effectiveDateRange:
IVL<TS.DATETIME>
ResourceProv ider
+ identifier: II+ effectiveDateRange:
IVL<TS.DATETIME>
constraints{Is a Function Performed By Exclusive Or}
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:
TS.DATE.FULL+ pre1938Indicator: BL::Material+ code: CD+ formCode: CD+ description: ST+ actualIndicator: BL+ effectiveDateRange:
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
constraints{Is a Function Performed By Exclusive Or}
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
+ effectiveDateRange: IVL<TS.DATETIME>
0..1
is a functionperformed by
{functions as}
1
0..*ov ersees
{is overseen by}
0..*
0..*
is a functionperformed by
{functions as}
0..1
0..*
is assigned by
{assigns}
0..1
0..*
is a function performed by
{functions as}
0..1
0..1
is a functionperformed by
{functions as}
0..1
0..*
is credentialed by
{credentials}
1
0..*
is a function performed by
{functions as}
1
0..*
has as source
{is the source for}
1
0..1
is a functionperformed by
{functions as}
1
0..*
has as target
{is the targetfor}
1
+identifyi ng 0..*
identif ies
{is identified by}
+identifi ed 1
0..1
is a functionperformed by
{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..*
is a function performed by
{functions as}
0..1
0..*
is managed by
{manages}
1
0..*
is a functionperformed by
{functions as}
0..1
0..*
is a function performed by
{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..*
is a function performed by
{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..*
is a function performed by
{functions as}0..1
+sourc e
0..*
has as target
{is the targetfor}
+target
1
0..*
is a function performed by
{functions as} 0..1
0..*
gr oups
{isgroupedby}
1.. *
0..*
fabricates
{is fabricated by} 1.. *
0..*
manufacturesfor
{manufactures at}
1.. *
0..*
is a function performed by
{functions as}1
+contained0..*
{contains} iscontained i n
+containing0..1
0..*
is a function performed by
{functions as}1
0..*
is a function performed by
{functions as}0..1
0..1
is a function performed by
{functions as}
0..1
0..*
is a functionperformed by
{functions as}
1
0..*
is a function performed by{functions as}
1
0..*
is a function performed by
{functions as}
1
0..*
is a function performed by
{functions as}0..1
1.. *
is amember of
{has as amember}
0..1
0..*
is a functionperformed by
{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
is a function performed by
{functions as}
1
0..*
is a function performed by
{functions as}0..1
0..*
is assigned by
{assigns}
1
0..*
is a function performed by
{functions as}0..1
0..*
identifi es
{is identified by}1
1.. *
belongs to
{contains}1
0..*
is a function performed by
{functions as}0..1
0..1
is a function performed by
{functions as}
1
0..*
is part of
{has}1
0..*
is a function performed by
{functions as}0..1
+performed
0..*
is a function performed by
{functions as}
+performing
1
+scoped
0..*
is scoped by
{scopes}
+scoping
1
0..*
is a functionperformed by
{functions as}
1
1
st aff s
{is staffed by}
1
1
staff s
{is staffed by}
1
0..*
is a function performed by
{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..*
is a function performed by
{functions as}0..1
0..*
belongs t odepartment at
{is thedepartmentfor}
0..1
0..*
is a functionperformed by
{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..*
is a function performed by
{functions as}1
0..1
is a functionperformed by
{functions as}
1
0..*
is a function performed by
{functions as} 0..1
0..*
is a functionperformed by
{functions as} 0..1
0..*
is a function performed by
{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..*
is a function performed by
{functions as}
0..1
0..*
is a function performed by
{functions as}0..1
1.. *
aut hors
{is authored by} 1
0..*
is a function performed by
{functions as}0..1
0..*
is a functionperformed by
{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
SALUS Technical Kickoff Meeting 10
Sample UML Model from BRIDG Study Conduct Sub Domain
April 17-18, 2012
SALUS Technical Kickoff Meeting 11
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
SALUS Technical Kickoff Meeting 12
BRIDG Ontology
April 17-18, 2012
SALUS Technical Kickoff Meeting 13
(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
SALUS Technical Kickoff Meeting 14
(B) Mapping CCD “Past Medical History” section to “PerformedMedicalConditionResult” class in BRIDG
April 17-18, 2012
SALUS Technical Kickoff Meeting 15
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
SALUS Technical Kickoff Meeting 16
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..
SALUS Technical Kickoff Meeting 17April 17-18, 2012
SALUS Technical Kickoff Meeting 18
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
SALUS Technical Kickoff Meeting 19
(D) Clinical data instance translation procedure
April 17-18, 2012
SALUS Technical Kickoff Meeting 20
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
SALUS Technical Kickoff Meeting 21
(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
SALUS Technical Kickoff Meeting 22
CDASH Data set example
April 17-18, 2012
SALUS Technical Kickoff Meeting 23
How CDASH Variables can be used within ODM messages
April 17-18, 2012
SALUS Technical Kickoff Meeting 24
(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
SALUS Technical Kickoff Meeting 25
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) .
}}
SALUS Technical Kickoff Meeting 26
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)…
SALUS Technical Kickoff Meeting 27
(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
SALUS Technical Kickoff Meeting 28
(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
SALUS Technical Kickoff Meeting 29
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
SALUS Technical Kickoff Meeting 30
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
SALUS Technical Kickoff Meeting 31
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
SALUS Technical Kickoff Meeting 32
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
SALUS Technical Kickoff Meeting 33April 17-18, 2012
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”
SALUS Technical Kickoff Meeting 34
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
SALUS Technical Kickoff Meeting 35April 17-18, 2012
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
salus:terminologyRef
SNOMEDCT: 102576009 Instance
typeSNOMEDCT:26237000
Instance
type
Medical History 2
salus:terminologyRef
SNOMEDCT:102574007Instance
type
Medical History 3
salus:terminologyRef
WHOART:0401Instance
Medical History 4
salus:terminologyRef
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>
SALUS Technical Kickoff Meeting 36
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
SALUS Technical Kickoff Meeting 37April 17-18, 2012
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
SALUS Technical Kickoff Meeting 38
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...