MHD Testing Architecture
Two new architectural elements were added to Toolkit to support MHD testing. They may be used in other ways in the future.
A copy of the HAPI FHIR server is now integrated into Toolkit. In this release is version 3.5. Only the core of the server is integrated which makes the FHIR Resource models and translation facilities available but Resource storage is based on Toolkit Simulator Architecture and indexing/search is based on Apache Lucene.
Some features/limitations of this integration are: New simulator type called FHIR Server which, for now, only supports Patient Resources Patient Resources offer a very limited set of query parameters: family name and given name in one query or identifier (system|id). This will be updated very soon. MHD tests rely on this server
When a FHIR Server is needed by the Conformance Tool to support MHD testing, it is created automatically by the Orchestration Manager. It shows up in the Conformance Tool as the fake Actor Type FHIR Support. This actor type has no tests but its page within the Conformance Tool can be used to easily find its logs and configuration. MHD tests targeting transactions that are initiated by the Conformance Tool always reference Patient resources in this server. The Orchestration phase (test setup) creates and initializes the server if needed.
A reverse proxy has been added to Toolkit with the following capabilities: Bidirectional transaction content translation Transaction endpoint translation Logging of client side and server side request and response messages
The proxy is implemented as a special simulator, actually a pair of simulators created together with a common controller. The controller contains a translation manager.
When a proxy is created in the Simulators tool it is given a name by the user. If the name given is “proxy” and the test session is “test” then the following elements are created:
test\__proxy - simulator representing the proxy front went
test__proxy_be - simulator representing the proxy back end
The controller is not visible in the Simulators tool.
Simulators always have an associated log where the request and response message pair is stored. Within the proxy, the proxy front end logs the message exchange with the client system and the proxy back end logs the message exchange with the target system.
The proxy, as described, is an abstract simulator. It is not listed on the simulator types list of simulators that can be created. Instead it is bundled with a target simulator. The integrated proxy and target are offered as a create-able simulator in the Simulator tool. This triple-simulator is called a simulator group. This term shows up when viewing the configuration of any of the component simulators. In the future the Simulator tool will offer extended support for simulator groups. For now they are created as a unit but have to be deleted individually.
Toolkit already has functionality to support testing of XDS elements. The approach to testing MHD is to use these existing elements and provide necessary translation functions through the proxy. The MHD test suite uses several configurations.
To test an MHD Document Source there must be a supplied MHD Document Recipient to test against. This recipient is implemented as a proxy based simulator group.
The proxy is coupled with an XDS Repository/Registry simulator to act as it storage agent. The proxy is configured, through its translations, to convert MHD Provide Document Bundle transaction to XDS Provide and Register. Similar translations are made for the other necessary transactions.
In operation, the translation can be monitored through the front and and back end logs of the proxy.