The following table summarises a number of concrete scenarios that illustrate how the the API and reference implementation can be used in real world use-cases.
Each individual scenario is illustrated via a sequence diagram, some explanatory text and some key code snippets. If you prefer the samples project contains the implementation code to fulfil these scenarios as well as some instructions on how to download, install and run the samples yourself.
In general the example code and sequence diagrams depict how the service client/message originator constructs a message that is fulfilled by/sent to the service provider.
The scenarios are grouped into three general integration patterns (synchronous, simple asynchronous and routed message) as viewed from the initiating application perspective.
The synchronous scenarios provide a detailed insight into the logic of the reference implementation so it is recommended that you take a look at these first even if your are more interested in other scenarios such as sending a CDA document.
The synchronous interaction pattern is the simplest pattern supported by the ITK. The synchronous pattern is applicable to scenarios where there is a user waiting (for instance a user has sent a query) or where there is a business response and the destination service is directly reachable.
| Scenario | Description |
|---|---|
| Spine Mini-Services Client - Get Patient Details by NHSNumber | Client side view of the Get Patient Details by NHSNumber SMSP message (SMS Provider is effectively a black box) |
| Spine Mini-Services Provider - Get Patient Details by NHSNumber | Service provider view of the Get Patient Details by NHSNumber SMSP message note the application is emulated - the details of invoking Spine PDS are not included as it is the ITK behaviour that is being demonstrated. |
| ADT Admit Patient (P/H) | This example shows the transmission of an ADT Admit Patient message (A01) in pipe and hat format, with a synchronous acknowledgement. |
The simple asynchronous pattern is suitable for service invocations where the service provider is naturally (currently) asynchronous, or where the processing of the business payload is suitably intensive that a synchronous call might result in infrastructure (e.g. firewall connection) timeouts or similar resource issues.
| Scenario | Description |
|---|---|
| ADT Query patient (XML) | Simple ADT Query with an asynchronous response. This example uses and XML ADT format and shows a simplified end to end view of the interaction. |
The routed message pattern is suitable for messaging where the destination system is not directly reachable and/or where corresponding business responses are triggered via human interaction (for instance the acceptance of a discharge summary by the GP). In the diagram (below) an intermediary ITK Router is shown, however it should be noted that the pattern is identical from an originator and destination system perspective if there are zero, one or many intermediary ITK routers.
| Scenario | Description |
|---|---|
| Send non-coded CDA to a document repository | Illustrates the process of sending a non-coded CDA document to a clinical repository and subsequently receiving an InfrastructureAck asynchronous message. |
| Send non-coded CDA (with business Ack) | Illustrates the process of sending a non-coded CDA document to a destination application and subsequently receiving a Business Acknowledgement (in addition to an Infrastructure Ack). |
.jpg)