Re: COI Functional Requirements - ways to implement them

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.)

Thanks,
Dan

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