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.
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.
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.
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.
Challenge closed for responsesProposals in development
This challenge is closed for comments.
Public responses to this challenges - ie possible solutions for the problem or issue raised by the challenge.
Proposals for solutions to this challenge, created by challenge owner and standards panel.
There are no proposals for this challenge yet.
The approach and standards or group of standards adopted to solve this challenge.
There is no solution for this challenge yet.