- From: Dan Russler <dan.russler@oracle.com>
- Date: Thu, 29 Nov 2007 15:21:19 -0500
- To: Dan Corwin <dan@lexikos.com>
- CC: "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG>, public-hcls-dse@w3.org, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>, Stanley Huff <Stan.Huff@intermountainmail.org>, Yan Heras <Yan.Heras@intermountainmail.org>, "Oniki, Tom (GE Healthcare, consultant)" <Tom.Oniki@ge.com>, Joey Coyle <joey@xcoyle.com>, Landen Bain <lbain@topsailtech.com>, "Bron W. Kisler" <bkisler@earthlink.net>
Just to let everyone know... There is now a new Open Source tooling organization called Open Health Tools. It is based on the Eclipse Public License and Eclipse development platform architecture. It is also in the process of producing an International EHR Reference Architecture model for general runtime architecture guidance. This International effort will include mappings from at least Canada Infoway, Australia NEHTA, and UK NHS Spine architectures sponsored by the respective governments. NCI in the US is also involved. The OHT organization is just getting up and running, but all the Eclipse related information is available from Eclipse. Hope that helps...Dan Dan Corwin wrote: > > Hi team - > > Vipul asked me to suggest an architecture for implementing our > Proof-of-Concept (POC) application. Below is a design we can > offer to real EMR systems once we debug it on simulated ones. > > From what I've read and seen, practical software for a "patient > recruitment" use case will require 3 main transformations in > data representation, numbered #1-#3 below. > > Their implied executables must connect 4 data stores. When their > boxes get added, the abstract architecture diagram below emerges. > In it, a UI encapsulating #1 and #2 is formalizing real protocols > into queries that a EMR-system-specific "back end" can evaluate: > > > ******************** > * Textual goals in protocol > ******************** > | > | > #1. (Concept-extraction UI) > | > V > ******************** > * UMLS summary graphs > ******************** > | > | > #2. (Remapping-to-domain UI) > | > V > ******************** > * "Domain" queries (HL7/DCM/SDTM) >== get ==> EMR Candidates > ******************** > | A > | | > #3. (Domain-to-EMR data mappings) > | | > V | > ******************** > * EMR System with pool of patients > ******************** > > > Architecture deployment specs should address only full-scale, > solutions, lest major design problems go unnoticed. I favor > the loose federation of HTTP services outlined three weeks ago > in the "COI Architecture" power point. It and related draft > specs are now on the wiki under "Use Case Scenarios". > > For a POC implementation, we need only "most central" features. > I'd wrap them in two web apps (easiest type to demo) that can > expand as resources allow. They'd communicate only by passing > files, so both can function alone: > > * UI-level code, working roughly as the "SearchAgent" specs > suggest, can help users convert protocol text into saved > inclusion queries, plus boolean constraints. > > * Detailed clinical model (DCM) constraints can evaluate > in "EMRwrappers", which run equivalent tests using EMR > system data, scripts, and any SW tools desired. > > EMRwrapper predicates widely expose "Clinical Observation" > standards and can gradually grow in scope. Those arising > from our HL7/DCM/SDTM mapping work can be early exemplars, > easy to download, which users adjust locally as needed. > > SearchAgent UIs can help users write "recruitment" queries > by suggesting applicable standard predicates. The UI too > can expand gradually in scope, by adding use cases. Many > seem possible, as this design lets "domain" web queries be > broadcast unchanged to open sets of disparate EMR systems. > > I can offer UI coders access to a UMLS-based "semantic" search > engine I am writing. It does the core of transforms #1-#2 via > web services now available. It can also index or query named > graphs, alert users on changes, and trigger constraint-based > filters of result lists. This tool raises my own ambitions > for a POC, and for similar COI use cases it may support. > > Next steps for any POC design should be critical reviews that > seek ways to improve or simplify it. Please email feedback on > these or related "architecture" thoughts to the list. Thanks. > > best regards, > Dan Corwin > >
Received on Thursday, 29 November 2007 20:23:11 UTC