Re: [COI] Project Plan Feedback

Vipul -

Sorry I missed today's TC.  Here is more feedback on the project
plan, continuing the thread I began last night ...

DC>> Your project plan handles "patient recruitment" only if you assume
>> that patient records are in DCM and protocol requests come in SDTM.
>> Neither assumption is valid, so its design seems very incomplete.
> 
VK> Yes, this is a scoping assumption for the initial prototype. It
makes sense
> to limit scope initially and we can expand scope later.

I got involved with this group because Rachel's Use Case seems a
real problem that needs a real solution.  Your POC plan moves
both realities "out of scope", and that seems its biggest flaw.

Tasks 1 and 3-5 effectively substitute limited mappings between
two abstract ontologies.  That may be easier, but it is unclear
that "patient recruitment" really needs (over)simplification.

If either ontology relates to the data expected under task 2,
that needs more explaining, especially for SDTM.  Why pick it
when UMLS is so obvious a bridge from protocols to HL7/DCM?

I suggest tasks 4, 5 and 7.2 get rephrased to address this issue
and others raised in today's excellent minutes.  Please address
in one how and when we'd "expand scope later" to go back to the
real-life "recruitment" use case advertised as the POC's goal.

DC>> Any useful architecture will map free-text requirements from *real*
>> protocol documents into working queries of *real* EMR systems.  DCM
>> and SDTM may help as intermediate "domain" schema, but without the
>> real-life endpoints, we'll show only trivial "interoperability".
>>
>> To meet its stated goals, your project plan must demo (1) turning
>> real protocol text into queries within some "domain" language; and
>> (2) such "domain" queries actually working on real-life EMR data.
> 
VK> I think this involves NLP and is clearly a difficult goal to achieve.

Looking up clinical vocabulary in UMLS is decidedly NOT a difficult
goal to achieve.  I'll say more on this when "architecture" gets on
the agenda (next week?), but here, my focus is your draft plan.

Its tasks 6-9 are currently to "implement", "integrate" and "deploy"
various components.  I urge each be replaced by a "design" task to
decide how the cited activities can best be done and why.  Until a
good public start exists on each designs, doing more is premature.

Task 9 is the toughest, as it must successfully blend designs 1 and
3-8, plus show how data from 2 gets populated and queried, assuming
each part develops as designed.  But this POC may take many months,
and much can change within that period.

All specs should therefore expect rewrites, and minimize wasted time
by keeping layered and modular all POC features they might redefine.
Instead of implementation internals, better task definitions would
focus on its interfaces (I/O) to others and capabilities.

Maybe task 10 could be identified to help more clearly specify and
collect such "process" policies, and maybe publish a POC timetable.

regards,
Dan

Received on Tuesday, 27 November 2007 21:14:29 UTC