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

 

 

 

 

 

From: [email protected]
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Justinas
Prelgauskas
Sent: Saturday, 8 January 2011 12:00 AM
To: openehr-technical at openehr.org
Subject: Issue with class PARTICIPATION. Should it be Locatable or Pathable?

 

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):

 

<attributes xsi:type="C_MULTIPLE_ATTRIBUTE">

          <rm_attribute_name>participations</rm_attribute_name>

          <children xsi:type="C_COMPLEX_OBJECT">

            <rm_type_name>PARTICIPATION</rm_type_name>

            <node_id />

            <attributes xsi:type="C_SINGLE_ATTRIBUTE">

              <rm_attribute_name>function</rm_attribute_name>

              <children xsi:type="C_COMPLEX_OBJECT">

                <rm_type_name>DV_CODED_TEXT</rm_type_name>

                <node_id />

                <attributes xsi:type="C_SINGLE_ATTRIBUTE">

                  <rm_attribute_name>defining_code</rm_attribute_name>

                  <children xsi:type="C_CODE_PHRASE">

                    <rm_type_name>CODE_PHRASE</rm_type_name>

                    <node_id />

                    <terminology_id>

                      <value>local</value>

                    </terminology_id>

                    <code_list>at0007</code_list>

                  </children>

                </attributes>

              </children>

            </attributes>

          </children>

          <children xsi:type="C_COMPLEX_OBJECT">

            <rm_type_name>PARTICIPATION</rm_type_name>

            <node_id />

            <attributes xsi:type="C_SINGLE_ATTRIBUTE">

              <rm_attribute_name>function</rm_attribute_name>

              <children xsi:type="C_COMPLEX_OBJECT">

                <rm_type_name>DV_CODED_TEXT</rm_type_name>

                <node_id />

                <attributes xsi:type="C_SINGLE_ATTRIBUTE">

                  <rm_attribute_name>defining_code</rm_attribute_name>

                  <children xsi:type="C_CODE_PHRASE">

                    <rm_type_name>CODE_PHRASE</rm_type_name>

                    <node_id />

                    <terminology_id>

                      <value>local</value>

                    </terminology_id>

                    <code_list>at0008</code_list>

                  </children>

                </attributes>

              </children>

            </attributes>

          </children>

          <cardinality>

            <is_ordered>false</is_ordered>

            <is_unique>false</is_unique>

            <interval>

              <lower_included>true</lower_included>

              <lower_unbounded>false</lower_unbounded>

              <upper_unbounded>true</upper_unbounded>

              <lower>0</lower>

            </interval>

          </cardinality>

</attributes>

 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110108/e7ffb3eb/attachment.html>

Reply via email to