Double addressing seems excessive

[jkiddo]

in terms of:

dk-medcom-messaging/input/fsh/MedComMessagingOrganization.fsh

Line 6 in 5730bfe

* identifier 2.. MS

Why are two identifiers needed for the same piece of functionality? Why isn't it sufficient to use the SOR code?

[jkiddo]

ping @ovi-medcom / @tmsMedcom

[tmsMedcom]

The EAN-number is used for routing of messages, why it is included.

[jkiddo]

AFAIK, EAN (GLN) is already part of SOR, hence the question.

[tmsMedcom]

That's true but a single EAN/GLN number can be used by multiple SOR-units, so EAN/GLN cannot uniquely identify a healthcare unit. However, this can be done through SOR.

[jkiddo]

Thats why I would think that only using SOR would be enough.

[tmsMedcom]

I'm think it will require big changes in the existing network to rely on SOR for routing of messages.

[jkiddo]

Thats the 'A' in VANS, right?

[ovi-medcom]

In the future more GLN may be supported in SOR in order to serve different kinds of systems in the same SOR unit, hence both the SORID and the GLN will be needed BR Ole

[jkiddo]

In the future anything can happen. Technically, what you suggest could be done just adding more Organization Entities without introducing a breaking change as you suggest. Can you qualify your statement a bit more. Is it something that is in some pipeline somewhere?

[ovi-medcom]

It is actually part of “Målbillede for meddelelseskommunikation” and the non-breaking change you suggest is actually causing SOR to be highly inaccurate and full of non-existing real units Fra: Jens Kristian Villadsen ***@***.***> Sendt: 4. september 2024 22:39 Til: medcomdk/dk-medcom-messaging ***@***.***> Cc: Ole Vilstrup Møller ***@***.***>; Mention ***@***.***> Emne: Re: [medcomdk/dk-medcom-messaging] Double addressing seems excessive (Issue #36) In the future anything can happen. Technically, what you suggest could be done just adding more Organization Entities without introducing a breaking change as you suggest. Can you qualify your statement a bit more. Is it something that is in some pipeline somewhere? — Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AI5NUYDFCMJYA3TORDHZQD3ZU5VXJAVCNFSM6AAAAABKFC54VWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRZHEZDONRWGI>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[jkiddo]

Those would be closer to virtual units, I agree. Can you point me towards an authorative register that keeps both SOR identifierns and GLN identifiers in sync? If that isn't present then I don't see how routing can be handled safely downstream.

[tmsMedcom]

@ovi-medcom

[ovi-medcom]

Those would be closer to virtual units, I agree. Can you point me towards an authorative register that keeps both SOR identifierns and GLN identifiers in sync? If that isn't present then I don't see how routing can be handled safely downstream.

SOR keeps those identifiers in sync. In the near future plans for further development of SOR, there are plans to separate SOR and GLN as belonging to two different objects, eg organization and endpoint, The endpoint will then be able to be related to many different organizational units without inheritance as the functionality to do so, which is also causing virtual units. Further down the road the SOR org unit will be able to have more than one endpoint. Thus the endpoint is only handling the postbox activities and the sor identifier is pointing to the org unit, that is receiving the message through the endpoint.

[jkiddo]

OK - so SOR is the authorative data source on this matter - all good.

[jkiddo]

The EAN-number is used for routing of messages, why it is included.

Back to this. Why is routing put into the FHIR message if VANS don't look there? That seems a bit contradicting to medcomdk/dk-medcom-acknowledgement#33 (comment)