Add EF.PD and EF.VD to registerEGK message

[theodiefenthal]

With the new Prüfziffer v2, the eRezept Fachdienst will get an update in such a way that the primary system querying for an e-prescription must send the prüfziffer and hcv to the Fachdienst.

In order to calculate the hcv, the primary system needs the correct StrasssenAdresse (Found in EF.PD) and Versicherungsbeginn (Found in EF.VD) from a patient as input.

Without these two fields, the HCV can't be calculated and hence cardlink won't work any longer.

The proposed change is to add EF.PD and EF.VD file content to the registerEGK message.

[porebskk]

Hello Theo,

exchanging the HCV (and PNW/KVNR) for ePrescription tokens is not directly part of the CardLink but rather part of a seperate pharmacy system (AVS), so it is not required to have it in this API.

With best regards
Kevin

[theodiefenthal]

Hi Kevin,

From a logical perspective, I agree that it is the task of the AVS. However, the AVS can't perform this operation without adjustments to cardlink:

There is no way for the AVS to receive the "Strassenadresse" and "Versicherungsbeginn" from a patient except for the "readVSD" SOAP command to the konnektor. The readVSD in the Konnektor in turn will submit APDUs to the SICCT terminal (Cardlink), especially also ReadBinary EF.PD and ReadBinary EF.VD.

If the cardlink can't deliver EF.PD and EF.VD with the real StrassenAdresse and Versicherungsbeginn from a patient, the AVS simply can't compute the correct HCV. And with the wrong HCV, the AVS can't query e-prescriptions, hence cardlink would not work any more. Concluding, Cardlink must report EF.PD and EF.VD at least in a way that includes the real StrassenAdresse and Versicherungsbeginn.

The only way that cardlink can deliver the correct data is that either the information is contained in registerEGK (as proposed here) or that not only INTERNAL AUTHENTICATE but also ReadBinary EF.PD and ReadBinary EF.VD are exchanged via the websocket sendAPDU commands.

I think it is more performant and more in the style of the spec to have the data part of registerEGK instead of having additional APDU going back and forth.

Best regards
Theo