Allow multiple Organization IDs in ITI-44 transaction

[tkergon]

Hello everyone!

We are currently using husky to develop our integration for the Swiss EPR. When sending ITI-44 Requests to add patient records using both the ConvenienceMasterPatientIndexV3 using convenience models or the PixV3Query using Fhir objects directly, only the first Organization ID will be considered, even when manually adding more values. See this message derivation snippet and this FHIR-patient object conversion snippet for reference.

Swiss EPR demands that we send both the patient's local identifier and the EPR SPID value gathered from a previous patient data query when registering a patient in the MPI. See also this for reference.

However, the IHE framework states that in that case, we're required to set all OIDs for the scoping organization, as declared here.

Is there any way to supply additional ID fields to the organization which we might have missed? Or is this not part of the feature set for husky? Would you maybe have a workaround that we could use?

Thank you kindly in advance for your time and effort. Best

[msmock]

The transaction should accept more than one assigningAuthorities as required for the Swiss EPR by law. It's an error if the transaction only accepts one assigningAuthority in the PIX transaction, but probably only the new version of the service api (see husky-communication/husky-service/src/test/java/org/projecthusky/communication/services/pix/PixAddPatientFeedTest.java).

Can you verify, that you have the same error in the service api implementation?

[tkergon]

Thank you for the quick response! I just moved our implementation to use the new HuskyService API. I'm using this statement to set the organization:

Organization organization = new Organization();
[...]
organization.setName("NAME");
organization.addIdentifier(localOrganizationIdentifier);
organization.addIdentifier(eprSpidOrganizationIdentifer);

PixAddPatientFeed.PixAddPatientFeedBuilder patientFeedBuilder = huskyService.createPixAddPatientFeed(affinityDomain.getPixDestination(), organization);

The rendered XML request looks as follows:

[...]
<providerOrganization classCode="ORG" determinerCode="INSTANCE">
    <id root="OID of the localOrganizationIdentifier from above"/>
    <name>NAME</name>
    [...]

So the second identifier is still missing. I think the same logic is applied in this API as well, discarding all identifiers except the first.

Are we using the API correctly? Or are other IDs added via other relations/settings?

[msmock]

Thank you. I'll initiate the correction of the error asap and will report it here.

[tkergon]

Thank you for the quick reply. We'll use the new service API once it's ready and use our erroneous implementation until then for testing only.

[tkergon]

Hi everyone!

Quick question regarding this problem: We're about to try and implement a workaround for this problem. Before we invest time for that, is there an ETA for a fix?

Thanks in advance!

[ch-fuchs]

Hey tkergon,

thanks for your feedback.

We have taken a look at the issue and will provide a fix by the end of the month.

Following changes will be applied (only for new API):

• Attribute scoping organization will be deprecated and replaced by providing organization on all PatientFeed classes (Add/Merge/Update) because scoping organization does not seem to be necessary for EPR context.
• For the corresponding request classes (add/update/merge), new setProviderOrganization method will be created to set the provider organization without setting the custodian. Additionally, those classes will be enabled to handle organization classes so multiple identifier are supported
• Underlying PixPdqQueryControlActProcess class will be modified generate the IDs properly.

I will give an update on this issue when we have created the branch to do the change. I think we should be able to do it until 17th, so that the review process is finished by end of the month.

[ch-fuchs]

Output of a test for the new PR: https://ehealthsuisse.ihe-europe.net/PatientManager/messages/messageDisplay.seam?id=158210

[tkergon]

Hi ch-fuchs,

Thank you very much for the quick work and the detailed explanations! We're looking forward to the next release to implement the changes.

Thanks!