Stream: implementers
Topic: Transaction POST for vital signs
James Dinsmore (Jan 10 2022 at 22:10):
We will be implementing a transaction POST for height and weight. The end goal is to POST both the height and weight within a transaction bundle such that a BMI is also captured.
We are trying to determine if it is more appropriate for the app performing the POST to calculate the BMI and include it as an entry within the bundle (in addition to the height and weight) or to perform the BMI calculation via the FHIR server and only require the height and weight in the bundle?
Craig McClendon (Jan 10 2022 at 22:40):
I think most typically, the app would calculate and include 3 separate Observation resources in the Bundle to the FHIR server. You can find examples if needed in the US Core Vital Signs profiles. - https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-vital-signs.html
Lloyd McKenzie (Jan 11 2022 at 04:30):
You can't expect most FHIR servers to perform any auto-calculation. If you want a BMI to exist, unless you're aware of a custom arrangement, you'll need to do it yourself.
Cooper Thompson (Jan 11 2022 at 14:06):
You might need to coordinate with the specific servers you are wanting to integrate with. Some servers may behave as Lloyd suggests. Some may prefer or require that they use their own BMI calculation. (I don't know offhand which Epic does, but I know we have built-in BMI calculation functionality).
John Silva (Jan 11 2022 at 14:17):
The other thing to consider is that there are different algorithms to calculate BMI so it seems like it would make sense to have the client (source of the BMI) to send this in based on the algorithm user on the source system, e.g. an EHR.
Rob Resendez (Jan 11 2022 at 15:54):
I wonder what an implementer who creates implicit observations (such as BMI, BSA, etc) would do in the event that a bundle contained those observations. I guess they'd either still go ahead and produce their own entry and consume the one posted; or, just accept the posted observations.
Lloyd McKenzie (Jan 11 2022 at 16:55):
Depends on their rules for creating implicit ones. If it's "create if there isn't already one", then maybe they won't. If it's "create every time there's a new body weight or height recorded", then that's what they'll do.
James Dinsmore (Jan 12 2022 at 19:35):
We have been looking at Observation.component. Would it be acceptable to include a height, weight, and BMI as a Observation.component where we'd POST a single Observation instead of using a transaction POST?
Lloyd McKenzie (Jan 12 2022 at 19:39):
No. Component is for content that can't (or is rarely) interpreted or used separately and where the data is all gathered as part of a single measurement. Think APGAR, blood pressure, the drug and sensitivity level for a susceptibility test, etc. Height, weight and BMI are all captured independently using different mechanisms and can all be used independently of each other.
Mike Lohmeier (Jan 12 2022 at 23:29):
Another wrinkle here is that the various medical device regulations require that any data associated with medical device claims are not reinterpreted by integrated systems. In this example, if it's a medical device sensing height and weight and computing BMI as part of its claimed medical device functions then an integrated system cannot reinterpret the device's computed BMI value without being considered part of the medical device. There's some ambiguity around derivative works and where the medical device function starts/stops but the spirit is you can't alter the medical device function in a way that is not under controls even in integrated systems.
Lloyd McKenzie (Jan 12 2022 at 23:54):
If the requirement is to transmit all three measurements at once, a transaction Bundle is likely your best option.
John Silva (Jan 13 2022 at 11:28):
I suppose you could 'tag' the 'computed BMI' differently from the (server-side) calculated BMI. (maybe even use different codes for them if that made sense or at least different display labels). Here's a scenario that might happen in the 'real world' --- the vital sign data is sent from different types of vital sign monitors, some which source (internally calculate) BMI and others that don't. So, the FHIR server (and some backend computing engine) always calculated the BMI so that there is always a value available but in the case where a vital sign monitor sources this you could have 2 values for the same time.
Daniel Venton (Jan 13 2022 at 13:20):
Wouldn't the device calculated BMI have provenance author of the device?
Wouldn't the server calculated BMI have provenance author of the server?
Wouldn't a provider calculated BMI have provenance author of the provider?
Seems like no matter who authored the BMI observations, you'd know.
John Silva (Jan 13 2022 at 16:04):
Assuming the FHIR server supports Provenance?
Lloyd McKenzie (Jan 13 2022 at 18:18):
Forget Provenance. The Observation itself would have a performer - which ought to be sufficient. The Observation could also indicate the source height and weight Observations that were used and what 'method' was used to perform the calculation.
Last updated: Apr 12 2022 at 19:14 UTC
