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

Re: COI Functional Requirements - ways to implement them

From: Dan Corwin <dan@lexikos.com>
Date: Mon, 29 Oct 2007 15:15:00 -0400
Message-ID: <47263134.6040408@lexikos.com>
To: "Kashyap, Vipul" <VKASHYAP1@PARTNERS.ORG>
CC: public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>, public-hcls-dse@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>

Kashyap, Vipul wrote:

>> [DC] I've been exploring designs that can implement your spreadsheet
>> rows as a web service of "predicates" helpful to achieving this.
>> The simplest design [1] just wraps a shell of customized JSPs
>> that can make such mappings around any working EMR system.
> [VK] Yes, this could be one of the technical tasks that could be proposed. 
> I do have issues with "customized JSPs". One of the value points of SW
> technologies is to create generalized solutions and not one-off solutions.

Yep, I understand - see footnote on [1].  HTTP request/response
specs, I suggest, are the general interface you seek here.  They
can be supported in any coding language, and called in any coding
language.  That is why they are helpful for interoperability.

Example "predicates" in some software library that users might
download and adapt to their own EMR would each need some coding
language, however.  Add any other one(s) you like, pseudo-code
included, but for these little example dynamic pages, I bet JSPs
would be very popular.

>> [DC] To support patient-matching for any protocol of interest, a user
>> must also describe that protocol's goals.  A browser-based web app
>> [2] can help input parameters to automate a recurring EMR search,
>> which seems to me about what is optimal in practice.
>>    [1] see "EMR Wrappers" under BIONTDSEDCM Use Case Scenarios
>>    [2] see "Search Agents" under BIONTDSEDCM Use Case Scenarios
> [VK] Would the EMR Wrapper essentially be a gateway translating EMR data in a
> legacy format to RDF/OWL?

As I picture it - see A.2 in [1] - each EMR wrapper returns a list of
boolean values for a given list of predicates (which it alone calls).
The return format seems unimportant to this use case, as only the UI
code [2] would see it.  It could become RDF, but I visualized just an
XHTML table with "T", "F", or an error code in each row.

The UI code will use such booleans to filter a results list it had
already gotten from the search engine.  The final set of candidates
could be returned in many formats, like JSON or XHTML.  RDF/OWL is
certainly another option, but the list is meant to annotate links
to candidates, and I suspect the legacy data it actually holds on
each one would be minimal.

> [VK] Also, would "search agents" essentially be matching agents?

Yes.  They are basically completed "target" models, which will work
much like Google Alerts as new candidate(s) appear.  (I've fixed up
[2], 6-7, so as to make this more clear.)

Received on Monday, 29 October 2007 19:15:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:34 UTC