ACTION 'reason' exposed in tools?

Implementation Tools
1

Since 2015, the ism_transition/reason element has been available in the RM for specifying the “reasons for this careflow step having been taken”. In parallel, because it hasn’t been exposed in tools so we didn’t know about it, modellers have been diligently adding “Reason” data elements to ACTION archetypes for the exact same reason.

Since this is a requirement in close to 100% of ACTION archetypes, it makes total sense to have it in the RM. So can we get this exposed in tools so we don’t have to model it in new ACTION archetypes, and can deprecate it in existing ones?

3 Likes
2

+1 from me

1 Like
3

So I’ve had three likes and one +1, but no response from tooling implementers.

What do you think @sebastian.garde and @borut.fabjan? :smile:

4

We can add this to the RM tab, e.g.

Action RM attributes
Action RM attributes758×1150 81.1 KB

The text I have used is a mixture of reason texts in current archetypes and the specs.
If you want to extend or change the text to make this clearer to clinical modellers please let me know. Once agreed, we can add this to CKM immediately, this is configurable.

1 Like
5

That’s helpful right now but this will probably have to be constrainable in archetypes e.g with a codedList.

It is the reason associated with a particular careflow_step - that means that to properly represent in AD or CKM, it has to appear as partof the constraint for a Careflow_step.

Very roughly

Careflow_step: Medication Administration suspended
current_state: Suspended
Reason:
at0345: Awaiting surgery
at4066: Abnormal lab tests
at5678: Significant side-effects

Careflow_step: Medication Administration commenced
current_state: Active
Reason:
at4066: Recurrence of condition
at5678: Planned administration

1 Like
6

We have actually enabled the upload of such archetypes soon after that field was added to the spec, so you should be fine to upload this to CKM.

However, we are not visualising it at the moment. This could be added without too much trouble.
The archetypes I had a look at today (with the explicit reason element) don’t code the reason at the moment though.

1 Like
7

The archetypes I had a look at today (with the explicit reason element) don’t code the reason at the moment though.

Sure but that’s because it is not supported in archetype tooling right now!! So if we get it supported in AD, it will work fine in CKM.

1 Like
8

We also need to check if this attribute is supported in CDRs. It ought to be but you never know.

9

What I meant is this explicit “Reason” element in Description.
My understanding was that this is the element that will be obsolete once the careflow_step has a (fully supported) reason? It surely is supported by AD to use a Coded Text there?

image
image771×438 23.5 KB

10

Yep sure - I’m not sure it will be redundant, though. There may well be use-cases for Reason to associate with the whole ACTION plus the overhead of converting/updating. It might usefully be renamed at some point.

11

I think the current element will probably be redundant, as its semantics are exactly the same as the RM element. Of course if there’s a need for a “reason” element for the whole archetype we can add that whenever the requirement pops up.

I think it’s more likely the RM element will be constrained to a particular value set in templates than in archetypes, but there may of course be use cases where we’d like to do it in archetypes too. I wonder whether this could support different value sets for different care flow steps btw?

Regarding how to go about deprecating it, I seem to remember there’s a method for deprecating parts of an archetype in ADL2?

12

That is the real change this new reason attribute is explicitly associated wth a care_flow step not with the ACTION as a whole, and it should be possible ether at archetype or template level to have different valuesets for different careflow_steps.

I agree re the Rason element - we can decide on a case-bty case basis whether its has value for a particular archetype, and it is an archetype Element that is explicitly added .

1 Like
13

Yes, that’s a major advantage of that attribute and makes coding the reason much more, well, reasonable. :slight_smile: We will add support for displaying this properly in CKM.

Just to ensure we are all on the same page, is there agreement that this is an example of how it would look like in ADL:

ISM_TRANSITION[at0062] matches {    -- Blood products ordered
	current_state matches {
		DV_CODED_TEXT matches {
			defining_code matches {
				[openehr::524]
			}
		}
	}
	careflow_step matches {
		DV_CODED_TEXT matches {
			defining_code matches {
				[local::at0062]    -- Blood products ordered
			}
		}
	}
	reason cardinality matches {0..*} matches {
		DV_CODED_TEXT[at0500] occurrences matches {0..*} matches {
			defining_code matches {
				[local::
				at0501, 	-- Reason one
				at0502, 	-- Reason two
				at0503] 	-- Reason three
			}
		}
	}
}
1 Like
14

That looks fine ot me although the occurrences on reason is more likely to be 0…1 (though not always, as in cases there might be multiple reasons

1 Like
15

Yes - that was the intention to showcase that this is supported by this being a List<DV_Text>, not just a DV_TEXT. Also the reason why there - I believe - has to be a technical at-code on DV_CODED_TEXT.

2 Likes