Lack of consistent date fallback method #136

Activity

1. thetylerhayes

   assigned

   sankarravi

   on Apr 4, 2015
2. sankarravi commented on Apr 6, 2015

   

   sankarravi

   on Apr 6, 2015

   Member

   More actions

   Yeah, I've definitely noticed this as well. Should absolutely be some shared code to process an effectiveTime tag and check both the value and the low/high tags
3. blacktm commented on Apr 6, 2015

   

   blacktm

   on Apr 6, 2015

   Contributor

   More actions

   FYI, we talked about the effectiveTime tag on this issue thread. I'd be interested in tackling this (been a while since I pushed some commits).
4. thetylerhayes

   assigned

   blacktm

   and unassigned

   sankarravi

   on Apr 6, 2015
5. thetylerhayes commented on Apr 6, 2015

   

   thetylerhayes

   on Apr 6, 2015

   ContributorAuthor

   More actions

   Go4it @blacktm
   
6. blacktm commented on Apr 6, 2015

   

   blacktm

   on Apr 6, 2015

   Contributor

   More actions

   @thetylerhayes Just the motivation I needed 🤘
7. ewhitley commented on Mar 24, 2016

   

   ewhitley

   on Mar 24, 2016

   More actions

   I'm looking at this as well. One other thing I ran into recently (not bb.js) is the coded representations for nullFlavor. PINF, etc. In the event we get a nullFlavor, would we prefer to return that in place of the date? Or set it as its own value?

   EX:

   <effectiveTime>
       <low value='20070501'>
       <high nullFlavor='PINF'>
   </effectiveTime>
   

   Return....

   {
       start_date: "05/01/2007",
       start_date_nullFlavor: null,
       end_date: null,
       end_date_nullFlavor: "PINF"
   }
   

   or

   {
       start_date: "05/01/2007",
       end_date: "PINF"
   }
   

   ?
8. ewhitley commented on Mar 25, 2016

   

   ewhitley

   on Mar 25, 2016

   More actions

   OK - I've got a version that handles this and returns back an interpreted form of "dates" based on the structure of the given element.

   EX:

   <effectiveTime>
       <low value="20120910"/>
   </effectiveTime>
   

   Would be interpreted as a date range

   <effectiveTime
       value="20111101"/>
   

   Would be interpreted as a fixed date.

   I'm also returning the type of date ("date" or "date_range") in the response. To avoid breaking all other consumers of dates in bb.js I'm returning the same structure I've seen in other areas of the system. This is varied by the type of date returned.

   EX:

   Fixed date:

   {
       date_type: "date", //note the key is "date"
       date_value: "2012-08-15T18:00:00Z" //or nullFlavor
   }
   

   vs.

   {
       date_type: "date_range",
       date_value: {
           start: "08/15/2012",
           end: "PINF"
       }
   }
   

   From there you can add this to your data collection in the caller. Only problem is since I'm using a variable key, you can't just neatly nest it in the data response. You have to create your data then directly add it using the variable key.

   EX:

   //get our date
   el = entry.tag('effectiveTime');
   var date = datesForElement(el)
   
   //build our response
   data.push({
       //don't add dates directly.
       // since we're using variable keys, we need to add them 
       // after we generate the data collection
       // date_range: {
       //   start: start_date,
       //   end: end_date
       // },
       status: status,
       severity: severity,
       ...
   });
   //add date to response, using variable key
   data[0][date.date_type] = date.date_value
   

   I'm honestly not too sure about the approach.

   The other option is to provide an argument to the method and say "look, I really don't care what you have - just return this as a single fixed date, even if you're a range. You sort it out." That's another option.

   Or - have a uniform response in all bb.js date responses where bb.js responds with "here's all date information" and then we don't use variable keys, but have one "date" concept wrapper that incorporates the date type, date, start date, end date, etc.

   No matter what, addressing dates will probably break some things. I'm looking at Parsers.CCDA.encounters for example.

   Right now it does the following:

   var date = parseDate(entry.tag('effectiveTime').attr('value'));
   

   So there is no concept of a start/end - just a date. That's probably OK (but not idea) for outpatient visits, but for inpatient stays - problematic. I'd actually like to change that.

   I'm glad to run with this, but would really love any ideas on the topic. :)

   -Eric
9. blacktm

   removed their assignment

   on Dec 28, 2016