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