Why is Diagnosis not immutable?

Tags: #<Tag:0x00007f600b85aee0> #<Tag:0x00007f600b85ab98>

Hey @burke, @dkayiwa, @wyclif,

I think I know the answer, it was an oversight when upgrading to 2.2, but I just want to double check.

(Same question for Condition of course).

You’re likely correct, @mksd. A Diagnosis, like Observation, is a determination at a point in time (e.g., Why diagnoses are being addressed for the patient in clinic today? What is the presumed diagnosis at time of admission to the hospital? What is the final diagnosis at time of discharge from the hospital?).

Condition is a little different

  • Conditions are used to track a patient’s medical condition (longitudinally) over time and the understanding of a condition may change over time. For example, a condition may start as a cough or fever and later be recognized as pneumonia. Also, medical understanding is constantly evolving and a condition may later be better understood to be one of multiple more discrete conditions. So, we want a provider to be able to update a condition.
  • One of the challenges in an EMR is maintaining a valid & useful condition list. Entropy leads to long condition list and (much like issues in JIRA) the longer the list gets, the less interested anyone is in maintaining it. This is why we try to make it incredibly easy to clean up a list (e.g., remove a condition with a single click backed by an undo option instead of using pop-up confirmations) and could (right or wrong) bias us toward designing Condition to have fewer rows.

Technically, Condition could be implemented as an immutable resource under the hood, but conditions can change over time while encounter and admitting/discharge diagnoses are point-in-time and don’t change.

1 Like

@burke the reason why I brought Condition in the mix is because, like Diagnosis, they used to be recorded as obs (groups). So in 2.0 and 2.1 they were immutable, then from 2.2 on they lost their immutability.

Looks like Diagnosis at least is a very good candidate for becoming immutable (again), perhaps a thing for 2.5? Cc @grace

1 Like

As long as we’re careful about it. Part of why Condition ended up in the state it was in was some attempts to make it sort of act like an immutable object without the hard guarantees of immutability.

Added to our TAC call agenda for further discussion there too :slight_smile: