Transcript HCLS$$ClinicalObservationsInteroperability$COI_Architecture2

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.
2.
3.
4.
5.
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
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.
2.
3.
4.
5.
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
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 the 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
• EMR system APIs SHOULD be real
• Who can offer data to EMRwrappers?