is an open routing service for standards of the Forum Datenaustausch, basically allowing to find a communication partner in function of/for a certain Forum Datenaustausch standard.
medSRS is up and running...
Uptime of the Webservice
1971d 12:24:54
0+
Number of active RHS
0+
Number of daily Queries
0
Number of standardNames
0
Number of glnProviders
0
Number of Intermediates
Routing Half Set and the Routing Table
Routing Half Set (RHS)
The RHS consists of a set of Global Location Numbers (GLN) plus the targeting Forum Datenaustausch standard forming an address path to an intermediate.
In this notation, a provider is bounded to an intermediate with a certain standard having the given GLN at that intermediate.
A provider knowing his own RHS inserts that data periodically into the medSRS routing table.
By using the query interface of medSRS, the RHS of a searched communication partner is returned.
Routing Table
The routing table is the basic database structure upon which the routing service acts. The routing table is populated by a number of Routing Half Sets (RHS) augmented by a time-to-live (TTL) data field.
The RHS of a searched provider (given by the GLN) is served to any querying instance as long as the TTL has not expired.
Therefore the validity timer must be periodically renewed in order to remain in force, otherwise the Routing Half Set is removed from the database.
The Routing Table is therefore similar in structure and design to the DNS Routing Table and fulfills its functionality with analogue mechanics.
The medSRS RESTful webservice
The medSRS service is accessible, managed, and queried by a RESTful webservice defined and build upon the state of the art OpenAPI 3.0 standard.
Please study the specification of the medSRS service below given in the syntax notation of OpenAPI 3.0. Furthermore
check the FAQ section should there be remaining questions or problems.
There are 2 different situations why/when a Routing Half Set (RHS) should be published at all:
The initial integration of a specific RHS defines the basic starting point that a provider can handle and process a specific standard in its entirety. Furthermore, this statement/placet also applies to the selected intermediary.
It is obvious that for the initial integration of the RHS there is only the software vendor who installs the XML-producing
software at the provider. Only at the time of installation can the primary readiness be signalled to fully operate the specific standard.
In normal operation, integration means that the specific RHS is still in use, i.e. still up-to-date.
A statistical evaluation of the Routing Table therefore also provides a picture of the deployment and use of a given standard of the Forum Datenaustausch.
In normal operation there are several candidates for RHS integration:
the software creating the XML document integrates the 'left' aka sender RHS alongside the XML production.
It is also in the interest of the intermediaries to ensure that the routing table is up to date, i.e. they can and should integrate both RHSs when receiving an XML document.
the software receiving the XML document integrates the 'right' aka recipient RHS in parallel to the XML analysis/processing.
As the RESTful webservice definition of addRHS shows, an appKey of the mandatory URI-encoded operation parameters besides the Routing Half Set.
The appKey is used to identify and authenticate the calling process and ensures that the RHS record can only be inputted by known,
trusted units.
As a software producer in the PIS area you are invited to order such an appKey free of charge in the contact form below.
In short each software producer that directly or indirectly generates XML files covered by standards of the Forum Datenaustausch can use
the webservice queryRHS free of charge!
Once a XML document should be created according to a standard of the Forum Datenaustausch, the
element transport must be added.
As the above definition shows, the element consists of 2 routing half sets (RHS).
While the 1st (own) RHS is well known, the 2nd RHS can be queried via the RESTful webservice queryRHS(glnRecipient).
The result then shows whether and how the recipient can be reached
via the selected intermediary. It also clarifies whether the standard used is supported by the intermediary and the recipient.
Please note, that each Sumex1 xmlManager module knows about the queryRHS webservice and helps you master the construction of the transport element.