This site is currently in beta and more functionality and content will be added over the coming months. We welcome your comments. Please click here to provide feedback.

Challenge: Multi agency incident transfer

Challenge closed for responses.

Short description: 

The emergency responder community currently relies on a range of processes to inform partners of incidents for which their assistance might be required. These include manual processes such as telephony, facsimile as well as some electronic methods. Some of these tie up resources as they call their counterparts and introduce risks of miscommunication as common data fields are re-keyed into multiple systems.

User need: 

This challenge draws users from a wide range of organisations.  It is likely to cover the broad range of organisations defined by the Civil Contingencies Act 2004 as category 1 responders - those most likely to be involved in the response to an emergency.  This includes police services, ambulance trusts, fire and rescue services, local authorities and HM Coastguard.  Category 2 responders like the Highways Agency will also be involved.  Other voluntary groups may also be involved and as such information may need to be passed to them too. Definitions of terms relating to Civil Protection can be found online at https://www.gov.uk/government/publications/emergency-responder-interoperability-lexicon 

The fundamental requirement in all rapid responder organisations is for fast reliable information exchange between each other.  Indeed the public, as users of these services, would expect no less. Service users require appropriate numbers and types of emergency service resources to be mobilised to the right place and in a timely manner. 

The exchange of this information at present is far from ideal. There are some local interfaces but, these are not standardised with differing versions in existence that do not take advantage of current technology. The transfer of common information elements is necessary to deliver the service effectively.

Expected benefits: 

Following agreement and subsequent implementation of the standard it is expected that there would be:

  • Reduced time for multiple agencies to log core incident information as the incident data will be injected into recipient's Computer Aided Despatch systems.
  • Faster secondary response times as it will be quicker for mobilisation decisions to be made thus delivering a better service to the public.
  • Improved fallback arrangements between agencies as during peak periods calls may be logged by 'Buddy' organisations and routed back to the intended organisations for decision. 
  • More efficient connection strategy via a centralised Hub instead of multiple point-to-point connections.
  • Allow the initial formation of a 'Common Operating Picture' to enable shared situational awareness.
  • Greater sharing of incident data will also highlight possible hazards to emergency responders.

Functional needs: 

A proof of concept project completed in 2012 concluded that the notification of partner agencies of incidents can be achieved by passing the data through a central hub to enable multiple agencies to be informed near simultaneously.  This would allow organisations to make a single connection to a hub and gain the capability to disseminate the data to a number of applicable organisations.  The use of a hub is a far more efficient and negates the need to install multiple point to point connections .

The information that is likely to be needed to be shared will include geographic elements (such as the location of an incident, any incident cordons, caller address); temporal aspects (day, date, time); data concerning the type of incident being dealt with; and the resources being mobilised to respond to it.

The standard must have a validation mechanism to confirm the integrity of the message.

The Maintenance of the standard will fall to client systems.

Likely endpoints for the system will comprise public bodies such as police, fire, ambulance and local authorities.  Other bodies might in the future view the message via secure portals.  Identification codes for organisations have not yet been defined. 

The message may need to be encrypted (in some scenarios) and signed.

On receipt and read, messages should be passed to the originator to provide a 'handshake'. 

Following the initial message being pushed to recipients' systems, further updates will be available to be 'pushed in both directions' as required.

It is yet undetermined if a common set of incident codes are defined or if incidents will be described using free text.

Status: 

Current

The Health and Social Care Information Centre has existing definitions of Ambulance XML messages. The HL7 UK organization (www.hl7.org.uk) will seek to work with partner organisations to build on existing established standard messages.

The proof of concept referred above, tested the concept of information regarding emergency incidents being shared between multiple agencies utilising a standard messaging format originally created for use by the Highways Agency. This is already recognised by leading Command & Control (C2) and Computer Aided Despatch (CAD) systems. It is proposed that adapting this standard to meet multiagency information requirements would fulfil this requirement.

The PSN is intended to be the next level of network integration for pan-Govt services operating below SECRET, replacing GSI, xGSI, N3 and other siloed networks. However, each part of Govt will wish to maintain its own SyOps, and thus a permeable security boundary and set of trust relationships so that incoming data can be identified by source and filtered for content in near realtime, before being processed and forwarded as required.

This suggests an approach with cross-domain technologies at both server and user interface (desktop, tablet) level, which present multiple copies of applications and services in different security contexts, and enable users to interact with them all on one (relocatable) screen, with mediated copy / paste actions

Most CAD systems these days have some form of incident transfer capability.. e.g. STORM has highways link, Ambulance has 111 etc etc. The trouble is that they dont conform to a standard. To save time and money create shims from existing implementations to a common standard. This means that you dont have to get your CAD supplier to change their system. This was the approach we took with Collaborator. For systems with no such interface we managed to integrate directly with the incident log feed. This enables operators to send mesages to other agencies simply by typing formatted log entries. The system also has capability for Multi-agency GIS.

Community safety partnerships increasingly need to exchange data about the various anti-social behavour incidents that are reported to the various partnership agencies (e.g. harrassment to the Police, secondary fires to Fire & Rescue services, A&E incidents to the health service, flytipping to local authorities) to help solve neighbourhood problems. A series of local data movement projects have been undertaken in a number of areas to 'prove' the incident exchange concept usually based on the SNEN 101 schema that was specified by the Home Office. However, this schema is not detailed enough. A successor schema has been developed by community safety professionals for your consideration. 

Developing messages from Health to Social Services informing of hospital exits as part of Care XML.  Could be extended to wider multi agency working.

BASDA (Software Industry Trade Association) is working on a Care XML standard to automated commissioning of social care and ordering of care from care providers this is an extension to the existing BASDA 3.10 ebis XML.

There are no proposals for this challenge yet.

There are no standards profiles for this challenge yet.