Furthermore, this method allows to define the parameters needed for sign and/or encrypt the resulting XML infoset. Therefore, read the notes about signature and encryption to get familiar with these concepts.

Important new feature: the electronic reachability of a recipient for a certain version of generalNotification is kind of chicken and egg problem. To solve this connectivity problem, the webservice medSRS (medical Standard Routing Service) has been created. By using the RESTful webservice method queryRHS one can find out, how and whether a specific recipient can be reached electronically. Please refer to the website medSRS.ch for getting an introduction to the topic or detailed information about the functionality of the webservice.

Instead of inputting the bstrToEan GLN literal, the query call queryRHS(glnProvider,glnRecipient) is supplied instead - cf. description of bstrToEAN below. Furthermore, should the query result indicate an unreachability for version V451, a query check for version V450 is automatically launched to investigate on the lower version. If the downgraded version is supported, than everything is prepared internally such that the method IGeneralNotificationManager::GetXML generates a downgrade automatically and transparently.

The usage of the patch can generate a new error code 'ERROR_RECIPIENTRHS_NOTAVAILABLE' indicating that a given recipient is not reachable. It is the decision of the calling program whether the error 'ERROR_RECIPIENTRHS_NOTAVAILABLE' will be considered or not.

• queryRHS( ) is a literal command
• glnProvider is the official GLN of the service with a required pattern of ^76[0-9]{11}.
  Please note that the official GLN of the service provider is needed here, which is not necessarily identical with the GLN of the sender == bstrFromEAN. The latter may be a GLN from the private sector (^2[0-9]{12}) - this is a small but crucial difference.
• glnRecipient is the official GLN of the recipient with a required pattern of ^76[0-9]{11}.
  Please note that the official GLN of the sender is needed here, which is not necessarily identical with the GLN of the recipient == bstrToEAN. The latter may be a GLN from the private sector (^2[0-9]{12}) - this is a small but crucial difference.

The result of the RESTful webservice call can return 3 possible result states:

1. the recipient (Suva) is reachable: the correct GLN bstrToEAN is returned and error state S_OK is defined
2. the call is faulty because the parameters have a wrong format or the used intermediate (bstrViaEAN) is unknown on medSRS or the call has caused some other technical problem. In this case bstrToEAN=bstrRecipient (7601003000078 in the example) is set and the error state S_OK is defined
3. the recipient (Suva) is not reachable: if there is the possibility of a downgrade, the RESTful call is repeated for the next lower version or bstrToEAN=bstrRecipient (7601003000078 in the example) is set and the error state 'ERROR_RECIPIENTRHS_NOTAVAILABLE' is defined.