# How to add reference to a person in the data structure **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2011-05-17 19:18 UTC **Views:** 15 **Replies:** 23 **URL:** https://discourse.openehr.org/t/how-to-add-reference-to-a-person-in-the-data-structure/12645 --- ## Post #1 by @Gediminas_Backeviciu 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. --- ## Post #2 by @system Hi! 2011/5/17 Gediminas Bačkevičius <[gediminas.backevicius@softdent.lt](mailto: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: 1. 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? 2. 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](mailto: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](mailto: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](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](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. --- ## Post #3 by @ian.mcnicoll 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](mailto:ian.mcnicoll@oceaninformatics.com) Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor [www.openehr.org/knowledge](http://www.openehr.org/knowledge) Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care [www.phcsg.org](http://www.phcsg.org) 2011/5/18 Erik Sundvall <[erik.sundvall@liu.se](mailto:erik.sundvall@liu.se)> --- ## Post #4 by @Gediminas_Backeviciu 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 --- ## Post #5 by @system 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 --- ## Post #6 by @ian.mcnicoll 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](mailto:ian.mcnicoll@oceaninformatics.com) Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor [www.openehr.org/knowledge](http://www.openehr.org/knowledge) Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care [www.phcsg.org](http://www.phcsg.org) --- ## Post #7 by @system 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 --- ## Post #8 by @system 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 --- ## Post #9 by @thomas.beale 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 --- ## Post #10 by @thomas.beale 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 --- ## Post #11 by @ian.mcnicoll 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](mailto:ian.mcnicoll@oceaninformatics.com) Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor [www.openehr.org/knowledge](http://www.openehr.org/knowledge) Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care [www.phcsg.org](http://www.phcsg.org) --- ## Post #12 by @system 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 --- ## Post #13 by @Gediminas_Backeviciu 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 --- ## Post #14 by @thomas.beale > ``` > 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 --- ## Post #15 by @ian.mcnicoll 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](mailto:ian.mcnicoll@oceaninformatics.com) Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor [www.openehr.org/knowledge](http://www.openehr.org/knowledge) Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care [www.phcsg.org](http://www.phcsg.org) 2011/5/20 Thomas Beale <[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)> --- ## Post #16 by @thomas.beale > 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](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140169202660_257304_813Report.html)) 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](http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140169202660_257304_813Report.html) for the UML of these classes. Note that PARTY_IDENTIFIED, a descendant of PARTY_PROXY, already has a List. 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 --- ## Post #17 by @thomas.beale 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 --- ## Post #18 by @Gediminas_Backeviciu Hi Thomas, I want to store such data in ADMIN\_ENTRY: --- ## Post #19 by @thomas.beale 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 --- ## Post #20 by @ian.mcnicoll 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 --- ## Post #21 by @system Hi Gediminas and All, My understanding of your problem is similar as Ian's interpretations\. Your original issue was that you wanted to display doctor's name in a table, but somehow you wanted to associate the doctor's reference via uid with each entry/a row so that the doctor's name can be resolved by the doctor's reference\. You may have known that displaying the data in a tabular format doesn't mean that the data must be recorded as a ITEM\_TABLE\. You can render the data from ADMIN\_ENTRY\.other\_participations and the data from the ADMIN\_ENTRY\.data in one table\. Cheers, Chunlan --- ## Post #22 by @Tim_Cook2 I think that this is a problem caused by the global educational systems\. Every domain analysis has to be thought of in tabular, SQL manner\. So the end result must be some kind of SQL form\. It is sad to know that this is caused by which companies fund researchers and therefore influence how and what they teach\. --- ## Post #23 by @system Dear Timothy, I don't agree with your statements\. There are some publications related to user interfaces on openEHR official website, which are not driven solely by company funded researchers\. On the other hand, separation of view model from data model is not an openEHR specific topic, e\.g\. Model\-View\-Presenter pattern and Model\-View\-Controller pattern have been used on various UI programming platforms\. Cheers, Chunlan --- ## Post #24 by @Gediminas_Backeviciu Hi Thomas, thank you for your response. I think will be the best choice to use DV_TEXT, because it's non-clinical data and related to legacy systems. I agree, we can go from here. Gediminas Bačkevičius --- **Canonical:** https://discourse.openehr.org/t/how-to-add-reference-to-a-person-in-the-data-structure/12645 **Original content:** https://discourse.openehr.org/t/how-to-add-reference-to-a-person-in-the-data-structure/12645