Skip to main content

ITK API and reference implementation scenarios

This page summarises a number of scenarios that illustrate how the the API and reference implementation can be used in the real world.

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.

Synchronous

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.

synchronous ITK API interaction pattern

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.

Simple asynchronous

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 (such as firewall connection) timeouts or similar resource issues.

simple asynchronous ITK API pattern

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.

Routed message

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. Note that the pattern is identical from an originator and destination system perspective if there are zero, one or many intermediary ITK routers.

Routed message ITK API pattern

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).

Related pages

  1. internal

    Routed CDA document – Business Acknowledgement

    This scenario illustrates the case where the sender elects to receive a business acknowledgement. In this case the ITK API allows the setting of a message property to request the return of a Business Acknowledgement.

  2. internal

    Spine Mini-Services Client

    In this scenario a client application is indirectly querying Spine PDS to obtain demographic information held for the provided NHSNumber.

  3. internal

    Spine Mini-Services Provider

    In this scenario a client application is indirectly querying Spine PDS to obtain demographic information held for the provided NHSNumber.

Last edited: 30 April 2019 3:38 pm