How to add reference to a person in the data structure

Implementers (archive)
1

Is there a possibility to add a reference to a person in the data structure, for example, in ITEM_LIST? For now i can only add DATA_VALUE in this list.

I viewed some archetypes in OpenEHR knowledge base and found some examples: there were added CLUSTER ‘Refferring doctor’ with three ELEMENTS: ‘ID’, ‘Family name’ and ‘Last name’(openEHR-EHR-ADMIN_ENTRY.admission.v1). How should it look in the UI?

I want to allow user to select person from list or from auto completion box but not to alllow to enter person ‘id’,’ lastname’, ‘firstname’ by hand.

2

Hi!

2011/5/17 Gediminas Bačkevičius <gediminas.backevicius@softdent.lt>

Is there a possibility to add a reference to a person in the data structure, for example, in ITEM_LIST? For now i can only add DATA_VALUE in this list.

This is an interesting question! What is the best way to refer to persons within an ITEM_STRUCTURE? Some further questions/thoughts:

Background: DV_EHR_URI is a possible DATA_VALUE, also all ITEMs in an ITEM_STRUCTURE inherit from LOCATABLE and can thus have LINKs pointing to DV_EHR_URIs.

Questions: Can such an URI point to instances from the demographic package or to PARTY_PROXY-related instances, and how would the URI then look?

Background: The children of PARTY_PROXY seem to be perfect for safely referring to persons in data. They are probably better suited than a DV_EHR_URI for this purpose. The archetype openEHR-EHR-COMPOSITION.referral.v1 shows examples of archetyped references to PARTY_PROXY via EVENT_CONTEXT via PARTICIPATION, but that is for the whole composition not at the ITEM or DATA_VALUE level.

Questions: Is there any way to get a PARTY_PROXY into some DATA_VALUE descendant? Is there a need for a new DATA_VALUE subclass that can encapsulate/contain a PARTY_PROXY descendant?

2011/5/17 Gediminas Bačkevičius <gediminas.backevicius@softdent.lt>

I viewed some archetypes in OpenEHR knowledge base and found some examples: there were added CLUSTER ‘Refferring doctor’ with three ELEMENTS: ‘ID’, ‘Family name’ and ‘Last name’(openEHR-EHR-ADMIN_ENTRY.admission.v1). How should it look in the UI?

In openEHR-EHR-ADMIN_ENTRY.admission.v1 things that really could belong in the demographic model are copied into the archetype using DV_TEXTs. Is that really a good idea? The PARTY_IDENTIFIED class already contains all needed elements that have been copied by the archetype authors to e.g. the fields under Referring Doctor and Consulting Doctor. If software is going to process that info it would be much nicer to use the PARTY_IDENTIFIED class instead of having the fields defined differently in different archetypes.

2011/5/17 Gediminas Bačkevičius <gediminas.backevicius@softdent.lt>

I want to allow user to select person from list or from auto completion box but not to alllow to enter person ‘id’,’ lastname’, ‘firstname’ by hand.

Could you tell us a bit more about your project? It sounds interesting.

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

P.s. CC to some archetype authors, since I don’t know if you follow the implementation list.

3

Hi Gedeminas,

The ‘linking’ of Demographic entities to an openEHR EHR is not a simple topic, as Erik suggested in his reply. I think part of your difficulty is that openEHR defines an information model, wheras you are thinking of it in terms of driving the GUI - sometimes, indeed often) these two requirements marry up nicely but this is not always the case.

In general, the linkages are handled at COMPOSITION or ENTRY level via PARTY_PROXY classes in attributes such as provider, composer, subject and participations. When building an EHR this works pretty well but can be difficult to document or map cleanly to messages. but a lot depends on the kind of Demographic information you are trying to display.

As Erik suggests, it would be helpful if you could give some concrete examples of your use cases e.g What is the context of wanting to add demographic links and who are these ‘persons’ -patient, professionals, personal carers, other third parties, will they have formal Identifiers with actual details stored in an external demographics database or service?

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

2011/5/18 Erik Sundvall <erik.sundvall@liu.se>

4

Hi,

I need to create a form which filled by a doctor or other medical staff. This form is related to patient but it dedicated for social insurance. Thus, it is non-clinical information which is why I use ADMIN_ENTRY to this information.

This information consists of a table which has these columns: date, doctor, service code, disease code, comment, etc. I want to store this information in ITEM_TABLE data structure.

As you can see I need to allow to assign many different doctors. In UI I want to display doctor’s firstname and surname while in the background I want to store person’s uid. I am thinking how to implement it…

In other situations I use PARTY_PROXY via PARTICIPATION. Depending on the constraint(C_COMPLEX_OBJECT), which describes subject or particiation performer, in UI I generate autocompletion box (for partly restricted constraints when only party type is defined in the constraint) or drop-down of party objects (for highly restricted constraints which result in less than ten values or something like that).

Gediminas Bačkevičius

5

Hi Gediminas,

I agree with using ADMIN_ENTRY for this information. Looks like you have separate doctor records and you want to store doctor’s uid in the ADMIN_ENTRY, but doctor’s name needs to be displayed in the UI. I personally would use the ADMIN_ENTRY.other_participants. The reasons are that 1) it allows you to store the uid via PARTY_PROXY.external_ref, 2) it allows you to store doctor’s name and other identifiers if it is required, 3) it also allows you to store the time interval. It means that you don’t need to use uid to retrieve the doctor’s name every time when you display the record, so that it makes less dependency on your doctor’s records. The disadvantage is that you need to think about how to synchronize the ADMIN_ENTRY data with doctor’s records, e.g. do you need to update all ADMIN_ENTRY data when there are changes to doctor’s records. If this is an issue, you can actually choose to not populate doctor’s name in the ADMIN_ENTRY.

If you have separate patient’s demographic records, I would suggest to use ADMIN_ENTRY.subject to store the patient’s uid via PARTY_PROXY.external_ref.

The comments, service code, and disease code might go to the ADMIN_ENTRY.data.

Thoughts?

Cheers,

Chunlan

6

Hi Gediminas,

I would agree with Chunlan’s suggestions. I am curious why you want to use an ITEM_TABLE structure. 99% of the archetypes we develop have an ITEM_TREE structure which gives maximum future flexibility. ITEM_TABLE is, in theory, useful for a small number of cases such as Eye examination with a fixed repeating pattern e.g Left Eye / Right Eye but in practice we have found most actual use cases require a more complex ITEM_TREE. In your case an ITEM_LIST might be sufficient but I would strongly recommend using an ITEM_TREE which allows for more flexibility in the future with no real overhead.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

7

Hi!

The disadvantage is that you need to think about how to synchronize the
ADMIN_ENTRY data with doctor’s records, e.g. do you need to update all
ADMIN_ENTRY data when there are changes to doctor’s records.

Could you elaborate a bit more on this? If you have a versioned
demographic database with doctor info etc, I assume that you would
(via PARTY_PROXY.external_ref) point to the PARTY version that is
current at the time of submit. If changes are made later to any part
of the system, that should not affect already recorded data, should
it?

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

8

Hi Erik,

I suggested to store doctor's name and uid via
ADMIN_ENTRY.other_participations. Therefore, the doctor's name is part of
ADMIN_ENTRY instance. If there are any changes to doctor's record (e.g.
changes to the doctor's name), the ADMIN_ENTRY instance may need to be
updated. However, it really depends on how the ADMIN_ENTRY instance is
persisted and created. If the ADMIN_ENTRY instance is persisted as an XML
blob/document, data synchronization must be considered. However, if the
PARTICIPATION.performer (part of ADMIN_ENTRY.other_participations) data is
always retrieved from the doctor's record, then don't need to worry about
the data synchronization with the doctor's record. The latter approach means
the ADMIN_ENTRY instance data is stored in different storage. It requires
extracting data from different storage when an ADMIN_ENTRY instance is
requested. It may or may not be easy depend on the entire system
architecture.

Hope it makes sense to you.

Cheers,
Chunlan

9

that is correct. However lots of people want to include some demographic
information in the EHR Compositions (which they can do in a limited way,
using PARTY_IDENTIFIED (which also has the inherited external_ref link
as well). WHat Chunlan is saying is that if you put too much direct
demographic info into numerous Compositions of the EHR they won't
provide the correct view if some of those details change. This is true
in one sense, i.e. that the information, retrieved much later might not
reflect today's reality (e.g. let's say Dr Jones has become Dr Stevens,
due to marriage & name change), but on the other hand it is
medico-legally correct - when the original data were committed, there
was no 'Dr Stevens' associated with it, it was someone called 'Dr
Jones'. Following the external_ref link is the only way to
(potentially) get through to some managed record of the Dr Jones/Stevens
person and find out their current details.

- thomas

10

Hi Gediminas,

I agree with using ADMIN_ENTRY for this information. Looks like you have separate doctor records and you want to store doctor’s uid in the ADMIN_ENTRY, but doctor’s name needs to be displayed in the UI. I personally would use the ADMIN_ENTRY.other_participants. The reasons are that 1) it allows you to store the uid via PARTY_PROXY.external_ref, 2) it allows you to store doctor’s name and other identifiers if it is required, 3) it also allows you to store the time interval. It means that you don’t need to use uid to retrieve the doctor’s name every time when you display the record, so that it makes less dependency on your doctor’s records. The disadvantage is that you need to think about how to synchronize the ADMIN_ENTRY data with doctor’s records, e.g. do you need to update all ADMIN_ENTRY data when there are changes to doctor’s records. If this is an issue, you can actually choose to not populate doctor’s name in the ADMIN_ENTRY.

If you have separate patient’s demographic records, I would suggest to use ADMIN_ENTRY.subject to store the patient’s uid via PARTY_PROXY.external_ref.

The comments, service code, and disease code might go to the ADMIN_ENTRY.data.

Thoughts?

Cheers,

Chunlan

11

Hi Thomas,

In theory you are correct but in practice I doubt that the medicolegal requirement would stretch to enforcing the name change of the doctor from that which was originally recorded. That ‘was’ the correct name at the time and the current details are still available via the ID.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

12

Hi!

...However lots of people want to include some demographic
information in the EHR Compositions (which they can do in a limited way,
using PARTY_IDENTIFIED (which also has the inherited external_ref link
as well).

Getting back to some of the previous questions:

Do you have any thoughts regarding how to point to a PARTY_IDENTIFIED
(or other demographic instances), via an ITEM or DATA_VALUE? Is it
possible? It might be useful not only for persons, but also for
devices etc that may be better modeled as versioned demographic
instances rather than having a lot of not-clinically-relevant data
copied into every composition where they have been used?

Or is it enough to add e.g. devices via ENTRY.other_participations? Or
is a combination useful - real external_ref link via
other_participations and a repetition of one of it's identifiers down
at DATA_VALUE level using a DV_TEXT, DV_EHR_URI or similar? A somewhat
standardised design pattern might be useful in that case in order for
software to make the connection between the DATA_VALUE encapsulated
identifier and the participation.

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

13

Hi,

In my opinion it's worthless to store party in ENTRY.other_participations and then to
try to link it to DATA_VALUE. It should be enough to store it in DATA_VALUE. As I can see it's
impossible to implement it directly.

Can I store person's name to DV_TEXT and assign it to ELEMENT.value and also add a LINK to ELEMENT
which will refer to the person (from DV_EHR_URI which is stored in link I can parse party type and uid)?

Gediminas Bačkevičius

14 
Getting back to some of the previous questions:

Do you have any thoughts regarding how to point to a PARTY_IDENTIFIED
(or other demographic instances), via an ITEM or DATA_VALUE? Is it
possible? It might be useful not only for persons, but also for
devices etc that may be better modeled as versioned demographic
instances rather than having a lot of not-clinically-relevant data
copied into every composition where they have been used?

at the moment you can’t bury a PARTY_IDENTIFIED inside an ENTRY in openEHR; you can however put as many as you like in the other_participations property, both at ENTRY and COMPOSITION level. I am not sure if I have heard a convincing case for needing a PARTY_PROXY / PARTY_IDENTIFIED inside an ENTRY - are there real use cases?

One thing you can do, that does occur fairly often in ADMIN_ENTRY is to use DV_IDENTIFIER to record someone’s driver’s license, veteran’s number, or in fact any id at all, including prescription ids.

Or is it enough to add e.g. devices via ENTRY.other_participations? Or
is a combination useful - real external_ref link via
other_participations and a repetition of one of it's identifiers down
at DATA_VALUE level using a DV_TEXT, DV_EHR_URI or similar? A somewhat
standardised design pattern might be useful in that case in order for
software to make the connection between the DATA_VALUE encapsulated
identifier and the participation.

I can’t disagree with any of the above, but again I would like to see a really solid requirement before creating a CR for the openEHR RM.

  • thomas
15

Hi Thomas,

This is something we have struggled with in various projects.

Probably the most important reason for allowing PARTY_REFs to be carried within an ENTRY is that it makes the modellng much more explicit. I don’t think Gedeminas’ use case is a particularly good example, but I am guessing that what he needs to record is the responsible clinician from an insurer perspective, which may well not be the composer or ENTRY provider i.e is the senior clinician.

This can be easily modelled under ‘other_participations’ with function “Responsible clinician” as has already been suggested, but it is
quite possible that other information, related to the responsible clinician is carried within the ENTRY, perhaps within a cluster, so ideally we might have …

e.g.
Responsible Clinician detail
Responsible clinician PARTY_REF
Responsible clinician has been informed? BOOLEAN
Datetime responsible clinician informed.

The use of participation makes the modelling intent more obscure, although better tooling would probably help here.

There are other circumstances where using other_participations is more semantically problematic. A good example is in lab tests where dfifferent labs are responsible for the processing of individual analytes, which is not uncommon.

This also raises a related problem in that in can be difficult to model, at archetype level, the possible range of potential identifier/referencing mechanisms that will be required operationally e.g. for a lb test, some entities (like responsible laboratory) will be identified variously via an identifier, a simple text string, or perhaps a PARTY_REF, depending on the exact circumstances of use. It would be helpful to have some sort of generic construct that would allow precise contraint at template level or run-time, otherwise we are forced to archetype a variety of reference/identifier methods which is clumsy.

The final niggle with demographics is that, again depending on circumstances, some entities may need to be explicitly modelled within the Entry e.g. brief demographic details of a third party observer. This is one of the reasons why we have a set of EHR model demographics cliuster archetypes. The problem is that we cannot predict whether implementers will want to use formal demographics PARTY_REFS or informal EHR clusters, as this will vary according to local and national policy.

So my suggestion would be an archetypable demographics construct that allows

  1. Current PARTY_REF links to formal demographics
  2. DV_IDENTIFIER
  3. Archetyped local demographics i.e plug ins of EHR model demographics clusters.

This would allow us to model demographics simply and consistently without having to be concerned about exact local implementation requirements.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org

2011/5/20 Thomas Beale <thomas.beale@oceaninformatics.com>

16

Hi Thomas,

This is something we have struggled with in various projects.

Probably the most important reason for allowing PARTY_REFs to be carried within an ENTRY is that it makes the modellng much more explicit. I don’t think Gedeminas’ use case is a particularly good example, but I am guessing that what he needs to record is the responsible clinician from an insurer perspective, which may well not be the composer or ENTRY provider i.e is the senior clinician.

This can be easily modelled under ‘other_participations’ with function “Responsible clinician” as has already been suggested, but it is
quite possible that other information, related to the responsible clinician is carried within the ENTRY, perhaps within a cluster, so ideally we might have …

e.g.
Responsible Clinician detail
Responsible clinician PARTY_REF
Responsible clinician has been informed? BOOLEAN
Datetime responsible clinician informed.

wouldn’t this extra information go in the protocol?

The use of participation makes the modelling intent more obscure, although better tooling would probably help here.

There are other circumstances where using other_participations is more semantically problematic. A good example is in lab tests where dfifferent labs are responsible for the processing of individual analytes, which is not uncommon.

This also raises a related problem in that in can be difficult to model, at archetype level, the possible range of potential identifier/referencing mechanisms that will be required operationally e.g. for a lb test, some entities (like responsible laboratory) will be identified variously via an identifier, a simple text string, or perhaps a PARTY_REF, depending on the exact circumstances of use. It would be helpful to have some sort of generic construct that would allow precise contraint at template level or run-time, otherwise we are forced to archetype a variety of reference/identifier methods which is clumsy.

it seems to me that PARTY_IDENTIFIED (UML) does what is required here - you can include or not the external_ref, you can include or not any number of DV_IDENTIFIERs and String names…

The final niggle with demographics is that, again depending on circumstances, some entities may need to be explicitly modelled within the Entry e.g. brief demographic details of a third party observer.

but that doesn’t require any kind of PARTY_REF, that is just data is it not?

This is one of the reasons why we have a set of EHR model demographics cliuster archetypes. The problem is that we cannot predict whether implementers will want to use formal demographics PARTY_REFS or informal EHR clusters, as this will vary according to local and national policy.

So my suggestion would be an archetypable demographics construct that allows

Technically the solution might be something like DV_PARTY_REF or DV_PARTICIPATION, a new data type to wrap either PARTY_REF, or PARTICIPATION (which itself wraps PARTY_REF). See here for the UML of these classes. Note that PARTY_IDENTIFIED, a descendant of PARTY_PROXY, already has a List<DV_IDENTIFIER>.

But I am not yet convinced that PARTY_REFs need to be buried in the data rather than included in other_participations… for example, in the example of multiple labs doing one analysis - it must be true that one lab or organisation takes responsibility for the entire result, since the requsting organisation has to have a business relationship as well as technical system interface with a single organisation. I.e. ultimately 1 order = 1 response. If the lab outsourced from work to other labs, then I would think that the name of that lab (if of any interest at all) would appear next to each analyte, with the main reference to that lab being in the other_participations; you are not going to repeat details of that lab in each occurrence in the data?

Other question: let’s say there was the possibilty to include PARTY_REFs or PARTICIPATIONs within the data; should the same participations / references appear in the other_participations list as well? I have the feeling that the underlying requirement for data design here is not yet clear…

  • thomas
17

that is likely to be too complicated for most software to understand; I
would suggest you use a DV_IDENTIFIER, but see my other post. I am not
clear that your problem isn't solved by using other_participations.,

- thomas

18

Hi Thomas,

I want to store such data in ADMIN_ENTRY:

19

Gediminas.

based on this, my questions would be:

  • is this list created once per patient episode of care? I.e. once per hospital admission / discharge or GP visit? I don’t understand the ‘end of month’ part…

  • is this the list of doctors who saw the patient during an episode, or what is the basis of the grouping?

  • such lists presumably get repeated a lot - => If so, much of the same data are being repeated all the time. Do you want the keys “Mantas X” etc to be able to be resolved to some real data, or is just this name good enough? (Maybe just the name is good enough…)

  • is there any registry containing information on “Mantas X”, “Jonas Y” and so on? Is there a need for the data in this form to point to that data?
    The simplest solution is simply to record the names and other items as DV_TEXTs etc. Let’s take this as the default solution until a requirement is described that shows it is inadequate.

can we go from here?

  • thomas
20

Hi Thomas,

I interpreted the requirement as being an end of month report from a
group of primary care providers to the paying authority of episodes of
care delivered. If I understand Gediminas' original intention to model
this as item_table correctly, he was goingto create a single
ADMIN_ENTRY for each monthly report.

I would model this a little differently, using a separate ADMIN_ENTRY
for each clinical episode

Use other_participation to record the physician name and identifier
via PARTY_IDENTIFED and the period of involvement

other_p

Cary 'Code' (which I guess is some kind of type of clinical service
code?) and Comment in the archetype

So the report being returned would be something like

COMPOSITION "Encounters report"
context/start_time = "20101030"
{
   ADMIN_ENTRY "Encounter admin"
     {
     other_participations/performer/name = "Mantas X"
     other_participations/performer/identifiers[0]/id = "123-456-789"
     other_participations/performer/identifiers[0]/issuer = "uk.nhs.scot"
     other_participations/performer/function = "Responsible clinician"
     other_participations/performer/time/lower = "20101012"
     other_participations/performer/time/upper = "20101012"

     data/[[at0001| Episode Code |]/defining_code = "5"
     data/[[at0002| Comment |]/value = "Some comment"
     }
   ADMIN_ENTRY "Encounter admin"
     {
      other_participations/performer/name = "Jonas Y"
      other_participations/performer/identifiers[0]/id = "345-567-890"
      other_participations/performer/identifiers[0]/issuer = "uk.nhs.scot"
     other_participations/performer/function = "Responsible clinician"
     other_participations/performer/time/lower = "20101014"
     other_participations/performer/time/upper = "20101014"

     data/[[at0001| Episode Code |]/defining_code = "4"
     data/[[at0002| Comment |]/value = "Some other comment"
     }
     etc, etc.
}

Please note this is not valid openEHR instance data, it is an rough
approximation.

I think this does highlight the problem that it is currently more
difficult than it should be to document the use of openEHR rm
attributes in specific use cases, particularly for messaging
definitions. We are currently doing somw work for CKM to make key
clinical/developer rm attributes more visible.

Ian

Dr Ian McNicoll
office +44 (0)1536 414 994
+44 (0)2032 392 970
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org