Stream: implementers
Topic: Vital signs supporting observations
Ardon Toonstra (Sep 06 2017 at 14:06):
The Vital Signs profiles suggest that supporting observations are possible, however the vital signs basic profile constrains the .value and component.value to Quantity. In addition, the .related points to a Vital Signs profile. One of the common supporting observations for bloodpressure would be Cuff size which is a CodeableConcept. Because of the basic Vital Signs profile it is impossible to associate such concept to the bloodpressure profile. How did others solve this?
Eric Haas (Sep 06 2017 at 16:10):
create a tracker. I think @Michelle (Moseman) Miller caught this one already.
Alexander Henket (Sep 06 2017 at 18:41):
I did not find anything in the 23 open tickets for "Vital" so I assumed it was not filed yet. Added GF#13796
Alexander Henket (Sep 06 2017 at 18:49):
Do you have any intermediate advice? The way I see it we could:
1. Add extensions onto a derived profile
2. Copy the Vitalsigns profile under our own canonical, remove the constraints on component.value, derive new copies of the panel profiles, and add cuff size and other supporting stuff in components where they belong (afaik)
The latter is more work but presumably preserves maximum compatibility with the VitalSigns like they are today and after the tracker is handled. Or least from an instance perspective.
Rob Hausam (Sep 06 2017 at 18:55):
It sounds like #2 would be more directly compatible with the spec as it likely will be in the future, but technically it wouldn't be conformant today. The extension(s) would at least be conformant until the spec is changed.
Michelle (Moseman) Miller (Sep 06 2017 at 19:16):
I commented on an open issue against the US-Core implementation guide's Vitals profile, per https://github.com/argonautproject/implementation-program/issues/63. I can add this link as a comment on GF#13796 since the comments apply to both US-Core and the base FHIR Vitals profile.
Eric Haas (Sep 06 2017 at 23:35):
lying is for infants. Was hangover from CCDA and ONC 2015 CCDS.
Grahame Grieve (Sep 08 2017 at 03:04):
adults can lie perfectly well too.
Grahame Grieve (Sep 08 2017 at 03:05):
more seriously, you could also consider just violating the profile if we can get consensus around this at San Diego - and running with your own variant with the same canonical, on the basis that it's a technical correction
Marten Smits (Sep 08 2017 at 08:18):
@Grahame Grieve It would be great if we can correct this. If you need any input from our side when you discuss this in San Diego, please ping either @Ardon Toonstra , @Alexander Henket or myself. Through skype, email, or this channel since we won't be present at the WGM.
Grahame Grieve (Sep 08 2017 at 09:38):
'correct it' - you want a R3 technical correction? just updated R3 profiles? just fixed in R4?
Marten Smits (Sep 08 2017 at 11:00):
Wouldn't updated R3 profiles automatically result in a R3 technical correction? Since they are part of the spec?
Grahame Grieve (Sep 08 2017 at 17:55):
no. I could generate updated profiles and send them just to a few people without going through the process of doing a full technical correction
Grahame Grieve (Sep 08 2017 at 17:56):
and I don't think this is a candidate for a technical correction, actually
Eric Haas (Sep 08 2017 at 23:53):
What 'this' are we discussing? The vitals signs goes through OO like any other OO artifact tracker and this is not technical and any changes would be an R4 update. Don't use lying if you don't want to...
Marten Smits (Sep 11 2017 at 10:09):
@Eric Haas We don't plan to "skip" OO's process here, but we would love to have this fix in an STU3 format (patch) as well per @Grahame Grieve 's suggestion.
Eric Haas (Sep 11 2017 at 21:03):
I don't see why you can skip this vital... imo there is enough wiggle room to ignore the lying and just use the height code. Just add some textula guidance in your implementation. No patching to STU3 is warranted here.
Ardon Toonstra (Sep 12 2017 at 07:31):
There are two discussions running next to each other. The lying / standing issue is not really a problem for us since we indeed give some textual guidance. However, the component.code constrain on Quantity is (this discussion) because we can't get supporting observations into the profile, for example the Cuff size of the bloodpressure measurement.
Eric Haas (Sep 13 2017 at 13:40):
ok will discuss today in work group
Grahame Grieve (Sep 13 2017 at 13:48):
further discussion amongst toolsmiths last night - this is not a technical correction. I'm not in a position to issue a patch to help you, unfortunately
Rob Hausam (Sep 14 2017 at 04:23):
@Eric Haas, what was the result of the WG discussion?
Eric Haas (Sep 14 2017 at 07:01):
approved the relaxing the constraint to allow other datatypes for supporting obs.
Marten Smits (Sep 14 2017 at 11:12):
further discussion amongst toolsmiths last night - this is not a technical correction. I'm not in a position to issue a patch to help you, unfortunately
That's ok, thanks for trying! We'll create our own that mocks the R4 version of the profile.
Eric Haas (Sep 14 2017 at 12:48):
further discussion amongst toolsmiths last night - this is not a technical correction. I'm not in a position to issue a patch to help you, unfortunately
That's ok, thanks for trying! We'll create our own that mocks the R4 version of the profile.
what I plan to do is slice component and related by value set. so If you get there first let me know and I 'll commit to the CI build.
Last updated: Apr 12 2022 at 19:14 UTC
