1 / 12

COI Architecture?

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.

tanisha-wood
Download Presentation

COI Architecture?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Key Design Goals(for a prototype) • Search by using UMLS terms & codes • Filter via standard DCM patient queries • Patient data may span EMR systems • Support narrative & structured EMR data • 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 • Keep group search agents easy to set up • Interactive user training via web forms • Deploying helps on clinical trials at once • Incremental work to add other use cases • 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 COIAgency(as UserInterface)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 DAGserveragent 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 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)

  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 • The EMR models MUST be realistic • Who offers EMRwrappers their data?

More Related