COI Architecture?

Web Enabling Standard Patient-Model Searches in Disparate EMR Systems

By Dan Corwin

November 2007

COI Prototype

Theory: a reference web app addressing Rachel’s Use Case Scenario as our HCLS Task suggests can deploy soon and at modest costs IF key needs can be met.

Experiment: devise a web service architecture (first cut is below), then seek a set of collaborators willing and able to supply its required components.

Proof: only by existence. Will you or your organization contribute ideas, energy, time, information or money to make this prototype a useable reality?

Key Design Goals(for a prototype)

1. Search by using UMLS terms & codes

2. Filter via standard DCM patient queries

3. Patient data may span EMR systems

4. Support narrative & structured EMR data

5. Show a general interoperability method

Core Design Plans

• Match via a “Generate-and-Test” model– Find candidates first via high recall searches– Boost precision by adding Boolean constraints– User adds constraints only if the ROI justifies it

• Focus on “alerts”; query only to set them up– User efforts get invested into future time saving– Saved queries helpful to others building new ones– Cost: must index EMR data-change summaries

• Secure web-based UI, accessible anywhere

Key Usage Goals

1. Keep group search agents easy to set up

2. Interactive user training via web forms

3. Deploying helps on clinical trials at once

4. Incremental work to add other use cases

5. System learns EMR mappings as needed

User-Visible Web Services

User in browser||

UMLS ------------- (internet) -------- Text Base||

COI Agency|:

UMLS holds bulk public medical ontologies and lexicons of quasi-standard terms - almost always cite bridge concepts

Text Base holds corpora of protocols, patient summaries, extension lexicons, mapping forms, and matching agents

COI Agency (as User Interface) can find all these resources,and interactively learn the latter sorts during normal operations

Hidden Support Services:|

COI Agency|

Extractor ------- (private HTTP) ------ DAGserver|

EMRwrapper-#:

Extractor (optional) uses parsing and pattern matching to map medical text into named graphs of UMLS or Text Base concepts.

DAGserver hashes a named graph from any source to index its URI, and/or list all URIs sharing generalizations of its sub-graphs.

Each EMRwrapper can be triggered as a DAGserver agent to help validate (and process) all listed patients that match basic goals 

Mapping a DCM to EMRs:|

EMRwrapper-#Lisp-#?

|( - - - - Intranet- - - - )

|SPARQL-#?

|EMR-system-#

A EMRwrapper can filter candidates by ASK-ing its local EMR system to test each patient for specified Boolean conditions 

Boolean constraints in a standard DCM (“detailed clinical model”) must each be mapped to the local EMR data base model.

Each mapping is defined by a Text Base form - for SPARQL and/or conditionals in some scripting language such as Lisp

EMRwrapper Prototypes(the core artifact for interoperability)

• Web predicates – useful to ANY caller

• They seem a best (simplest) initial API

• Internally, they can exploit SW tools…

• .. and integrate them by using scripts

• The similarity to LSW is not coincidental

COI Agency Prototype(Web UI & QA Environment)

User in browser|

UMLS ------------- (internet) -------- Text Base|

COI Agency|

Extractor ------- (private HTTP) ------ DAGserver

|:

• UMLS resources are available; be nice to automate downloads • COI Agency UI needs web forms built for each COI use case• Lexikos can supply other 3 services - now in active beta tests

• Speed issues suggest that any new UI be deployed nearby• Hosting at same ISP is $29/mo - allows a POC scale site• Open source UI could be run under any domain name

• EMRwrapper(s) need to be run at some healthcare provider(s)

A Combined Demo Process?

The user suggests (+) and (-) predicates

DAGserver maps (+) into Patient-ID list

To improve the results-list, the UI then …

• Posts pairs: Patient IDs and (-) predicates

• EMRwrapper picks the “final” candidates

Can We Get EMRs?

Protocols are easily located on the web

Core missing need: useful Patient data

• The patients do NOT have to be real

• The EMR models MUST be realistic

• Who offers EMRwrappers their data?