W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > November 2007

[COI] Architecture thoughts

From: Dan Corwin <dan@lexikos.com>
Date: Thu, 29 Nov 2007 13:42:51 -0500
Message-ID: <474F082B.7080006@lexikos.com>
To: "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG>
CC: 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>

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 18:43:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:50 GMT