Hi everybody,
According to I_DEMOGRAPHIC_SERVICE party and relationships are two separate root aggregates. But in I_PARTY Interface we have to load party( get_party) with all relationships(based on party Demographic Rm) which causes performance problems. So, in my opinion it is better, load party with just ref list of relationships.
Do you confirm this idea or not?
Thanks
The PARTY contains only references (ref lists) indeed - see here.
The SM specs are in TRIAL state, but for Demographics domain I would see it more close to DEV rather than TRIAL, as we don’t have too much feedback from implementation yet, and neither is supported by our REST API specs. So considering this aspect, I would say the I_PARTY is correct, but I_DEMOGRAPHIC_SERVICE might have to be reviewed and changed if necessary (if proven to be not good enough).
1 Like
As Sebastian mentioned, remember this is work in progress.
1 Like
Hi Mehdi,
Am interested to know about the performance problem. If you look at the demographic RM, when you retrieve a Party, you will get only 1-st degree PartyRelationships; each PartyRelationship points to its target by reference (PartyRef) not by value. Or is it that you have Parties with very large numbers of relationships?
1 Like
I would also be interested in which implementation are you using, since the SM is an abstract / platform independent spec, still in the making, and the only implementation technology spec we have is the REST API.
Currently there is no corresponding REST API for I_DEMOGRAPHIC_SERVICE, that is why I’m intrigued about your implementation, and how that works, since we need to get feedback from anyone actually implementing those interfaces to be able to improve them in the near future.
For SEC members: we already mentioned on another thread, to work on the definition for the REST API (and maybe other APIs), and have matching SM interfaces, for extra services like demographic, terminology, audit log, etc.
3 Likes
At first, I have to say I am a designer, so I have to concern about all situations that possibly can happen.
In some situations, The numbers of relationship can be large.
Hi sebastian,
In my opinion,
when loading a party with large relationships the problem is details : ITEM_STRUCTURE and not target or source which are ref.
If you accept Party and Partyrelationship are two different aggregates, based on Domain Design, it is better to have get Party without whole relationships and just ref or even nothing.
if somebody needs both of them can apply AQL.
Thank you for your consideration.
Hi pablo,
thank you for your attention to this matter.
I am trying to design REST API for demographic based on my understanding of EHR API pattern . As soon as the project is done. we will share the information in openEHR website and put the demo link to get your useful feedbacks.
We could modify the model to do this - it would mean that PARTY objects have no knowledge of the relationships they are in - relationships are completely separate. I did think about using this approach a long time ago, but was never convinced by it adding enough utility for the annoyance (PARTY_RELATIONSHIP objects are after all, fairly lightweight objects).
But others might agree with this point of view, and indeed maybe we can demonstrate that it is better in a real system. It would not even require modifying the model, it would just mean deprecating the use of PARTY.relationships and PARTY.reverse_relationships, and documenting the fact that finding relationships for a given PARTY had to be done by querying the PARTY_RELATIONSHIP object repository.
I’m interested to know more about this - do you have some real situations with very large numbers of relationships?
Based on diversity of our system stakeholders, we should design scalable Demographic Data Repository(DDR) as a central service to cover many hospitals, polyclinic, clinics, and laboratories.
in this case, the number of relationships between a service provider as source with patients as a target will be more than a million records.
2 Likes
We (Code24) use the Demographic RM for many years now, having a separate repository for that; DDR sounds like I good abbreviation and complementary to CDR - I somehow did not heard it before, but like it!
One of our largest DDR (runs on-premise) has around 200.000 actors and about few million relationships. Those are being used by the source-PARTY’s version, but also persisted separately (cached). In order to have an optimal search functionality we use those cached relationships (internally, by the query engine) in a similar way as the containment of AQL but not via separate and dedicated api calls. We basically search and fetch PARTYs (or parts of them) matching given relation-conditions, but not the relation itself (as that can be found in the source PARTY).
From our point of view and experience, the current Demographic RM spec is workable in a real life architecture/system. The details are just implementation aspects and may vary between solutions. What we miss are specs on REST & AQL using this RM - which is why I’m usually promoting this topic on SEC. Hopefully we’ll be able to address them in upcoming months. So your work/research/feedback on DDR is also interesting for us.
3 Likes