Hi everybody, We need to provide information about the composer and the corresponding organization that was responsible for the treatment of the patient (which can be different from the healthcare facility where the treatment took place). To my understanding, this would require a party_identified f…

I would say, use (implement) openEHR Demographics - then problem solved :slight_smile: Perhaps an slightly tricky suggestion: you could also use FHIR practitioner refs, assuming that your external system is FHIR server which can handle Party/Practitioner-Organisation relations?

The question is if I would always like to have object representations of any participant or composer in such a service. For our use-case, this is just unnecessary overhead. How do you feel about allowing to add some extra properties like role and organization directly in a party or even introducing …

That’s also a suggestion/direction I can relate to. This suggestion is also related to some discussion we had in SEC about 2y ago.

Ah, I remember that. I think @ian.mcnicoll raised the topic. I would like to get some more opinions and then I’m happy to “adopt” the issue.

Yup - in a perfect world, we would reference back to the formal record, whether in openEHR demographics, or FHIR or … but in many circumstances this is just not possible, or doable within budget/ governance arrangements. So we end up having a need to add snippets of demographic information to the E…

[image] ian.mcnicoll: Yup - in a perfect world, we would reference back to the formal record, whether in openEHR demographics, or FHIR or … but in many circumstances this is just not possible, or doable within budget/ governance arrangements. So we end up having a need to add snippets of demogra…

Normally we want to avoid that. Perhaps we don’t have to take that decision, we just have to facilitate. Usually such large organisation may have a demographics or fhir service and the’ll go for optimal way, whereas other mat have a simplified infrastructure, with less data, and don’t mind the du…

The problem is that we also might receive data from outside the organization/EHR. Maintaining a correct and up-to-date external demographics/provider repo might not be feasible or desirable in this case, as we might not get proper identifiers for organizations or there is no shared list of value set…

[image] birger.haarbrandt: Its just a dirty real-world out there and openEHR needs to deal with that without punishing users. Well, the point isn’t to punish users, it’s just to avoid truly basic design errors, like uncontrolled copying. But I think the key thing is to work out the ‘real’ re…

Organization of a party within the EHR

Specifications Entity/demographics

thomas.beale (Thomas Beale) 16 June 2021 08:54 6

See this post, and the previous one in that discussion for a) a solution and b) reasons why we really don’t want to keep adding details into the PROXY_PARTY types.

Topic		Replies	Views
PARTY as 'regular' datatype Entity/demographics demographics	33	2058	23 November 2020
Additional 'Participations' metadata item RM rm	16	449	22 May 2024
Demographic archetypes for clinical record purposes Clinical demographics	43	2516	10 August 2023
Integration Information Model revamp RM fhir , iim	31	1280	14 August 2020
Why is the editor not opening ADL files? Clinical (archive)	41	9	5 April 2009
Timing in the real world, openEHR and FHIR Clinical fhir , time	23	1483	27 May 2020
Collaboration between programs and tooling vendors Specifications	17	618	25 October 2021
Atomik CDR and DDR website is online and demographic API proposal Tools	13	659	30 April 2023
Referring to demographic entities in data Entity/demographics	1	550	27 May 2022
Inconsistency in REST API Create EHR implementations -needs spec clarification? ITS	27	885	9 October 2024

Organization of a party within the EHR

Related topics