RequestGroup discussion

[bdc-ehealth]

WG:
After alignment with the VIDIS project (and if they agree):

1. We would like to use a RequestGroup to group requests, even if there is only one request at this moment.
2. If requests in a RequestGroup do not have a temporal/causal relationship, they should also be grouped in a RequestGroup.

RequestGroup or other resource with a similar name.

Please add relevant usecases to the Google doc here: https://docs.google.com/document/d/1s2GNrXXWd5jDZT9ZyEIE54N1VC6Ukz8Fv18LWy6XNh8/edit

[bdc-ehealth]

related to #183

[costateixeira]

We have a negative answer now, so we have time to regroup.
Suggest to close this and reopen a clean discussion.

[bdc-ehealth]

This is getting too difficult for me... Baseline for me: we still have no solution.

[costateixeira]

Please put it in the agenda, I'll clarify

…

On Thu, 24 Nov 2022, 15:18 Bart Decuypere (eHealth), < ***@***.***> wrote: This is getting to difficult for me... Baseline for me: we still have no solution. — Reply to this email directly, view it on GitHub <#190 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3HUUBPJ6EQ5RXBM6KFWPDWJ52MZANCNFSM6AAAAAASDQLN6M> . You are receiving this because you were assigned.Message ID: ***@***.***>

[bdc-ehealth]

WG: we decide to continue using the RequestGroup, and we are conscious of the fact that we deviate from the recommendation of the norm. This has no technical impact on the servers.

[bdc-ehealth]

@MatonAnthony

[13:16] Anthony Maton (Smals)
Just a note #190 (comment)

If the "servers" you refer to is UHMEP, it has an impact.

Maintainability when we will want to align with the standard (which will happen)Increased complexity to manage those case where all of that RequestGroup is useless (which is a specific that will come with its set of rules)Increased storage of data
It's not "simpler" like people seems to think, it's added complexity.

[bdc-ehealth]

WG: Hans will go back to his team to see whether they agree with Anthony's opinion. Anthony will send his slides to the WG.
HL7BE_WG_RequestGroup.pptx

[bdc-ehealth]

Feedback by Hans and Anthony:

Hello Bart,

Beneath you can find our correspondence about the RequestGroup – ServiceRequest.

So we can agree with the approach of Anthony which is in line with HL7 if we can easily fetch the RequestGroup for a ServiceRequest.
We can discuss this further in the WG.

Met vriendelijke groeten,
Cordialement,
Kind regards,

Hans De keersmaecker
Product owner
 
Luchthavenlaan 25A

1800 Vilvoorde (Belgium)

www.corilus.be

From: anthony.maton@smals.be anthony.maton@smals.be
Date: Thursday, 15 December 2022 at 14:10
To: Hans De Keersmaecker hans.dekeersmaecker@corilus.be
Subject: RE: HL7 Belgium WG referral - biweekly meetings
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hello Hans,

We can talk about it before the meeting. I can free anytime that works for you before the meeting, just send me an invite that works for you.
For us there should never be a ServiceRequest in multiple RequestGroup, we never received any usecase going in that direction, so unless this business case appears it’s not taken in account in our proposal.

We can probably provide a search parameter to allow to find RequestGroup containing a specific ServiceRequest

Sincerely,
Anthony

From: Hans De Keersmaecker hans.dekeersmaecker@corilus.be
Sent: Thursday, 15 December 2022 13:50
To: Anthony Maton (SMALS) anthony.maton@smals.be
Subject: Re: HL7 Belgium WG referral - biweekly meetings

Hi Anthony,

The solution of slide 2 was not how we had it in mind.

If you create ServiceRequestB that has a relationshipB, we wouldn’t create RequestGroupB.
We would immediately add it to requestGroupA with the correct relationship.

Of course, if you didn’t know that there was a relationship and they were created before with ServiceRequestA-RequestGroupA and ServiceRequestB-RequestGroupB and you need to add the relationship. You must move ServiceRequestB to requestGroupA and you can remove requestGroupB (or visa versa).

In the example that we don’t create requestGroup/ServiceRequests.
What we see as difficulty is that we must call both requestGroups & ServiceRequets in order to make changes.
You don’t have 1 call to fetch all information, which can be the case if the Groups are always created.

In your example: you create ServiceRequest A at first. Then you create ServicRequest B. If you want to add a relationship between ServiceRequest B & ServiceRequest A. You fetch A, you first ask for all requestgroups that contain A. You must perform the same for B. We hope that we don’t need to fetch all Groups to do this. And then you must see if a group was created by somebody else for them, this may or may not be the case and how to link them.
If we won’t need to fetch all groups to identify that a ServiceRequest is added to them. But we can immediately fetch the RequestGroup for the ServiceRequest, we think the new solution will also work.

If you want to have a call on this, I can send you a Teams link to have a discussion before the meeting at 16h.
Let me know.

Met vriendelijke groeten,
Cordialement,
Kind regards,

Hans De keersmaecker
Product owner
 
Luchthavenlaan 25A

1800 Vilvoorde (Belgium)

www.corilus.be

[bdc-ehealth]

WG: we agree on the principle as described above. We will provide another diagram which makes the final choice clear. The only thing to solve is to determine how the requestgroup can easily be retrieved from the servicerequest. This can be done either by an extra extension, or by an API feature (such as _reverseinclude), but this is to be investigated.

[bdc-ehealth]

WG: we wait for the architecture diagram that Anthony will provide.

[bdc-ehealth]

WG: solved by the proposal by RIZIV-INAMI/SMALS https://drive.google.com/file/d/156V7Pjw_ZYs4RGEit8HVFi0DhSEjduqo/view?usp=share_link