Issue with class PARTICIPATION. Should it be Locatable or Pathable?

Technical (archive)
1

Hello,

We are having some problems with Reference Model class PARTICIPATION.
We want to define an archetype of COMPOSITION type and state, that it could have two types of participants: Doctors and Patients; At least one Doctor and one Patient participant must be specified.

After we create an archetype (we use Ocean Archetype Editor v2.2) and constrain PARTICIPATION.function using “at0007” = Doctor & “at0008” = Person, we get following XML (I removed all unnecessary elements):

participations PARTICIPATION function DV_CODED_TEXT defining_code CODE_PHRASE local at0007 PARTICIPATION function DV_CODED_TEXT defining_code CODE_PHRASE local at0008 false false true false true 0

The problem with this archetype is this:
There is no “node_id” specified on neither of PARTICIPATION alternatives (C_COMPLEX_OBJECTs).
Furthermore, in AOM 1.5 specification, C_MULTIPLE_ATTRIBUTE class description (page 39) is validation rule, that sounds like this:

<…>VACMI: child node identification: any object node added as a child to a container
attribute must have a node identifier.<…>

And this rule is being violated.

My questions are:

  1. How would we query & bind those constraints with data if we do not have node_id neither on constraint nor on data?
  2. How would we validate invariant “VACMI” on this C_MULTIPLE_ATTRIBUTE node?

My suggestions for fixing this issue would be:

  1. Derive PARTICIPATION class from “Locatable” or “Pathable” so that data could be attributed with node_id.
  2. Get rid of validation rule “VACMI” (this does not solve data <—> constraint binding issue);
  3. Any other suggestions?

Regards,
Justinas Prelgauskas,
PhD student at Kaunas University of Technology

2

Hi Justinas,

My clinical input….

You are showing an impressive level of knowledge here and have hit an area where there is still debate. There are a number of requirements:

  1. I think want to maintain the ability to add participations that are not archetyped. It is clear that systems, wards, clinics etc will want to do this on an ad hoc basis and formalising participations too much will not be possible in advance.

  2. Participations have a link to a demographic entity and limited structure beyond that. Users want a pretty simple way to say that Dr John Brown was the assistant surgeon and Dr Karl Mitten was the Anaesthetist (or the like). The tagged PARTY_IDENTIFIED is probably enough but the ID is contentious. Should this be the national doctor ID? Or the ID used for this person with the details stored elsewhere in the composition (or extract). This needs more thought.

  3. Highly structured participations probably need to be archetyped in the CONTEXT to ensure that you have what you need. We have used the demographic clusters for this purpose (as they can be shared across the two models).

I am keen to allow multiple instances of a node without a unique name as these names are for the GUI and get problematic. We are moving to this approach as it does mean that events do not need a name (they have a time after all) and simplifies things a good deal. It does require position in the query syntax.

It will be good to hear from the technologists what they see as the solution.

Cheers, Sam