Stream: implementers
Topic: Degrading Quantity
Richard Kavanagh (Jan 08 2020 at 14:02):
We have a scenario where we are attempting to represent immunisation data in FHIR. A challenge that we have identified is that the "dose quantity" is currently expressed as a string, but the resource expects it as a simple quantity. We don't think we can reliably decompose the string into value & unit. From what I can see there is no way to degrade a quantity to text and no extensions exist,
I am assuming that the only option I have would be to create my own extension - has anyone else has similar issues with quantities?
Nathan Hall (Jan 08 2020 at 14:19):
We have had the same issue with dose quantity for regular medicationstatements and medicationrequests, using an extension for a string representation of the dosage quantity
Richard Kavanagh (Jan 08 2020 at 14:50):
@Lloyd McKenzie @Grahame Grieve is this a candidate for a standard extension that we could backport to earlier versions of FHIR?
Jose Costa Teixeira (Jan 08 2020 at 14:53):
I like the idea of a standard extension to allow quantity expressed in text. Would be a simple string, or..
?
Richard Kavanagh (Jan 08 2020 at 14:57):
I'm guessing just a string
Jose Costa Teixeira (Jan 08 2020 at 15:01):
(Just for hammering the arguments)
so what is the need for a standard extension? Are there 2 ways to add a string extension? Or is just to give visibility that we know that quantities can be expressed as a string only, this is why we publish an extension
Jose Costa Teixeira (Jan 08 2020 at 15:02):
The only thing we standardise is the extension name, right?
Richard Kavanagh (Jan 08 2020 at 15:24):
Yes that would be my view , the important bit is that everyone can use the same extension and not create their own.
John Moehrke (Jan 08 2020 at 15:47):
seems a good candidate for a core extension. not something that we would want to put in as an element, but reality is that sometimes (legacy data) all there is is text. Thus core extension enables us all to record that text the same way, while making it clear the number is preferred.
Richard Kavanagh (Jan 08 2020 at 16:01):
I'll add a JIRA ticket
Lloyd McKenzie (Jan 08 2020 at 16:19):
You can already use this extension: http://hl7.org/fhir/extension-originaltext.html
Lloyd McKenzie (Jan 08 2020 at 16:20):
It's allowed on Quantity and anywhere else you might want it (doesn't make much sense for string and Address, HumanName and CodeableConcept already have core equivalent)
Nathan Hall (Jan 08 2020 at 16:25):
That's good to know. thanks
Richard Kavanagh (Jan 08 2020 at 16:34):
We dual develop in both STU3 and R4 - any suggestions on what we would do for Stu3 as this is an R4 extension.
Lloyd McKenzie (Jan 08 2020 at 16:52):
If you want it to validate, I think you'll have to define your own as I'm pretty sure the validator doesn't recognize extensions defined in future releases (@Grahame Grieve to confirm).
Grahame Grieve (Jan 09 2020 at 23:05):
the validator recognises anything defined in r2-r4. It doesn't know anything about R5 extensions for now
Lloyd McKenzie (Jan 09 2020 at 23:21):
Cool - so the version in which an extension is defined doesn't matter? That's pretty awesome...
Grahame Grieve (Jan 09 2020 at 23:58):
oh no. it supports the extension format for cross versioning, but not cross versioning like that. but the original-text extension has been around for a while
Lloyd McKenzie (Jan 10 2020 at 00:43):
Actually, originalText hasn't been around that long. I looked for it in STU3 and couldn't find.
Last updated: Apr 12 2022 at 19:14 UTC
