1. COI Architecture? Web Enabling Standard Patient-Model Searches in Disparate EMR Systems By Dan CorwinDan Corwin November 2007

2. COI Prototype Theory: a reference web app addressing Rachels Use Case Scenario as our HCLS Task suggests can deploy soon and at modest costs IF key needs can be met.our HCLS Task 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?

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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 the other 3 services - now in active beta testsother 3 services 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)

11. 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

12. 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 EMR system APIs SHOULD be real Who can offer data to EMRwrappers?