OK, a closer reading of the naaccr_facts_load.sql script verifies Angela's point, that Heron base just generates an encounter_num for the observation_fact record but no record is created in the visit dimension corresponding to that encounter_num, and no encounter facts are created either. So that explains how it works now.
So an inconvenient question remains: Should it? Should NAACCR tumor records, each of which involves a tumor accession, be represented as "real" encounters? A use case might be a researcher who wants to see outpatient encounters for people who have a tumor accession listed in the registry. Does that sound at all like a real world situation to you folks? From: Bos, Angela [mailto:[email protected]] Sent: Friday, January 30, 2015 9:37 AM To: Lenon Patrick; [email protected] Subject: RE: NAACCR Encounter type? Using the HERON code base, we do not generate encounters (visit_dimension) for NAACCR tumor records. -Angela | UTHSCSA From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Lenon Patrick Sent: Friday, January 30, 2015 9:13 AM To: [email protected]<mailto:[email protected]> Subject: NAACCR Encounter type? Hey all, I'm close to loading our NAACCR data into our I2B2 instance, which involves generating encounter records (per the tumor_reg_visits table referenced in KUMC's naaccr_facts_load.sql). These encounters don't line up with any existing encounters, they're all unique. My question is, should these NAACCR "encounters" be represented in the Encounters portion of the I2B2 tree? I checked Babel and spot-checked a few setups and didn't see any reference to NAACCR under Encounter Type, which is where I'd expect to find it. Has this been considered/discussed/rejected? Your thoughts are welcome. Patrick Lenon HIMC Informatics Specialist 608 890 5671
_______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
