Basic_validity in PARTY_RELATED

[stefanspiska]

Hallo,

take this PARTY_RELATED

{
                            "@class": "PARTY_RELATED",
                            "relationship": {
                                "@class": "DV_CODED_TEXT",
                                "value": "mother",
                                "defining_code": {
                                    "@class": "CODE_PHRASE",
                                    "terminology_id": {
                                        "@class": "TERMINOLOGY_ID",
                                        "value": "openehr"
                                    },
                                    "code_string": "10"
                                }
                            }
                        }

From a Prozess Standpoint its is clear to whom I’am referring to, hover since PARTY_RELATED inherits from PARTY_IDENTIFIED the Invariant Basic_validity fails since name /= Void or identifiers /= Void or external_ref /= Void is false

1. Is it correct that PARTY_RELATED inherits the invariants?
2. If yes, how should partys wich are defined by there relationship be dealt with. Set name to relationship.value?

Thanks,

Stefan

[borut.jures]

“name”, “identifiers” and “external_ref” are all optional: PARTY_IDENTIFIED.

1. Yes, PARTY_RELATED inherits the attributes from its ancestors (PARTY_IDENTIFIED and PARTY_PROXY).
2. No, “name” should be set to “Optional human-readable name” if available. It shouldn’t have a value of e.g. “mother”. If the name is not known it should be left empty.

My comments are just what is specified in the specifications and the model:

[stefanspiska]

@borut.jures
Yes but according to the spec Common Information Model
there is an Check ( Invariants Basic_validity: name /= Void or identifiers /= Void or external_ref /= Void) that one of them has to be not empty even if all are optional and if try to validate a composition with GitHub - openEHR/archie: OpenEHR library implementing ADL 2, AOM 2, BMM, RM 1.0.4 and many tools then the validation fails and thus can not be saved in ehrbase.

[ian.mcnicoll]

I agree that this should relaxed but I’d also say it is probably good practice to include some kind of human-readable name or ‘label’ in ‘name’.

I have been arguing that we need a rethink of this part of the RM as I find I am having to workaround the need to ebed various other parts of provider demographics using cluster archetypes when doing integrations with other systems, and I see other folks doing the same.

[borut.jures]

@stefanspiska

Invariants

I googled the meaning of “invariants” but the dictionary explanation didn’t help. I also missed the “Invariants” section in the specifications

I found the explanation in an older PDF (invariants come from Eiffel). I’ll copy it here since we are in the “New to openEHR” and it might help others:

“Invariants are probably the single most important element of class specifications in any object model, since they indicate to the developer the valid instance structures in a system (for example, if a list attribute must be present, and if it is, whether the list can be empty and so on).”

As a note to myself (and others new to openEHR) - make sure to read the “Invariants” section.
Each individual attribute may be optional but an invariant may require that at least one of the optional attribute is set.

• Three optional attributes:
  • 0…1 name
  • 0…1 identifiers
  • 0…1 external_ref
• An invariant that requires that at least one of the above attributes have value:
  • Basic_validity: name /= Void or identifiers /= Void or external_ref /= Void

[borut.jures]

@stefanspiska

there is an Check ( Invariants Basic_validity:

Technically we could fill “name” with any value, but that is against the definition of this attribute. By filling it with “mother” we solve a technical problem but there might be somebody that will expect to be able to identify this person (PARTY_RELATED/PARTY_IDENTIFIED). If they found “mother” in the “name” they won’t be happy.

If “Basic_validity” is not satisfied (or it is intentionally circumvented) then the openEHR implementation that allows this will be judged as “not working”.

I guess there should be another data value that is required in case PARTY_RELATED cannot be identified. But this would probably be a free-form text field that would end-up with a value of “mother”

[ian.mcnicoll]

There is often a need to have some sort of ‘tag’ or alias against a related person. The Family history archetype has this.

[sebastian.iancu]

@stefanspiska

1. Is it correct that PARTY_RELATED inherits the invariants?

Yes, it is correct that it inherits the invariants - thus one of name, identifiers or
external_ref should be present, besides relationship.

@stefanspiska

2. If yes, how should partys wich are defined by there relationship be dealt with. Set name to relationship.value?

I am not sure I get your question correctly, but we (Code24) would store "mother" (coded) in relationship and her real name under name. For example:

{
    "_type": "PARTY_RELATED",
    "name": "Marie Curie",
    "relationship": {
        "value": "mother",
        "defining_code": {
            "terminology_id": {
                "value": "openehr"
            },
            "code_string": "10"
        }
    }
}

PS: Not sure if is relevant or applicable to your use-case, but in general the @class was replaced by _type and is not necessary when the type is fixed and clear (like when no polymorphism is involved) - compare my example above.

[thomas.beale]

@stefanspiska

• Is it correct that PARTY_RELATED inherits the invariants?

Hi Stefan,
classes always inherit invariants. The sum of invariants of some descendant class is the set of invariants from the inheritance lineage, including itself.

If that set has some logical error, then we have to fix the model.

I think your example is intended just to represent ‘mother’ but with no name or any other identifying info? I remember modelling this a long time ago according to requirements from the clinical people (@ian.mcnicoll feel free to remind us of the requirements) and I suspect I thought that there would at least be a name. Assuming that is not the case, i.e. that just saying ‘mother’ is fine, then we need to fix the model. NOTE: what we are really saying here is that just indicating ‘mother’ or whatever is sufficient to be ‘identified’… which is probably OK, but people need to be sure that’s what they want

The standard fix for this (as I am sure you know!) is that we define a function such as (this is pseudo-code - to be re-imagined in Java, PHP, etc as usual):

class PARTY_IDENTIFIED {
    <properties>

    identification_valid(): Boolean
        Result := name /= Void or identifiers /= Void or external_ref /= Void

    invariants
        Basic_validity: identification_valid()
        etc
}

class PARTY_RELATED {
    <properties>

    identification_valid(): Boolean // REDEFINED
        Result := precursor() OR relationship /= Void
}

Now, depending what language one is working in, there are various tricks needed to effect redefinition (I think Java 11 allows it), so the exact coding of this will vary. But the above is the semantic definition - i.e. you override identification_valid() and that’s all - the inheritance of the invariant Basic_validity into the child class will invoke that redefinition.

[stefanspiska]

@thomas.beale

I thought more about it and I think you should always run an openEHR server together with an Demographic Service (MPI) and thus generate a Identifier for the Person “Mother” (or more generally for any anonymous Person )and try to merge there if for example the “Mother” gets its own EHR.

Also you might have cases where the legal mother is not the biological mother, or we have a Surrogate Mother.

So I think the rule name /= Void or identifiers /= Void or external_ref /= Void is correct also for PARTY_RELATED

[ian.mcnicoll]

Yes sometimes the ‘name’ needs to be some sort of ‘alias’ to preserve privacy, or clarify that ‘sister’ in Joan and not ‘Jean’

I’d be happy to implement as-is with the rubric from the relationship code populating the party_identified name by default.

TBH I don’t think I have ever used PARTY_RELATED in a real deployment though.

[thomas.beale]

@stefanspiska

So I think the rule name /= Void or identifiers /= Void or external_ref /= Void is correct also for PARTY_RELATED

Either way can be correct - as I proposed above, or as you and @ian.mcnicoll are saying here (with or without demographic record generation for pseudo-anonymous parties). As long as we agree what the correct semantic actually is across openEHR and document it in the specs…

Shall we assume for now that what the specs say is actually formally correct? ANd that all we want to do is add a bit of text to say that you have to put something (anything) in one of the name/identifiers/external_ref fields to be valid?