Modeling case question: quantity units depending on the element name coded value

Specifications ADL
,
1

Hi all, I have a question about clinical modeling: in a use case, which is similar to the current generic modeling for laboratory results, but for fluid replacement (solutions and blood products), I’m trying to model the recording of each solution or blood product administered to a patient by using a quantity as the value of the amount of fluid administered, and to say which was the fluid (saline solution, ringer, colloids, plasma, red cells, etc), I’m trying to use the ELEMENT.name as a coded text.

Since different fluid types could have a different unit of measure (ml, cc, …), I need a constraint based on the code in ELEMENT.name that will constraint ELEMENT.value.units (value is DV_QUANTITY).

Note: that is just an example of a more general use case which I don know if could be solved only with cADL

The question: is it possible to express such constraint based on dependencies to another field value in an archetype? How do others do this?

My guess is: cADL is not enough and some kind of rule/assertion is needed to express such constraint.

BTW, I’m cheating a little bit because I’m not really creating an archetype, but the rules for UI generation in that case, in fact I’m working on a UI specification in JSON, I’m share my findings later :slight_smile: (what I need to realize is from where to get those constraints to use that metadata in the GUI generation / data validation).

This is a pseudo-code of the case:

ELEMENT {
  name {
    type: DV_CODED_TEXT
    code      <<< this defines the ELEMENT type, in my fluids example would be the type of fluid like "saline solution"
  },
  value: {
    type: DV_QUANTITY
    value: {
      magnitude
      units      <<<< defined/constrained by setting the ELEMENT.name.code
    }
  }
}
2

The first capability we have to address this is ADL rules (see here in ADL2 spec).

The second one is tuples that allow paths from different objects, not just attribute names from the same object. I did a proposal for CIMI years ago on this, that would allow LOINC-based tuples for lab quantities, with exactly the kind of constraint you mention in the example. I can’t seem to lay my hands on it right now, but I think it is worth adding to ADL2 anyway.

3

Thanks Thomas, for this specific case, after trying different approaches, I solved it using “conditional constraints”. Basically that is: if a rule evaluates to TRUE, a constraint is enabled. With that, the rule could be on a different field than the one where the constraint is applied.

A pseudo-code would be:

 field: [
    if (condition1(other_field, params)) then apply_constraint(field, constraint1),
    if (condition2(other_field, params)) then apply_constraint(field, constraint2),
    ...
 ]
  • “field” would be the quantity.units in my sample case.
  • “other_field” would be the code in ELEMENT.name, being a DV_CODED_TEXT
  • “conditionX” is a boolean function
  • “constraintX” is just a normal constraint (in cADL if this is an archetype)

So this is like modifying the archetype depending on the data input, which I see useful for a lot of cases where we have fields depending on each other.

Right now I’m not focusing on ADL but on GUI generation, here is a set of things that I want to express, and I’m working on making a consistent set of rules, constraints and actions: https://gist.github.com/ppazos/d9478bff574ef7064f3d882a6337baaa

Note: there, each field corresponds to a node in a archetype/template, even though some field/attribute names might differ from the RM, since this is not RM, and will have it’s own model, with some correspondences to the openEHR RM.