FHIR Chat · Decimal property for a code · implementers

Stream: implementers

Topic: Decimal property for a code

Russell McDonell (Jul 05 2016 at 01:41):

Can a code, in a CodeSystem have a decimal property?

Russell McDonell (Jul 05 2016 at 01:42):

What I have is a table of codes and descriptions for physical activity, such as
01003 - bicycling, mountain, uphill, vigorous

Russell McDonell (Jul 05 2016 at 01:43):

However, each code also has a METs value - sort of the calories burned doing this thing for 1 min. e.g.

Russell McDonell (Jul 05 2016 at 01:43):

Code METS Description01003 14.0 bicycling, mountain, uphill, vigorous

Grahame Grieve (Jul 05 2016 at 01:44):

this is a set of mulitpliers for an actiivity, right? so you can take a time based observation and covert to an amount of energy?

Russell McDonell (Jul 05 2016 at 01:44):

Is METs a property of the code, and if not, how do I associate a code in a CodeSystem with a decimal value?

Russell McDonell (Jul 05 2016 at 01:47):

"MET (Metabolic Equivalent): The ratio of the work metabolic rate to the resting metabolic rate. One MET is defined as 1 kcal/kg/hour and is roughly equivalent to the energy cost of sitting quietly."

Russell McDonell (Jul 05 2016 at 01:52):

Yes, a multiplier. The units are fixed [kcal/kg/hour]. So if I have an observation of '01003' for 10 minutes, and another observation of '01004' - 'competitive cycling', which has a METs of 16.0, then the observations are comparable. See https://sites.google.com/site/compendiumofphysicalactivities/

Eric Haas (Jul 05 2016 at 01:58):

try using this extension which assign as decimal value to a code http://hl7-fhir.github.io/extension-codesystem-ordinalvalue.html

Russell McDonell (Jul 05 2016 at 02:04):

The wrinkle here is, of course, that with the advances in bicycling technology, the METs value drops over time. What was 16.0 METs in 1993, is now 15.8 METs in 2011

Russell McDonell (Jul 05 2016 at 02:07):

I could define a new extension, that contains three extensions for startDate, endDate and decimalValue, but that doesn't seem right.

Eric Haas (Jul 05 2016 at 02:10):

or define a version of a codesystem for each recalibration?

Russell McDonell (Jul 05 2016 at 02:20):

And let the application use the date of the observation to work out which CodeSystem to use. I could use DataElement for the METs values; one instance of the resource for each physical activity code and put the date bound METS values in the repeating element structure. But ElementDefinition doesn't have a start and end date, so I would have to add an extension for that. And I still don't have a way of asserting, in CodeSystem, that each code has a matching DataElement resource.

Grahame Grieve (Jul 05 2016 at 02:21):

I think this is a use of data element. Maybe @Lloyd McKenzie has some comment on that

Grahame Grieve (Jul 05 2016 at 02:21):

or else a more general question - has OO talked about conversion factors before?

Eric Haas (Jul 05 2016 at 02:25):

Yes but not recently. That was in the context of an operation. Maybe you need a new code when the concepts value changes which is equivalent to creating a new version.

Lloyd McKenzie (Jul 05 2016 at 02:38):

This does sound like a data element property - DataElement is intended to capture metadata about the meaning of a particular type of data that can be captured, though you'd end up needing to use extensions there too for something like the metabolic effort of a given activity in a given year.

Russell McDonell (Jul 05 2016 at 03:43):

I agree - one DataElement resource with multiple DataElement.elements [one or more for each code in the CodeSystem]. Just a question about the cardiality. Options are a) one DataElement resource with an extension for date range on the DataElement.element, which would mean multiple DataElement.element.code values returned when you search by 'code'. OR b) one DataElement resource for each date range, with only the DataElement.element.codes that are valid in the associated date range. At a crude level I could use DataElement.version to select the right instance for the observation date. The definition of the DataElement would be 'METs value' and the DateElement.element.type.code would be 'decimal' and the DataElement.element.defaultValueDecimal would be the MET value.

Russell McDonell (Jul 05 2016 at 03:44):

The question is, should DataElement have a 'validPeriod', or should DataElement.element have a 'validPeriod'?

Lloyd McKenzie (Jul 05 2016 at 05:08):

Multiple elements are for complex data elements (e.g. address) where you want to list multiple parts. If we wanted different characteristics per time range, then we'd need validity period

Russell McDonell (Jul 05 2016 at 05:11):

So your suggesting one DateElement resoure, for each code, in any system that assigns any additional attributes/metrics to the code.

Russell McDonell (Jul 05 2016 at 05:11):

And a validity period on DataElement itself.

Russell McDonell (Jul 05 2016 at 05:15):

So, to lookup the METs value for a physical activity code I would search for a DataElement resoure, with 'code' == physical activity code and observation date within DataElement.validityPeriod. That would should return one instance of DataElement, with DataElement.element.defaultValueDecimal being the METs value. Have I got it right?

Lloyd McKenzie (Jul 05 2016 at 05:51):

Correct

Robert McClure (Jul 05 2016 at 15:11):

@Lloyd McKenzie By using DataElement in this way would this be a code system supplement? And I assume the DataElement that stores this MET value for the code would also have the code listed so you can link them, correct?

Lloyd McKenzie (Jul 05 2016 at 15:31):

Hi @Robert McClure - it's not really a code system supplement. That's about capturing additional properties, relationships and representations - i.e. content that would be expected to be usable in value set definition and exposed as part of a terminology service. I wouldn't expect that to be the case here.

Eric Haas (Jul 05 2016 at 18:57):

so the element definition changes over time? or it versioned as well?

Eric Haas (Jul 05 2016 at 18:58):

If its static and versioned then no net benefit to versioning the code system for each generation ?

Lloyd McKenzie (Jul 05 2016 at 20:07):

Probably multiple DataElement instances each with a different version and effective time, all pointing to the same code

Robert McClure (Jul 06 2016 at 15:40):

@Lloyd McKenzie I think you have too narrow a definition of what I think of as a code system supplement - this is something that does not only exist to make value sets but is supplemental information not found in the code system but is directly tied to the concepts in the code system. Just because this specific example is not being used to define a value set who says it can't be? What if I wanted to define a value set based on MET values? We'd want to use this as a code system supplement.

Lloyd McKenzie (Jul 06 2016 at 16:20):

Well, you can define anything as a concept "property", so yes you could do it this way too. However FHIR doesn't currently support code system supplements. It does support DataElements.

Grahame Grieve (Jul 06 2016 at 21:38):

an alternative is to say that "data element" is one way to do a code system supplement. In fact, Data Element is always a code system supplment from this perspective. So is Medication, btw

Russell McDonell (Jul 07 2016 at 02:22):

On reflection, I'm not convinced. DataElement is about capturing/recording data. I'm not capturing or recording the METs value, it's a fixed property of the code, not a defaultValue. If you select a code, and the system displays a METs value, which you think is too small, then you can't override it - you have to pick a different code.

Russell McDonell (Jul 07 2016 at 02:25):

I also suspect that you cannot reasonably support integer properties and not also support decimal properties. It seems to me unreasonable to assert that, if you have properties of "1" and "3", that you can add a new property of "2", but if you have properties of "5" and "6" you cannot add a new property of "5.5". You should be able to create new category levels. And if I know that I will be creating new category levels, then I should be able to chose a data type that suites my requirements.

Russell McDonell (Jul 07 2016 at 02:30):

Now most of this I can see. The different values on different dates is not different to the problem of a different set of codes on different data. You model that with versions. There's the 1993 version, the 2000 version and the 2011 version. It is up to the application to know which version to choose when recording activity for a specific date. Further more, activites are grouped as in 'Walking', 'Running', 'Home Duties'. So that's another property on each code. And I could store 'METs * 1000" as an integer property on each code. So why not support decimal as a property of a code?

Russell McDonell (Jul 07 2016 at 02:42):

And B.T.W. - I do want to create ValueSets from this CodeSystem, such as the 'Walking' ValueSet. Now I understand that there is some current limitations on ValueSet.compose.filter.op which prevents me from creating a ValueSeet of 'Laziest exercises', being the 'bottom(10)' METs. But that might change. We might add a 'sort' and 'limit' to the parameters of $expand.

Grahame Grieve (Jul 07 2016 at 10:17):

you really want a quantity, not a decimal

Brian Postlethwaite (Jul 08 2016 at 06:33):

I think that the code should be different as Eric suggested and then the MET value is just fixed on that.
Makes more sense to be as the definition of the concept is different over time, hence a new value feels right to me.

Russell McDonell (Jul 10 2016 at 02:12):

CodeSystems that vary over time are frequently modelled as "the same CodeSystem, just different versions". It shouldn't matter whether the set of concept/code changes from version to version, or whether the properties of a concept/code varies from version to version. Which version the user choses to use is handled outside the CodeSystem. For example, there is a different issue of the DRG code set every year, with different $ re-embursements. Hospitals usually match all of last year's episodes with next years code set, in order to predict future revenue, assuming the same patient load and mix. The Compendium of Physical Activity fits that model, being issued in 1993, 2000 and 2011; each issue had mainly the same codes and same METs values, however each version had some new codes added, a few old gloves removed, and occasionally different METs value for an existing code. So versioning makes sense.

Russell McDonell (Jul 10 2016 at 02:24):

You're right - quantity would be better than decimal. I can see that we may need both one day, but I don't have Use Case for decimal at the moment. However, if 'property' is meant to cover all possible properties of a concept, then we've only begun to scratch the surface. Let's see, we need Address as a property and property needs to repeat to what we can represent the boundaries of a 'postalcode' [after we add longitude, latitude and elevation to the Address data type].

Grahame Grieve (Jul 10 2016 at 06:46):

Code System is not meant to be used for everything.

Russell McDonell (Jul 13 2016 at 08:52):

But codes are used for everything.

Last updated: Apr 12 2022 at 19:14 UTC