I can do a short show and tell on concept paths in i2b2 and why the path is the 
most important piece on May 6th, if needed.

On a related note, I've been playing with SHRINE recently and it might be a 
good tool to look at for holding our local mappings, even if we didn't link our 
nodes together.   I can do a quick demo of that as well, if people are 
interested.

Phillip
Sent from my iPhone

On May 4, 2014, at 10:34 AM, "Dan Connolly" 
<[email protected]<mailto:[email protected]>> wrote:

This proposal, like the previous one, directly constrains the 
patient_dimension, provider_dimension, and visit_dimension.
 
Milestone_27_TestSQLv2.docx<https://informatics.gpcnetwork.org/trac/Project/attachment/ticket/114/Milestone_27_TestSQLv2.docx>​<https://informatics.gpcnetwork.org/trac/Project/raw-attachment/ticket/114/Milestone_27_TestSQLv2.docx>
 added

Those constraints conflict with practices and preferences at our site (and, as 
I recall, several others).

Plus, those constraints don't specify the concept paths (c_fullname in metadata 
tables) that would actually appear in the relevant queries.

Agreement on paths is necessary and sufficient for our work, as far as I can 
tell.

Given what I've seen so far, I disagree with any proposal that directly 
constrains the i2b2 table schema.

I tried to explain how paths are sufficient in last week's call, and I agreed 
to elaborate in detail. But as I mentioned, I'm at a conference this week, so 
I'm not sure I'll have it done in time for the May 6 call.


--
Dan

_______________________________________________
Gpc-dev mailing list
[email protected]<mailto:[email protected]>
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

________________________________

UT Southwestern Medical Center
The future of medicine, today.
_______________________________________________
Gpc-dev mailing list
[email protected]
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

Reply via email to