December 15, 2011

Use of Semantic Adapter in caCIS Architecture

1. caCIS Project Objectives

2. TRANSCEND-caCIS Integration

a. Integration Event Flow

b. Integration Solution

c. Integration Architecture Components

3. caCIS Architecture – Information Model

4. caCIS Semantic Adapter

Contents

2

3

caCIS - Project Objectives

The caBIG® Clinical Information Suite (caCIS) project has two initial objectives: 

1. Enable source Clinical Applications to share the clinical data with target EHR systems, in multiple standard formats such as CDA

R2, RIM ITS and HL7v2; and

2.   Transform the data received from the source Clinical Application into a standard canonical information model and store it in a data warehouse for subsequent analysis by researchers

While the TRANSCEND Tolven system will be the first source Clinical Application to use the caCIS solution, the solution has been designed to be generic and extensible such that it can be integrated with other source systems in future.

TRANSCEND – caCIS Integration – Event Flow(Optimally Viewed in the Slide Show mode)

4

TRANSCEND – caCIS Integration – Event Flow

5

Activity Description

Request Clinical Data Sharing

This is when a TRANSCEND User elects to “push” clinical information to an external EHR, such as EPIC. They will enter inform ation for a Data Share Request to be evaluated by the TRANSCEND Tolven

instance.

Validate Data Sharing Request

It is expected that the TRANSCEND Tolven instance will validate the user’s authority to make such a request. If it is valid, the TRANSCEND

Tolve n instance will push all relevant content to the TRANSCEND Semantic Adapter with one or more TRIMs as payload.

Transform to Canonical Data Format (Outbound)

Based on the receipt of Internal Clinical Information, the “Semantic Adapter” converts the information to the Canonical Data Format. (Each

implementation will need a semantic adapter configured to handle that specific Internal Clinical Information characteristics and content.) The information in the Canonical Data Format is passed to the caCIS Integration Platform.

Transform to External Clinical Exchange Format

Based on the intended recipient , the caCIS Integration Platform takes information from the Canonical Data Format to create a Clinical Exchange Instance that is made available to the recipient (the method can vary). For the caCIS Project, this is when TRANSCEND’s

CDA/CCD, RIM-ITS, and HL7 v2 documents are generated and communicated.

Persist to the Clinical Data Warehouse

The caCIS Integration Platform persists all the information that it has received in the Canonical Data Format (along with the ac tual source data) into a Clinical Data Warehouse. This data is then made available to the other researchers for analysis.

caCIS – Architectural Components - Definitions

No. Term/Component Definition1. Canonical format Standards-based target data format that is used as a basis for creation of

exchange instances and is also used to populate the Clinical Data Warehouse.

2. Integration Platform (IP) The overall caCIS infrastructure component that manages the verification of canonical information, generation and routing of exchange instances and management of transmission of data to the Clinical Data Warehouse. This is the component exposed to external systems involved in data exchange.

3. Semantic Adapter (SA) The component that transforms Source Clinical Data into the Canonical format.

4. OpenXDS OpenXDS implements the Cross-Document Sharing (XDS) Registry and Repository. It is used for delivery of data to recipient systems.

5. Document Router The caCIS integration platform component responsible for managing the creation of exchange instances and delivering them to their intended recipients.

6. Canonical Model Processor

The caCIS infrastructure component responsible for receiving information from various source systems (via their individual Semantic Adapter), validating the input data, transforming it into the warehouse persistence format and passing it to the clinical data warehouse.

7. Clinical Data Warehouse The repository where the Integration Platform persists clinical data for ad hoc querying.

6

Integration PlatformCanonical

Model Processor

Canonical Model

Processor

ETLETL

Document Router

Document Router

Clinical Source Application

Clinical Source Application

Semantic Adapter

Third Party ApplicationsThird Party

Applications

Clinical Data Warehouse

Clinical Data Warehouse

RDF XML

AdhocQuery (Native Query Interface )

NAV

Native Data(Any Format)Native Data

(Any Format)

TRANSCEND Tolven (Clinical Source App.)TRANSCEND Tolven

(Clinical Source App.)

XML Payload[Routing Instructions*, Clinical Metadata*, Source Data]

XML Payload[Routing Instructions*, Clinical Metadata*, Source Data]

Data Flow

Defined Interfaces

LEGEND

caCIS Architecture

XDSXDS RetrieveDocument

Secure E-Mail

Secure FTP

Mirth Connect 2.1.1

Mirth Connect 2.1.1

Virtuoso 6.1.3

Doc. Transfer Requests only

All Data

Optional Element*

Canonical Model ProcessorWeb Service

Semantic Adapter Web Service

XML Payload[Routing Instructions*,

Clinical Metadata, Canonical Data,

Source Data]

XML Payload[Routing Instructions*,

Clinical Metadata, Canonical Data,

Source Data]

OpenXDS 1.0.1

Future Implementation

Identifier Resolver

(optional)

Identifier Resolver

(optional)

ResolveIdentifier

Vocabulary Resolver

(optional)

Vocabulary Resolver

(optional)

ResolveVocab. Code

Note: Semantic Adapter (SA) passes through the routing instructions and clinical metadata without any changes and transforms the source data into canonical data. SA output also includes untransformed source data.

caCIS – Architectural Components - Implementation Details

No. Term/Component Implementation Details

1. Canonical format Based on CCD and other broadly used CDA R2 templates

2. Integration Platform (IP) Mirth Connect (ESB)

3. Semantic Adapter (SA)

Implementers can choose a platform that is acceptable to their enterprise. The caCIS integration platform is loosely coupled with the semantic adapter and this provides the flexibility to choose any implementation platform for SA. For TRANSCEND, the SA is implemented using XSLT on MirthConnect.

4. OpenXDS OpenExchange provided by MOSS (Misys Open Source Solutions)

5. Document Router Deployed as component of the Integration Platform (on Mirth Connect)

6. Canonical Model Processor Deployed as a component of the Integration Platform (on Mirth Connect)

7. Clinical Data Warehouse Virtuoso - RDF/Triple store

8

caCIS – Architectural Components – Data Formats

9

Routing Instructions(Optional)

Meta Data(Optional)

Source Data(Any format)

caCIS Request

Routing Instructions(Optional)

Meta Data

Canonical Model Data and

Untransformed Source Data

caCIS Request

CDA/CCD

HL7v2 Document

RIM ITS

RDF Graphs

:::

Source System Integration Platform Document Recipients Data Warehouse

OR

OR

Semantic Adapter

caCIS – Information Model

caCIS Integration Platform able to support multiple Clinical Applications as the source systems (the first implementation with TRANSCEND Tolven as the source system).

caCIS Integration Platform transforms all clinical data it receives for document exchange into its “Canonical Information Model”.

A canonical information model is a model of the semantics and structure of information that adheres to a set of rules agreed upon within a defined

context for communicating among a set of applications or parties.

caCIS canonical information model is HL7 CDA R2 (Clinical Document Architecture). If any of the clinical data for document exchange does not fit the CDA model, RIM extensions will be used.

CDA R2 is based on HL7 RIM v2.07 and HL7 Data Types R1.

10

caCIS – Semantic Adapter

Functions of caCIS Semantic Adapter

Transform data from native format of the source system into the canonical representation

Translate local identifiers (e.g. Study, Study Site, Patient and others) to standardized identifiers, allowing matching of identifiers across data sources **

Translate codes from the local code systems into standardized code systems allowing comparison of data across data sources **

Semantic Adapters configured to combine data from multiple source systems prior to submission to the Integration Platform (allows construction of complete patient record when data is stored in disparate locations)

Additional Functions of the caCIS TRANSCEND Semantic Adapter

Generate the narrative text corresponding to the contents of the clinical note (requirement of the CDA specification)

Add formatting information to the output CDA document to enable human readability

11** In the initial TRANSCEND implementation, this functionality was designed but not fully implemented.

caCIS – Semantic Adapter

12

Semantic

Adapter

<relationship typeCode="PERT" direction="OUT" name="medication" sourceTrim="path/clinicalMedicationTemplate" enabled="false"> <act moodCode="EVN" classCode="OBS"> <title> <ST></ST> </title> <effectiveTime> <label>Start Date</label> <TS> <value>20110721000000-0700</value> </TS> </effectiveTime> <relationship typeCode="PERT" direction="OUT" name="medicationName"> <act moodCode="EVN" classCode="OBS"> <observation> <value> <label>Medication</label> <ST>paclitaxel</ST> </value> </observation> </act> </relationship> <relationship typeCode="PERT" direction="OUT" name="dose"> <act moodCode="EVN" classCode="OBS"> <observation> <value> <label>Dose</label> <ST>150 mg</ST> </value> </observation> </act> </relationship> <relationship typeCode="PERT" direction="OUT" name="route"> <act moodCode="EVN" classCode="OBS"> <observation> <value> <label>Route</label> <ST>IV</ST> </value> </observation> </act> </relationship> <relationship typeCode="PERT" direction="OUT" name="frequency"> <act moodCode="EVN" classCode="OBS"> <observation> <value> <label>Frequency</label> <ST>q. week</ST> </value> </observation> </act> </relationship> </act> </relationship>

Input TRIM

Medication section

<entry typeCode="DRIV"> <substanceAdministration classCode="SBADM" moodCode="EVN"> <templateId root="2.16.840.1.113883.3.88.11.83.8"

assigningAuthorityName="HITSP C83"/> <templateId root="2.16.840.1.113883.10.20.1.24" assigningAuthorityName="CCD"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7" assigningAuthorityName="IHE PCC"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1" assigningAuthorityName="IHE PCC"/>

<id nullFlavor="NI"/> <statusCode code="completed"/> <effectiveTime xsi:type="IVL_TS"> <low value="20110721000000-0700"/> </effectiveTime> <effectiveTime xsi:type="PIVL_TS" institutionSpecified="false" operator="A"> <period nullFlavor="OTH"> <translation> <originalText>q. week</originalText> </translation> </period> </effectiveTime> <routeCode nullFlavor="OTH"> <originalText>IV</originalText> </routeCode> <doseQuantity nullFlavor="OTH"> <translation> <originalText>150 mg</originalText> </translation> </doseQuantity> <consumable> <manufacturedProduct> <templateId root="2.16.840.1.113883.3.88.11.83.8.2"

assigningAuthorityName="HITSP C83"/> <templateId root="2.16.840.1.113883.10.20.1.53"

assigningAuthorityName="CCD"/> <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"

assigningAuthorityName="IHE PCC"/> <manufacturedMaterial> <code nullFlavor="OTH"> <originalText>paclitaxel<reference value="d14e825"/> </originalText> </code> </manufacturedMaterial> </manufacturedProduct> </consumable> </substanceAdministration> </entry>

Output CDA

Substance Administration Entry

caCIS – Semantic Adapter

Example of the Human-readable Narrative and the formatting generated by caCIS Semantic Adapter

13

caCIS – Semantic Adapter

Analysis & Design

Conducted sessions with TRANSCEND SME to understand the clinical context and meaning of each input data element

Created semantic mapping between Input TRIM templates and output CDA by

Identifying CCD and C83 templates associated with the clinical content for each section within the source clinical data Mapping TRANSCEND custom value sets to standard SNOMED- CT and HL-7 values

Implementation

Developed semantic transformations as well as CDA narrative generator using XSLT 2.0

XSLT transformations hand-coded. Use of graphical mapping tools such as Altova MapForce and caAdapter not feasible due to

very complex transformation rules

XSLT transformations invoked from MirthConnect Semantic Adapter channel 14