Stream: workflow
Topic: Status Codes
Grahame Grieve (Jun 09 2019 at 03:35):
Is there anything to learn from this? https://wolandscat.net/2019/06/08/improving-process-state-representation-in-fhir/ - other than that somehow we need to make the canonical status codes more obvious?
Jose Costa Teixeira (Jun 09 2019 at 05:53):
an EHR deals with machine states (this is ongoing, this is canceled), our Request deal with state transitions (please do, please cancel). I think some remarks by the author do not reflect this (we are not clear of our choice, or perhaps he sees this, but it is not clear to me that he does). For example, trying to compare states in MedRequest vs MedDispense...
Jose Costa Teixeira (Jun 09 2019 at 05:53):
I understand that we mix different concepts like "completed" and "entered-in-error" - besides the state transitions, we added a few machine state codes for simple workflows. This was done for implementers that have very simple workflows, and do not need to use Task (which would then contain the machine states). Perhaps that causes confusion.
So, we could split those status codes as we reinforce the standard codes.
- requestStatus ("draft", "entered-in-error", "valid",...)
- activityStatus (to be usedfor very simple workflows)- ("completed",...).
But we could do some cleansing
Lloyd McKenzie (Jun 09 2019 at 19:25):
I disagree about 'draft' being a documentation state as opposed to a clinical activity state, but agree that we do mix document and activity states into one - generally just with entered-in-error. We do so on the grounds that once something is designated as "in error", the activity state ceases to be relevant and thus splitting the status adds unnecessary complexity.
It's also not accurate that we don't have state machines. We do have base 'typical' state machines for the event/request/definition patterns. We probably should have them for places where we significantly diverge from those patterns too. However, we don't expect rigorous enforcement of the machines. If you want to transition from "completed" to "draft", we'll let you - because in some contexts, doing that makes sense (e.g. correcting an erroneous transition).
Lloyd McKenzie (Jun 09 2019 at 19:29):
I disagree with the notion of a standard state machine. Different types of resources will have different machines - both in general and specifically. We need to align with the state conventions of the domains. We do capture concrete process 'steps' through the Task resource - which is the only place we've seen this needed so far. (I suppose it's possible we could see it in the Definition space if we wanted to deal with the approval process, but in most cases, that can be best represented using Task, where we've got it covered.
In my quick read, I didn't really grasp the difference between what he was proposing in terms of status and what we've already done, so I'll re-read once I've got a bit more time.
Grahame Grieve (Jun 09 2019 at 23:30):
I think that what he was proposing is that he chooses the states, and everyone else conforms, rather than having committees with only imperfect knowledge do it (apparently no knowledge is better than some knowledge)
Grahame Grieve (Jun 09 2019 at 23:31):
Also, the state machine is misleading for interop - it might be useful documentation about useful states but as long as state transitions can happen without updates, including undoing state transitions, then almost any transition is legal
Lloyd McKenzie (Jun 09 2019 at 23:33):
And one set of states for everything, rather than using that imperfect knowledge to try to better align states to what implementations actually support (and what makes sense in that domain)?
Grahame Grieve (Jun 09 2019 at 23:35):
it always comes back to the fact that some people find top-down much more comforting than bottom up
Jose Costa Teixeira (Jun 09 2019 at 23:39):
A finite state machine helps understand but in practice that is not what we can expect. We can anchor some states - as we do - but people may have statuses like "appended" or "charged" or "ready" and a prescriptive approach will not work.
Jose Costa Teixeira (Jun 09 2019 at 23:51):
Group wisdom is not always right and is hard to align but it has been insightful.
Last updated: Apr 12 2022 at 19:14 UTC
