# RM Participations name/role? **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2016-11-23 13:29 UTC **Views:** 7 **Replies:** 15 **URL:** https://discourse.openehr.org/t/rm-participations-name-role/15556 --- ## Post #1 by @siljelb Hi, We’re wondering if it’s possible to specify what the role was of each instance of Participation in an OBSERVATION archetype? For instance in a histopathology result the macroscopic description will often be performed by a different person from the microscopic description. We’re thinking both will be listed using participation, but we need to be able to document which person did what. Kind regards, **Silje Ljosland Bakke** Information Architect, RN Coordinator, National Editorial Board for Archetypes National ICT Norway Tel. +47 40203298 Web: [http://arketyper.no](http://arketyper.no/) / Twitter: [@arketyper_no](https://twitter.com/arketyper_no) --- ## Post #2 by @system Hi Silje, The [PARTICIPATION class](http://www.openehr.org/releases/RM/latest/docs/common/common.html#_overview_3) has a codable attribute 'function' for this purpose (calling it 'function' rather than 'role' came from 13606). It may be that you want to state a 'role' as well, i.e. to say that a certain *kind of person* is required, and then use function to state the actual function that person is supposed to do in the particular activity in question. I would have expected 'function' to be sufficient for your example - just use 2 x other_participations on the OBSERVATION. An example of needing both could be something like: - role = nurse - function = foley catheterisation Currently 'role' is only known in the demographic model, i.e. on the other side of the PARTY_PROXY.external_ref link. It may make sense to add a role attribute to PARTICIPATION at some point if we need to distinguish the type of person (qualification) from what they do in the activity. - thomas --- ## Post #3 by @system Hi both Agreed. Role = pathologist Function = macroscopic histopath examination. Ian. --- ## Post #4 by @system Ok, sounds like a new need ... Ian, do you want to check if there's a PR for that, and if not, add one? This might even be doable in the next release. - thomas --- ## Post #5 by @system Hi, I'm not sure if this is a correct approach. What in the example you call a function can be in fact a full Action that is being done. That is, if the function is so relevant that you can even assign a dedicated participant to it, it should be also enough important to be represented and documented as an individual entry of the EHR: coded, with start and end times, etc. If the case is that a complex procedure is composed by other simpler procedures, then we should document and link all of them. I see the case of Silje from a different perspective. What she is asking is if we can document the participants of each Element inside the Entry. So far this is not possible, as Entries have been always seen as a whole clinical statement, with all participants assigned to that level. --- ## Post #6 by @system Hi David, I think your approach is perfectly valid but I suspect would impose an overhead of complexity that is not always justified or necessary. In the original lab system the kind of individual entry tracking you suggest is probably required to facilitate workflow but by the time it hits the ehr, that level of granularity is not needed IMO. Another good example of the way the health data is summarised and compressed as it passes through the system. Both approaches are valid IMO. Ian --- ## Post #7 by @system My understanding: Roles are characteristics of an entity (person, device) Functions are characteristics of a service/process I agree with David. The Statement (ENTRY) defines who is involved in that statement. Problem: A Statement is the documented result of a process (Observing, Assessing/Inferencing, Planning, Ordering, Executing) How to model a Panel/Bundle is documented in a Statement? (e.g. Chem 7 panel, Apgar score, Blood count, Long function, etc.) Each of the items in the Panel theoretically can be executed by a different participant. Gerard --- ## Post #8 by @siljelb Hi, thanks for your replies everyone! I think the function attribute is sufficient for our use case, as the focus is on what the person did. Their profession/credentials can be provided by an external knowledge base. BTW, I tried looking this up using the UML link from the CKM, which led me here: [http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_0_76d0249_1109066119163_537311_2210Report.html](http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_0_76d0249_1109066119163_537311_2210Report.html). I then tried to follow the List link to [http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_5_76d0249_1118914287896_171737_4134Report.html](http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_5_76d0249_1118914287896_171737_4134Report.html), which gave me a 404. Mvh. **Silje** --- ## Post #9 by @system Silje, It may be true that it is sufficient for your use case\. In principle there are two methods to deal with information in the EHR: \-1\- In the COMPOSITION the data is referenced by a code/url because it is in a shared Repository \-2\- In the COMPOSITION all data needs to be made available explicitly, when used in a message/document where the receiver has no access to the shared Repository\. This means that the generic Archetype needs to support these two possibilities where in the Template for a particukar use case one of the methods is implemented Gerard --- ## Post #10 by @system Thanks Silje, Good to know the existing model covers your use case but I am reminded of a previous request to add 'Role' to PARTY_IDENTIFED to allow the exact role of the party to be recorded in a particular context, where clinicians often have multiple roles e.g. GP, out of hours clinician. Ian . --- ## Post #11 by @system Thanks Silje, Good to know the existing model covers your use case but I am reminded of a previous request to add 'Role' to PARTY_IDENTIFED to allow the exact role of the party to be recorded in a particular context, where clinicians often have multiple roles e.g. GP, out of hours clinician Ian . --- ## Post #12 by @system Hi David, > Hi, > > I'm not sure if this is a correct approach. What in the example you call a function can be in fact a full Action that is being done. That is, if the function is so relevant that you can even assign a dedicated participant to it, it should be also enough important to be represented and documented as an individual entry of the EHR: coded, with start and end times, etc. If the case is that a complex procedure is composed by other simpler procedures, then we should document and link all of them. I think that argument is generally correct, but what we see implementers (i.e. their customers) wanting is extremely variable across specialties, institutions and settings. For example, a lot of simple procedures require a simple IV cleaning sub-procedure. It's easy to imagine one institution wants all the steps fully modelled and to create detailed actions in the EHR, and another just wants to treat it as a single action that can be signed off. > I see the case of Silje from a different perspective. What she is asking is if we can document the participants of each Element inside the Entry. So far this is not possible, as Entries have been always seen as a whole clinical statement, with all participants assigned to that level. From a realist perspective, the phrase 'participants of an Element' doesn't completely make sense - an Element is just an atom of information that is part of something else. You can only participate in an 'activity' (an Activity that has been performed in openEHR is an Action; an activity that generates information is usually an Observation, with the protocol part indicating how it was done), and to express the activity generally takes 1..N Elements in some sort of structure, including timing etc. If two different activities are being reported inside the same Entry, there are two possible conclusions: 1. it should really be two Entries 1. they are just considered detailed items within the larger activity documented by he Entry. I think we need to be more careful on the meanings of the primitives in the RM - in any RM in fact - they are regularly abused within all RMs I see, including CDA, FHIR, even HL7v2. It always seems OK from a human perspective, but we say good-bye to computable information when we do that. - thomas --- ## Post #13 by @system That was exactly my point ;\-\) I was not advocating for including participations at the ELEMENT level\. On the contrary, I was remembering that it can only be done at the ENTRY level\. In the case of Silje, the histopathology findings archetype that can be found at the CKM is a CLUSTER \( http://www.openehr.org/ckm/#showArchetype_1013.1.2680). So, it is not possible to add there the participation information to inform about who did the macro or micro findings as she wanted\. The alternative I proposed without modifying the current RM is, as you also said, to create two different ENTRYs\. --- ## Post #14 by @siljelb The Histopathology findings archetype was made a cluster this week. It used to be an OBSERVATION specialised from Laboratory test. J Mvh. **Silje** --- ## Post #15 by @system David, sorry, you are right, I misread you. As usual, you were writing precisely, and I was reading imprecisely ;) - thomas --- ## Post #16 by @system and is always intend to be used inside an OBSERVATION\.laboratory\_test archetype \(example template in preparation\!\) \- which is where the participations would sit\. @David \- I agree with Thomas here\. Whilst your suggestion is 'absolutely' correct, and where monitoring the laboratory procedure is vital, then it is entirely appropriate to use an Observation and Action archetype but for most lab reporting situations this is over\-complex, and the requirement is to document who was involved in the observing, and not in the process\. Ian Dr Ian McNicoll mobile \+44 \(0\)775 209 7859 office \+44 \(0\)1536 414994 skype: ianmcnicoll email: ian@freshehr\.com twitter: @ianmcnicoll Co\-Chair, openEHR Foundation ian\.mcnicoll@openehr\.org Director, freshEHR Clinical Informatics Ltd\. Director, HANDIHealth CIC Hon\. Senior Research Associate, CHIME, UCL --- **Canonical:** https://discourse.openehr.org/t/rm-participations-name-role/15556 **Original content:** https://discourse.openehr.org/t/rm-participations-name-role/15556