Modeling family members / next of kin participants and "other clinicians"

Pablo Pazos pablo.pazos at
Sun Mar 11 22:43:42 EDT 2018

Hi Thomas,

Thanks, I'm on 1.0.2. Looking at the PDF, in the UML the EVENT_CONTEXT has
participations. page 35

But in the HTML, the UML of EVENT_CONTEXT doesn't have participations, nor
health_care_facility (that are in the PDF UML).

The tabular view includes those attributes

My confusion was because I use the UML as reference and go to the tabular
definition when I need detailed info.

Should be fix the UML in the generated HTML?

I detected many errors in the generated HTML for 1.0.2. I like the HTML
more but I should go back to the PDF as the trusted source.


On Tue, Feb 27, 2018 at 6:37 PM, Thomas Beale <thomas.beale at>

> Hi Pablo,
> there is COMPOSITION.event_context.participations, of type
> List<PARTICIPATION> (see here
> <>).
> It seems to me that does what you need.
> - thomas
> On 20/02/2018 04:10, Pablo Pazos wrote:
> Hi,
> I'm checking on the RM 1.0.2 how to add information about family members
> (if the patient is a child or an elder), and maybe other clinicians that
> participate of an emergency care event (composition).
> In 1.0.2 the extra participations appear at the ENTRY level as
> docs/ehr/ehr.html#_entry_and_its_subtypes
> But it is not possible to add that kind of information at the COMPOSITION
> level
> docs/ehr/ehr.html#_overview_3
> I think a family member that participates through all the event should be
> linked at the COMPOSITION level, and maybe some clinicians and nurses also
> need to be at that level.
> 1. One idea is to use the EVENT_CONTEXT.other_context to add
> DV_IDENTIFIERs of DEMOGRAPHIC entities that represent family, clinicians,
> nurses, etc. But that is a little "hacky" since I want to reference
> DEMOGRAPHIC entities and DV_IDENTIFIERs are not for that, the reference
> should be PARTY_REF that is used from PARTY_PROXY, but can't add
> PARTY_PROXY to EVENT_CONTEXT.other_context because the RM doesn't support
> it, since PARTY_PROXY is not LOCATABLE.
> 2. Another idea is to add ADMIN_ENTRY and do the same there, also a little
> hacky and has the same problem with the RM types.
> 3. The third is to add all the participants to each ENTRY of the
> COMPOSITION, duplicating the same data by the number of entries.
> 4. An idea between 2 and 3 is to add a dummy ADMIN_ENTRY with no data,
> that includes the participants in the ENTRY.other_participants collection.
> --
> Thomas Beale
> Principal, Ars Semantica <>
> Consultant, ABD Team, Intermountain Healthcare
> <>
> Management Board, Specifications Program Lead, openEHR Foundation
> <>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <>
> Health IT blog <> | Culture blog
> <>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

Ing. Pablo Pazos Gutiérrez
pablo.pazos at
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list