Stream: IPS
Topic: ObservationResultsLaboratoryUvIps profiling
Elliot Silver (May 05 2021 at 03:37):
This may be more of a profiling question than about the IPS in particular, but I'm trying to understand the value[x] profiling for the lab results profile (http://hl7.org/fhir/uv/ips/StructureDefinition-Observation-results-laboratory-uv-ips.html). Elements valueBoolean, valueInteger, and valueSampled are not given slices and they don't look to be contrained out. On the other hand, valueTime, valueDateTime, and valuePeriod are listed, but don't appear to have any constraints on them.
Elliot Silver (May 05 2021 at 04:06):
Another thing I found -- ObservationResultsPathologyUvIps (http://hl7.org/fhir/uv/ips/StructureDefinition-Observation-results-pathology-uv-ips.html) has some oddities around the specimen element. The base Observation specimen datatype is Reference(Specimen). On the differential and snapshot views, it appears the data type is SpecimenUvIps; on the detail view the datatype is CodeableConcept(SpecimenUvIps). Neither SpecimenUvIps nor CodeableConcept should be possible profilings of Reference.
Elliot Silver (May 06 2021 at 18:55):
I see that SpecimenUvIps.fastingStatusCodeableConcept also has oddities on the data type. It's showing as CodeableConcept(CodeableConceptIPS). Again, I don't think that should be possible.
Rob Hausam (May 06 2021 at 22:58):
@Elliot Silver It's interesting (and a bit funny) that you are the first person that has mentioned this issue for Observation.specimen in the IPS profiles for laboratory and pathology results. You picked up on that 2 days ago, and that's exactly the same time that I first noticed it and I fixed it in our CI build yesterday. Basically, we were inadvertently treating the Specimen-uv-ips profile as if it were a datatype (as seen here - in the published IPS STU 1 it was even worse, where it was declared as a CodeableConcept with a profile of Specimen-uv-ips, as seen here). As you say, I'm pretty sure that isn't supposed to be possible! And the validator has never complained about any of this at all, so it was completely overlooked (until both of us discovered it apparently at the same time). This seems like something to fix and prevent in the validator. I was going to call that to @Grahame Grieve's attention, so I will do that now.
Rob Hausam (May 06 2021 at 22:59):
@Elliot Silver I'm also looking at the the fastingStatusCodeableConcept issue that you noted, as the rendering there is odd.
Elliot Silver (May 06 2021 at 23:00):
Thanks. Between those issues I was wondering if there was just an issue with the publisher when the IG was generated.
Grahame Grieve (May 10 2021 at 20:20):
I think it would be an error now
Rob Hausam (May 10 2021 at 21:04):
As of 1.1.68 (and earlier) I haven't seen an error message from it (unless it's somehow obscure enough that I didn't notice it, which seems rather unlikely).
Grahame Grieve (May 10 2021 at 21:23):
the current build is not like that
Rob Hausam (May 10 2021 at 21:27):
No, it isn't. I just commited the fix for it (the second iteration) on May 5th (after 1.1.68 was released). The first (partial attempt) at a fix was committed back on June 10, 2020. I haven't seen any error messages for it, at least since the first fix attempt almost a year ago.
Last updated: Apr 12 2022 at 19:14 UTC
