FHIR Chat · testing variability on Observation.effective[x] · inferno

Stream: inferno

Topic: testing variability on Observation.effective[x]


view this post on Zulip John Moehrke (Jul 14 2021 at 13:50):

What is the current set of testing in Inferno around the Observation.effective[x] element? Of interest to me is:
a) Variations on effectiveDateTime -- precision, timezone presence, offset presence
b) use of effectivePeriod
c) rather the use of effectiveTIming, and effectiveInstant

I ask as am seeing most US-Core data using just effectiveDateTime... and having high variability on the (a) front. So wondered to what extent Inferno is covering the possibilities of variation...

and thus wondering if there is a sample data (e.g. synthetic) that covers this full range.

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:10):

Inferno, as a test platform, does not include any functionality to track or enforce coverage of variations in elements / data types. You can build that functionality in tests, as we have to a certain extent in the Inferno US Core tests (and copied into our IPS tests, and may others). I do think that we should extract that kind of functionality out into the platform itself because it is broadly useful.

view this post on Zulip John Moehrke (Jul 14 2021 at 14:11):

I was not asking about observations where the .effective[x] changes over time... I am speaking to the case where data population has variation on how the .effective[x] is filled out.

view this post on Zulip John Moehrke (Jul 14 2021 at 14:13):

as in... some observations have just year, some have just year+month, some have just year+month+day, some have.....

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:14):

Sorry, by 'track' I meant look across a set of data and see what kinds of variations exist (and maybe add some rules about what a minimum set of variations are necessary to pass a test)

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:15):

For our US Core tests, we do not keep track of what variations have been shown by the responder, because there are no requirements in US Core for responders to support multiple variations.

view this post on Zulip John Moehrke (Jul 14 2021 at 14:16):

understood... so the answer is.. Inferno has no specific tests for varability in effective[x]... reasonable answer

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:17):

Inferno as a test platform does not, and Inferno US Core tests do not either. You certainly could write a little bit of code as part of the test to keep track of that, but we haven't because we haven't needed it (yet).

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:22):

DateTimes are a bit like choice types, which brings me to b) and c). Versions 1.0 - 1.3 of the Inferno US Core / g10 certification tests required systems to demonstrate all choice types for must support elements. There was a lot of pushback against that interpretation by ONC, so the Inferno US Core tests were updated to only require demonstration of at least one choice for each must support element. US Core v4.0.0 has been updated to be explicit about which choices must be supported for each must support element, so for testing that version we will take that into account.

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:27):

In the case of Observation.effectivePeriod, if a US Core v4.0.0 profile flags that choice as a must support, we will verify it is included when testing in the context of that profile. For lab result observations, as an example, it looks like only the Observation.effectiveDateTime is flagged as must support, so we will only verify that choice exists in the data provided by the responder.

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:36):

As far as synthetic data that covers the full range... we do provide a data set, based on synthea with a few post-process tweaks to ensure that we get patient records that cover all the things that we test. At one point, I believe part of the tweaks were to update some must support choice-type data elements so that all choice variations were present. But since Inferno US Core g10 tests were updated to not require seeing all choice variations, we may have pulled that logic out. We did not touch the DateTime elements that came out of Synthea -- we just did provided whatever Synthea provided. I would guess Synthea only provides one variant, but I'm not sure about that.

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:40):

If you'd like to see what we did, it is Synthea -> US Core Data Script -> US Core Data Sets. The most recent data set is loaded onto https://inferno.healthit.gov/reference-server/r4

view this post on Zulip Robert Scanlon (Jul 14 2021 at 14:47):

Another layer to this is that the search API allows flexibility in what DateTime variants a server decides to support searching by.
For example, a system may decide only to allow searching by the date + time + timezone variant. US Core v4.0.0 adds some constraints around that.

view this post on Zulip John Moehrke (Jul 14 2021 at 15:02):

thanks. I understand the scope and intent of Inferno... I was not being critical, I was investigating.


Last updated: Apr 12 2022 at 19:14 UTC