Lack of consistent date fallback method

[thetylerhayes]

Looking through real-world CCDA files, I see a lot of switching back and forth between using <effectiveTime value=...> vs. <effectiveTime><low ...><high ...>. Almost arbitrarily—tough to nail down when/why people use one vs. the other.

I noticed ccda/immunizations.js falls back on the latter when the former doesn't exist. But no other CCDA parsers employ this.

I noticed this after submitting #135 which effectively updates ccda/results.js to include this fallback behavior too.

[sankarravi]

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

[blacktm]

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).

[thetylerhayes]

Go4it @blacktm

[blacktm]

@thetylerhayes Just the motivation I needed 🤘

[ewhitley]

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"
}

?

[ewhitley]

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