How About A Second Date?
Supporting Dates on the FHIR-y Data Platform
Hellooo again…it’s April! It’s been a while since I opened the window into RelayHealth’s Data Platform development adventures, but not because we weren’t working hard. As I resurface from three months of intensive discussions, prototyping, and operationalizing, I also want to surface some of the mystifying discussions we’ve been having over here in Emeryville.
You’re probably thinking, “It’s about time!”, and you’d be correct because post is about time…dateTime (heh heh).
…And dates of other types to, like instant, date, and time. FHIR supports a plethora of date dataTypes (say that five times fast) in a clear way (read: “interoperable”). This is exciting as we look forward into the FHIR-y realm of the future.
However, as you know from my other posts, we at RelayHealth are largely concerned about the bridge from today’s jungle of health information exchange to the FHIR-y future. How do we get there?
I want to talk about dates because of the number of invalid dates I see every day from our customers, both in CCDA and HL7 v2. When I say invalid, I mean invalid w.r.t. FHIR’s well-defined dataType formats. These dates could be invalid because they are only a month and a year, instead of the required day/month/year, making them essentially garbage in the eyes of the FHIR model.
But are they garbage to us? Sometimes I think yes…like with a result or set of vital signs without a timestamp. Do those clinical values even make sense without a qualified date? And, I know that our customers are often frustrated when they see bad data (such as un-timed results) in their system.
On the other hand, one of our office mantras is, “If we get sent bad data, we will expose bad data”. Part of what we do here is surface bad or incomplete data to our customers so that they can get their rogue EMRs in line. And, a core principle of the RelayHealth Data Platform is to “Platform all the things!”…in other words, store all the data that we can, and someone will find a use for it.
That last principle is what brings me to my stance on storing so-called “invalid” dates: Data is data, and sometimes a human can make sense of data in ways that computers can’t yet.
“Platform all the things!” — Arien Malec
But how to implement this?
We are thinking a FHIR extension to include a “string” dataType for dates. In this way, we can capture any non-conformant dates (because data is data) and simultaneously surface the invalid dates since they will have been stored in their very own dataType.
Building that 20%, yo.
So, FHIR community, what do you think? How are you handling invalid dates, and other non-conformant pieces of data?