I ran across this in the new i2b2 CRC Design Document (https://www.i2b2.org/software/files/PDF/current/CRC_Design.pdf). They are recommending using the vital_status_cd column in the patient dimension as an indicator of the specificity of a the date/time in the birth_date and death_date columns. I think we could have i2b2 query that column, based on the code and determine how many patient we have a birth_date and death_date for.
The coding they used was arbitrary as there was no standard, I’m not sure why they didn’t use the same time codes time codes for the date specificity between birth and death, so we could either change them, or go with the i2b2 arbitrary standard. Is anyone else using these coded in the vital_status_cd column? The reason I’ve run into to implement it is that some patient have a date of birth, and some have date/time of birth, and there isn’t a good way to determine how accurate the birth_date is without it. Any thoughts here? Phillip From: <Campbell>, James R <[email protected]<mailto:[email protected]>> Date: Monday, July 28, 2014 at 8:51 AM To: "Hickman, Hubert B" <[email protected]<mailto:[email protected]>>, Phillip Reeder <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: PCORI Mapping This message was sent securely using ZixCorp.<http://www.zixcorp.com/get-started/> One thought I have been entertaining is whether we could deploy computed datatypes since the Birth_date and the Birth_time are available (or not) in the patient dimension. As Hubert says, the function would have to return a numeric date and time. Age would be good to handle similarly so that it does not have to be refreshed periodically. Jim From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Hickman, Hubert B Sent: Thursday, July 24, 2014 2:28 PM To: Phillip Reeder; [email protected]<mailto:[email protected]> Subject: RE: PCORI Mapping Since observation_fact seems to have no good way to represent a date fact natively, we could use an integer to represent the date as a Julian date, which we could convert back to a ‘regular’ date when needed. I don’t know if I like this though – but it is one way to express a date fact in the observation_fact table. Oracle has conversion functions for Julian dates. H2 From:[email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Phillip Reeder Sent: Thursday, July 24, 2014 1:35 PM To: [email protected]<mailto:[email protected]> Subject: PCORI Mapping I’m working with the i2b2 PCORI terms that Dan created and attempting to map the demographics to our local UTSW terms. I’ve mapped the PCORI Sex, Gender, and Hispanic which are pretty straight forward. I simply put our local corresponding c_fullname into the dimcode field of the PCORI terminology and it now allows me to query the pcori terms through our existing i2b2 dataset. For birth date & birth time, we currently have the birth date stored in the patient dimension. Is there a proposed way to handle querying for this through i2b2? I can map \PCORI\DEMOGRAPHIC\BIRTHDATE and have it return all patients that have a birthdate in the patient dimension which will work for getting the counts. That seems like it may be a good way to show compliance, but it doesn’t allow you to query the date/time by value. Does anyone have a good method for handling this through i2b2, or should we plan to write a SQL query outside of i2b2 to get the numbers for the GPC Site Population Data Summary? Thoughts? Phillip Reeder UT Southwestern ________________________________ UT Southwestern Medical Center The future of medicine, today. ________________________________ The Nebraska Medical Center E-mail Confidentiality Disclaimer The information in this e-mail may be privileged and confidential, intended only for the use of the addressee(s) above. Any unauthorized use or disclosure of this information is prohibited. If you have received this e-mail by mistake, please delete it and immediately contact the sender. ------------------------------------------------------------------------- This message was secured by ZixCorp<http://www.zixcorp.com>(R).
_______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
