The ACTION transfusion archetype has the field ‘Proportion administered’ [at0016] of type DV_PROPORTION. However, there is no PROPORTION_TYPE; it should be 2, indicating a percentage. This archetype would presumably not parse properly in at least some tools.
Thanks Thomas! This archetype hasn’t been worked on for a while, and as it was originally created more than 15 years ago the tooling at the time probably didn’t enforce this. Could I ask you to add a change request for this in the CKM, so we can track it?
1 Like
It’s done.
Possibly all archetypes with fields of type DV_PROPORTION and type = 2 (percentage) should have those fields changed to DV_QUANTITY with % units? THat wasn’t a thing we could do with UCUM in the old days, but it is now.
I’d hesitate to make those changes for established, published archetypes, unless another breaking change is required. And there are some exceptions like FiO2 where a proportion is actually a better fit.
Probably good advice, in general though that UCUM % should be the goto option in most cases. Is this worth documenting in the specs?
Are those edge cases where a particular datapoint like FiO2, is expressed as ‘equivalent ’ ratio/percent’ i.e FiO2/%O2 ,so rare that in time we should deprecate the percent type on proportion?
I would suggest doing that anyway. It just means: don’t create new archetypes / data points that represent percentage this way, it doesn’t stop the existing ones working.
Just to remind everyone, we’ve discussed this before, but I don’t think we had a clear conclusion back then. What has made you more sure now than you were then, @thomas.beale?
Percent as DV_PROPORTION or DV_QUANTITY - Clinical - openEHR
I agree with you that this should be “2” in this case and that UCUM % may be helpful here as well and that this removes the need for a DV_PROPORTION in some cases in favour of a DV_QUANTITY nowadays (whether that is desirable or not I will not comment on here).
However, one question fro my understanding: why should this archetype not parse or not be validated if the type is not pre-constrained in the archetype, what am I missing?
Yes, type is a mandatory attribute of DV_PROPORTION, but so are nominator and denominator. So in data, they need to be present, but neither of them absolutely needs to be constrained at archetype level? (For type it may be a lot more common to constrain on archetype level than especially for the nominator of course.)
You can do the same in Archetype Designer today as well btw - just leave all 5 PROPORTION_KINDs checked for DV_PROPORTION and it will not constrain the type (or just check a few).
All true (as usual 
- but I would say that if DV_PROPORTION is going to be constrained at all (rather than just stating that the data point is of that type), I’m not sure if it makes sense to not constrain the type field, since that’s pretty integral to what that data point means.
That is the sign we are missing a formalization layer. In the RM the field is required but have the choice of any values from the PROPORTION_KIND.
AOM is totally independent from the RM, so doesn’t know it needs to have a constraint for a specific value, just say a value is required.
At this level, in terms of formal conformance, the archetypes is totally valid.
You know all that, this is my point: we have this informal “does/doesn’t make sense” thing, and this is not the first time. IMO we need to find a way to express those kinds of informal agreements or patterns in guides the whole community can follow. Without that, all the “agreements” are buried in some conversation somewhere.
We could define different levels of guides, from “recommendations” to more strong rules to avoid issues when modeling or implementing, and only for things that are not RM or AOM but are kind of in between or on top of those specs. That way we could implement a whole set of extra rules and automate their checking, without breaking the specs, which will also contribute to conformance verification as another layer.
Agreed. The clinical program has a style guide on confluence. Let’s at least start collecting these examples on the specifications confluence. Can be scrap book level for now, and work from there.