Constraints on Participation

Dear All

We are adding constraints on participation to the Archetype Editor. Participations can be recorded at two levels, the Composition and at the level of the Entry. Remember that the reference model knows who was the author of the composition - which is mandatory. There is a special participation on each entry called provider which is just the identification of the source of the information.

If we see archetypes as the shared maximal data set we never want to constrain something in a way that would mean other people collecting the same information would have to use another structure - this means we do not want to put any constraints in the archetype that might be use specific. All such constraints go into the templates where everyone can do as they wish (always keeping to the model expressed in the archetype). Archetypes are what we agree on to enable interoperability.

Attestation or signing is dealt with using another mechanism, so there is no need to bring that into this discussion.

The next release of the archetype editor will have a participations tab. At the level of the entry this will allow:

  1. The ability to make the provider of the information mandatory. While this is not a general requirement, in cases like consent and some other issues it is good to have this in a computable form rather than just as text - this is possible through the PARTY_PROXY which allows formal statements such as SELF, related parties with relationship and with or without identification and demographic identifier and also identified party again with or without demographic identifier. (I actually think this part of the openEHR model is extremely elegant but I am biased and it did take about 10 years to get to this point!)

  2. Add participations with occurrences set and possibly

  • restricted modes - this is an openEHR termset that describes the mode and includes telemedicine, written notes, email…and of course face to face.
  • function - this is a DV_TEXT and may be limited to a term set in an external terminology or build a termset within the archetype (internal codes). Both of these are unlikely at present in the archetype, but the time is coming. It does mean that for procedures we can have the operator, assistant etc if this is appropriate.
  • Force the date time interval of the participation to be recorded - ie make it mandatory as it is optional in the model.

Please have a look at the UML

http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140169202660_257304_813Report.html

Lets hear if there are any concerns…

Cheers, Sam

Dear All,
I checked out the OpenEHR UML model release 1.0.1 and assuming the it is target to clinician? please correct me if I am wrong. If this is not the case therefore the following message may be NOT irrelevant. HOWEVER, if it is!!? my sincere feedback is that:::: IT IS a complex model tool to get participation from the UML model. Since I found personally difficult to follow and I cannot see how the participative approach can be achieved with real ACTORS of these models .

Please treat this comment as an initial point of discussion:!!! ( or may be a very ignorant beginner: since I have deal with this space for the last couple of years only) and truly ; I want to understand and help clinicians to gain a strong view of the power of archetypes as a change agent for their health systems.

Cheers from Brisbane, Australia where the biggest congress in Medical Informatics is happening next week!!

Carol ( Spanish coordinator & embassor @ Medinfo)

Dr Carola Hullin Lucay Cossio

Dear Sam,

It is very nice for you to float this as a discussion topic before it is implemented, so that we can engage with you on the requirements/design aspects in advance.

Since the UML you reference is of the Reference Model, and means much to informaticians but not the other clinicians on this list, I wonder if it will help engage discussion if we collate a list of a few examples of archetype-level participants.

As you say, these are specific kinds of participants as opposed to the generic ones of committer, composer, information provider and attester.

As a starter, we might wish to discuss these suggestions:

anaesthetist for an operation note (COMPOSITION): mode: must be present in person
witness for a consent form (COMPOSITION): mode: must be present in person
parent/next-of-kin/carer for administration of a drug to a child (ENTRY): mode: must be present or by telephone (not e-mail)
information subject to be mandatory for family history kinds of information, and must be a relative (ENTRY): no mode restriction
consultant psychiatrist optional/mandatory for a mental health section (COMPOSITION): mode?
verifier/witness for a drug administration on the ward (ENTRY), mode: must be present in person

Is this the kind of archetype-level participation you had in mind?

With best wishes,

Dipak

Thanks Dipak

I will respond to your very helpful examples.

Since the UML you reference is of the Reference Model, and means much to informaticians but not the other clinicians on this list, I wonder if it will help engage discussion if we collate a list of a few examples of archetype-level participants.

As you say, these are specific kinds of participants as opposed to the generic ones of committer, composer, information provider and attester.

As a starter, we might wish to discuss these suggestions:

anaesthetist for an operation note (COMPOSITION): mode: must be present in person

Here the function would be the anaesthetist - the actual reference to the person uses party proxy (this means the person could be identified or be a demographic reference) and the mode (which is optional) might be limited to present in person until we have telemedicine anaesthetics.

witness for a consent form (COMPOSITION): mode: must be present in person

Here the mode would probably not be set in the archetype - but in a template it might be reasonable to do this if that is the only means of consent that is appropriate in a particular use environment.

parent/next-of-kin/carer for administration of a drug to a child (ENTRY): mode: must be present or by telephone (not e-mail)

This would be an instruction and may be recorded if the person is not present at the time as in Dipak’s example. Again, this will probably not be set in an archetype - but at template or in the application at the appropriate moment.

information subject to be mandatory for family history kinds of information, and must be a relative (ENTRY): no mode restriction

Here the information subject is a special type that is associated with all entries. In fact you are combining two separate concepts here. Any archetype can have the information subject set to a relative - so it is possible to say that someone’s father had alcoholism or their mother had breast cancer at the age of 15 using the problem EVALUATION. The family history in the archetype set is an evaluation of risk and is a separate archetype. Here the data subject is the person at risk. We have learned that in pregnancy it is necessary to say that the woman’s husband (he is the data subject) has a family history of Huntington’s Chorea. This will need to appear in the woman’s record in the case of obstetric care. So Family History (risk) can have the information subject set to SELF - that is the EHR subject has a family history of X and the relationships of affected parties (leading to the risk) is expressed within the archetype itself.

consultant psychiatrist optional/mandatory for a mental health section (COMPOSITION): mode?

Again, a template - but a good example. It might be a social worker but the list will be small.

verifier/witness for a drug administration on the ward (ENTRY), mode: must be present in person

This may be entered as a participation of the ACTION, but is probably best dealt with as an attestation of the action leading to an irrefutable signature.

Is this the kind of archetype-level participation you had in mind?

Very much so and thank you.

Sam