An Overview of the Integration of the UCSF Dept. of Radiology Teaching File with MIRC Wyatt M. Tellis University of California San Francisco Departments.

An Overview of the An Overview of the Integration of the UCSF Integration of the UCSF

Dept. of Radiology Dept. of Radiology Teaching File with MIRCTeaching File with MIRC

Wyatt M. TellisUniversity of California San Francisco

Departments of Radiology and

Biological and Medical Informatics

2

IntroductionIntroduction• MIRC is a “virtual” community of medical image

libraries that can be indexed and searched• Libraries can be:

– Teaching files– Research and reference image repositories– Clinical trial images and related data– Textbooks or papers

– PowerPoint © and other types of presentations

• This presentation describes the process of integrating an existing database driven teaching file with MIRC

3

UCSF Teaching File OverviewUCSF Teaching File Overview

• Web accessible• Database driven

– 4th Dimension© RDBMS

• Integrated with PACS– Images entered from the PACS display station– Images automatically converted from DICOM to JPEG– Reports automatically retrieved from RIS

• In use since 1998 with over 14,300 cases– Used by all sections (neuroradiology, chest, abdominal

imaging, skeletal, nuclear medicine, etc.)

Input Screen on PACS Input Screen on PACS DisplayDisplay

Demographics & history filled in automatically

ACR codes used for indexing

Additional content can be entered

Select key images using PACS “summary series” tool

5

Search Page for Internal UseSearch Page for Internal Use

UCSF Teaching File DisplayUCSF Teaching File Display

InternetInternet

ServerServer

Index

ServerServer

Index

UCSF

QueryService

MedPixServerServer

Index

RSNA

User

UCSF uses its internal database to index its dynamically generated documents.

UCSF TF Within MIRCUCSF TF Within MIRC

User

Independent MIRC Storage Services

User Submits Search

Broadcast Query of All Storage Services

User Views Content Hosted by Storage Services

Query Service

Receives Matching Results

Query/Storage Service Query/Storage Service InteractionsInteractions

9

MIRC Storage Service MIRC Storage Service IntegrationIntegration

• UCSF TF acts as MIRC “storage service”– Integration achieved through MIRC “query interface”

• MIRC “query interface” responsibilities:– Receive “MIRCquery” document via HTTP POST– Extract query parameters from “MIRCquery” document– Perform actual query– Generate “MIRCqueryresult” document containing

matching cases– Send “MIRCqueryresult” document back to query

service

MIRC XML Document MIRC XML Document SchemasSchemas

MIRCquery Document

MIRCqueryresult Document

11

Storage Service Storage Service ModelModel**

DB

QueryService

Storage ServiceUser

Web Server

ControlLogic

Request Handlers

XMLParser

*Courtesy of Steve Moore

12

Storage Service ComponentsStorage Service Components

• Web Server– 4D contains built-in web server– Handles network traffic between browser (and

query service) and teaching file server• Parses incoming HTTP requests• Sends HTTP response data

• Database– 4D contains built-in relational database– Used to store all text data

• Images stored externally with pointers in database

13

Storage Service ComponentsStorage Service Components

• Control Logic– Written in 4D’s scripting language

• Pascal-like syntax• Uses third party “plug-ins” to extend scripting

language’s capabilities

– Responsible for authenticating users– Delegates individual HTTP requests to

appropriate “handlers”

14

Storage Service ComponentsStorage Service Components

• XML Parser– “Expat4D” plug-in provides XML support

• 4D does not inherently support XML parsing• Freely available:

http://www.mitchenall.com/expat4d/• Based on the open source, event driven, XML parser

“Expat”

– Used to parse MIRCquery document

15

Storage Service ComponentsStorage Service Components

• Request Handlers– Individual “functions” written in 4D’s scripting

language– Approximately 70 handlers, each dedicated to

processing a specific request:• Perform query• Send list of matching cases• Send images

– Handlers can make direct calls to underlying database to process a request

16

Storage Service ComponentsStorage Service Components

• Request Handlers (cont’d)– Apply access restrictions– Each handler generates the output that is sent

as part of the HTTP response:• HTML• Binary data

– JPEG– PDF

• XML (for MIRC)

– New handler (“query interface”) added to process requests from MIRC query service

17

Query Interface OverviewQuery Interface Overview

• Single request handler– Receives MIRCquery document as input

• Uses Expat4D to parse XML

– Performs query of database using parameters specified in MIRCquery document

• Translate MIRC’s Boolean query syntax into database engine’s internal query language

• Map MIRCquery document elements to columns within the database’s schema

– Generates MIRCqueryresult document which is sent back to query service

Key Integration IssuesKey Integration Issues• Translating MIRC’s query syntax into

database engine’s internal query language– Supports Boolean operators: “and” and “or”– Uses quotes to define phrases – Uses parenthesis to create complex Boolean

searches– Sample query:

<MIRCquery>(alpha | “bravo charlie”) delta

</MIRCquery>

– Reused code from internal search page to process MIRC queries

• Query syntax is similar to the one already being used to search teaching file

19

Key Integration IssuesKey Integration Issues

• Mapping of MIRC XML document elements to database schema– 28 elements in MIRCquery document– MIRC spec allows you to ignore those that can’t

be mapped

• Anonymization of cases– Patient identifiers extensively used by

radiologists– Flags added to specify whether case has been

fully anonymized and can be shared with MIRC

20

Conclusion & Future Conclusion & Future DirectionsDirections

• Use of well established standards makes integration with MIRC straightforward– HTTP– XML

• MIRC schema extensive enough to accommodate our teaching file schema– Schema continues to evolve to meet the

community’s demands

21

Conclusion & Future Conclusion & Future DirectionsDirections

• Initially required only three days of development time with subsequent refinements over the next couple of years– Schema changes– Addition of anonymization support

• Use of the “MIRCdocument” to integrate teaching file with authoring software developed at UCSF for creating eCME courses