MAIT DRAFT 1d Exchange Candidate 5

8/12/2019 MAIT DRAFT 1d Exchange Candidate 5

1/30

MAIT 1d XML Interchange FormatInterface Specification

Issued: 28 March 2014Issue: DRAFT 1d Candidate 5

Page 1 of 30

Multi Agency Incident Transfer (MAIT)

Protocol Version 1d Candidate 5 (DRAFT)

Copyright:

You may re-use this information (excluding logos and other minor exemptions) free of charge inany format or medium, under the terms of the Open Government Licence. To view this licence,visit http://nationalarchives.gov.uk/doc/open-government-licence

Where we have identified any third-party copyright information, you will need to obtain permission

from the copyright holders concerned.

This copyright is considered to be broadly compatible with the Commons Share with Attributioncopyright agreement (BY-SA) under which any suggestions for changes and improvements to thisstandard will be accepted.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to beinterpreted as described in RFC 2119 ( http://www.ietf.org/rfc/rfc2119.txt).


2/30



Page 2 of 30

Document Change Control

Date Version Name Notes

2006 1b CAPITA(formerlySunGard

Vivista Ltd)

Original NSPIS C&C Inter-Force Incident ExchangeInterface IPR released to Public Domain

2012 1c BT/ULTRA UED/BTNRE/FC/748 Version for DEIT Phase 1a Trial IPR Release to Public Domain

2013 1dCandidate

1-4

BAPCO MAITGroup

Internal Versions before public release followingfeedback from Emergency Service User groups and

BAPCO members.

28 March2014

1dCandidate

5

BAPCO MAITGroup (TJG)

Public candidate for Open Standard discussion andparticipation.


3/30



Page 3 of 30

Contents

1 OVERVIEW ...........................................................................................................................41.1 Introduction.......................................................................................................... 41.2 Structure of Document.........................................................................................4

2 OPERATING PROTOCOL ........................................................................................................52.1 Communications Management............................................................................ 52.2 Data Management.................................................................................................7

2.2.1 Data Mappings...................................................................................... 72.2.2 Data Truncation ....................................................................................72.2.3 Control Characters / Non ASCII characters............................................72.2.4 XML Schema Validation ........................................................................82.2.5 XML UK National Element Values .........................................................92.2.6 Schema Extensions ..............................................................................9

2.3 Presentation Guidance ......................................................................................103 INTERFACES ......................................................................................................................11

3.1 Incident Creation................................................................................................113.1.1

Incident Creation Message.................................................................. 11

3.1.2 Incident Creation Acknowledgment Message ......................................22

3.2 Incident Log Update...........................................................................................243.2.1 Incident Update Message....................................................................243.2.2 Incident Update Acknowledgment Message ........................................28

APPENDIX A -REFERENCES...........................................................................................................30APPENDIX B -GLOSSARY OF TERMS...............................................................................................30


4/30


5/30



Page 5 of 30

2 OPERATING PROTOCOL

2.1 Communications Management

The exchange of incident information between organisations is based on the following underlyingmechanism:

Messages are formatted using XML.

Messages are transported between command and control systems using TCP/IP socketswhere ports MUST be a direct message passing socket for the RAW XML. Systems MAYagree a port to implement a SOAP (within HTTP) interface to a store and forward messagesystem implementing the SOAP Action(s) IncidentCreation and IncidentUpdate. Any systemclaiming compliance with this standard MUST identify itself as TS if it supports this option and

S if it does NOT support the default RAW connection. E.g. This system complies withMAIT1DC4-T, MAIT1DC4-TS or MAIT1DC4-S. Users of the standard must be careful as Tand S systems will be UNABLE to interoperate.

Messages are not delimited by a start and end character.

Systems MUST ignore any unknown message types to allow the standard to expand.Unknown elements from Schema 1d onwards should raise an error as non conforming to theXSD validation please see extensions options at 2.2.6 for adding elements.

The interface operates to ISO-8859-1 XML encoding standards up to schema Version 1c. Notethat to support multi-lingual (including Welsh) character transfer it is necessary that schema 1donwards use the UK Open Standard of UTF-8. Therefore systems using UTF-8 MUST includean encoding value attribute in the initial XML header which consists only of ASCII allowing an

encoding change if needed i.e. Theabsence of an encoding attribute will assume ISO-8859-1 (also a single byte standard). Itshould be made clear that legacy systems MAY immediately translate non ASCII charactersand users MUST confirm with the receiving organisation that they will be able to handleinformation other than the basic ASCII character set see 2.2.3.

The interface connects to a single IP address for each external organisation with whichincidents will be exchanged. Systems MAY (and any HUB solution SHOULD) implement theability to connect to two alternative address/port combinations if no response is received withina definable timeout, after a configurable number of retries. It is expected that this will allowsuitably equipped receiving systems to provide a hot standby server and a cold standbyDisaster Recovery Site where IP address management techniques such as HSRP or loadbalancing are not used.

The interface connects through a single port number, for both inbound and outboundmessages. Port numbers on either organisation side are subject to agreement between theorganisations including any HUB operator. Each organisation is also responsible for resolvingits own IT security issues, including any network (e.g. PSN) accreditation, connection andassociated IT health checks if required.

The communication protocol is connect-send-acknowledge-disconnect. Theoriginating system connects to the receiving system, sends the message, receives theacknowledgement (down the same socket) and disconnects from the recipient system. Theresulting effect is that the originating system acts as a client connecting to the receivingsystem which acts as the server.

The communication is synchronous using a single two-way socket. As a result, it is onlypossible to send one message at a time to a given external system. Outgoing messages

should therefore be queued as necessary by the sending system to be sent as soon as theprevious message has been sent and the corresponding acknowledgement has beenreceived.

On failure of a connection, the originating system is responsible for trying to re-establish theconnection and taking any consequential action see also alternative address note above.

Comment [A1]: This sectionis currently open for discussionwith a proposal for theAsynchronous option to not beSOAP but, be aligned with theOASIS Emergency Committeework or other solution forpublish/subscribe systems

Deleted: or elements


6/30



Page 6 of 30

To minimise adverse operational impact, participating organisations SHOULD notify eachother when an interface is unavailable (for example due to maintenance). In a HUBenvironment it is RECOMMENDED that a supplier will support some form of out of bandmanagement service to exchange basic metadata covering this and other aspects offunctionality.

Due to the connection protocol being connect-on-demand, heartbeat messages are notrequired for connection monitoring. If a group of users wish to implement such a system thenthey MAY agree to use an Incident Update Message (IUM) at a suitable incident as a form of

PING it is RECOMMENDED that incident number 0 is reserved for this purpose. The sending system must identify itself in every message sent between C&C systems using

the OrigOrganisation element of the XML messages detailed below. From version 1c thesending system MUST also identify the intended recipient in the DestOrganisationelement ofthe XML messages to facilitate interchange via a HUB operator.


7/30



Page 7 of 30

2.2 Data Management

2.2.1 Data Mappings

Fields that have a constrained list of values in a command and control system may not have thesame values in all systems, even between organisations that use the same C&C systems. This isbecause organisations will always need the flexibility to configure their own system to hold andpresent local values for specific types of data, for example call origin, grade of response and even

incident type. As a result, data mappings will have to be used for data items exchanged betweenorganisations within an incident record. These data mappings were performed on the receivingC&C system only up to version 1c.

Field content mapping SHOULD be available in systems on Send, to the nationally agreedsuperset values for the key fields this will allow local variation but, avoid recipients having tocreate maps for all incoming connections which would be unworkable on a national level where aHUB is in use. The need to map incoming fields from the national superset or specific originatorswill still be required to allow local coding to be used by the recipient organisation. If there is a mixof a HUB connection and point to point links, suppliers SHOULD provide a per sender mappingoption on inbound data from systems.

Although indicated to be constrained by an asterisk * in the schema some fields such as

, , and do not have a defined constraintlist (DTD) which causes problems between agencies, so the data elements are discussed below in2.2.5 with suggested contents that suppliers are strongly RECOMMENDED to implement.

2.2.2 Data Truncation

As many data items have different lengths within the various C&C systems, it is not alwayspossible to specify the lengths of these data items within the XML messages. As a result, whenthe length of a data item is not specified in the message definitions below, there is no limit to thenumber of characters that can be used to specify the data item and therefore any truncationrequired will be performed by the receiving C&C system.

There is a need to WARN the sender if this has happened on receipt. System developersSHOULD ensure that the system provides a suitable error response. This should be achieved

using the couplet for Incident CreationAcknowledgement Messages (ICAM), or Incident Update Acknowledgment Messages (IUAM) e.g.

Y

#WARNING: Some fields truncated.

The sender MAY append a list of field names if wished to the description.

It is RECOMMENDED that the receiving system should append the text of anyto status messages even if the success flag is received.

2.2.3 Control Characters / Non ASCII characters

Some of the data within the XML elements sent across the interface can contain controlcharacters. The receiving system must therefore be able to accommodate these to ensure that theentire field value is used. The control characters that may be received in this way are carriagereturn (decimal 13) and line feed (decimal 10). The fields which can contain these are:

PersonComment

VehicleComment

Description

CallerAddress

CommentDescription

It should be made clear that accommodating the characters only goes as far as being able toaccept a message that contains them. The receiving system is not constrained as to how it dealswith them. The fact that the message may contain line feed and carriage return characters doesnot mean that the fields that hold the data received must be capable of holding multiple lines of

Comment [A2]: With theaddition of validation this mustbe changed to require theSending organisation also totruncate at 300 characters andwarn its users. This does notprevent the receiving systemfrom truncating further.


8/30



Page 8 of 30

data. The receiving system might, for instance, substitute a carriage return with a comma so that itcan hold the data in a single l ine.

Obviously the UTF-8 encoding may add significant complexity so systems MAY wish to transformthe stream into a text form for onward system compatibility. See http://tools.ietf.org/html/rfc3490forthe IDNA mechanism as a suitable example.

2.2.4 XML Schema Validation

No mandated validation was executed against an XML schema, XSD or DTD prior to Version 1d.

This provided the additional flexibility for an organisation, for its own purposes, to add customfields to the interface of its own C&C system without disrupting the ability of that system to operateusing the national standard defined in this document.

Although no XML Schema or DTD validation is useful to allow extensions it brings risks oninteroperability, from version 1d receiving organisations SHOULD and HUBs MUST ensurevalidation, a schema extension methodology is provided at 2.2.6. Suppliers of systems SHOULDfollow the guidance paragraphs within this schema to ensure maximum compatibility betweensystems and commonality of data.

It should be made clear that the XML standard does not specify that the order of the fields willalways be that in the schema and suppliers should ensure that systems can cope with out of orderXML items, usage of existing handling libraries will usually ensure this.

To allow compatibility between systems and future growth of the schema, a schema versioningattribute has been added to allow continued use between systems of various schema levels. To

retain compatibility the absence of a SchemaVersionattribute will imply an older schema 1c or

1b which are broadly compatible as the 1c extensions add functionality for HUB andrecommended *Gaz value operation only.

Where a system receives a different schema level acknowledgement especially in a n ICAM itSHOULD inform the users of the risk of loss of data. In the case of an IUAM it MUST clearly flagany absence of a Positive Delivery Notification (PDN).


9/30



Page 9 of 30

2.2.5 XML UK National Element Values

Systems SHOULD provide a configurable way to map on send, at least the data values forConstrained elements - marked with an * asterisk in element tables.

2.2.5.1 and

There is a vital need to maintain a central list of codes for this field. Currently to avoid additionalwork for any central body it is intended (in the UK) to use the code list maintained by the CabinetOffice for transmission through any UK Government HUB as this contains most organisations that

could join the HUB and includes namespace to accommodate additional agencies if needed.

System developers SHOULD ensure that the can be different for callsdestined for a HUB than that used for point to point links to preserve compatibility with anycentrally mandated organisation code.

Systems SHOULD provide a way of managing lookups for user friendly names for organisationsrather than the codes used in the Destin/OrigOrganisation fields. HUB suppliers SHOULD providea standard for this.

The use of a dotted notation is also recommended in the form uk.GROUP.ORG999 whereGROUP is optional to allow multiple agencies with unique identifiers in the form ORG999 toprovide shared Control systems or indeed single agencies to internally distribute to multiplecontrol systems.

2.2.5.2 Type fields

0 Local => Easting/Northing or Lat/Long value, only has meaning to sender although the

recipient can store the supplied key value for future reference or groups of organisations maychoose to share a local gazetteer.

1- Address Point (Deprecated).

2- NLPG / AddressBase Premium the UPRN is the selected key, English and Welsh systemsSHOULD use this as the preferred method for addressable items.

3- One Scotland Gazetteer (http://www.onescotlandgazetteer.org.uk/).

4- AddressBase / Addressbase+ (not recommended in the UK).

5- UK Emergency Services Gazetteer (Colloquial and Historic) proposed extensions to ABP.

2.2.5.3 and

The absence of this couplet (as in older schemas) should be taken to mean Business IL2 orConfidentiality marking of PROTECT / OFFICIAL.

Options for MarkingScheme (SecurityLevel):

BIL(IL0,IL1,IL2,IL3).GPMS(NPM,PROTECT,RESTRICTED).

GSC(OFFICIAL,OFFICIAL:SENSITIVE).

2.2.5.4

To maintain compatibility with older systems the new NotificationReason can be used to informinter agency interaction it is effectively a National Incident Type list simplified.

2.2.6 Schema Extensions

The schema allows for supplier expansion in a controlled fashion under the mait.org.uk/extensionsnamespace with the creation of up to 50 triples of named data items of type string, number,integer or boolean. Suppliers SHOULD only use these where extending the system isunavoidable and in any case SHOULD ensure, where possible, they are clearly documentedwithin the MAIT community and seek to ensure the requirements can be incorporated into the

development roadmap. These extension items MUST only be included in ICM type messages.Receiving systems MAY choose just to convert them to LOG entries or COULD provide fullsupport for flexible fields like this.

Comment [A3]: This iscurrently undergoing work andshould be based on the outputof the JESG project in Walesand consulted on within theBAPCO group.


10/30



Page 10 of 30

2.3 Presentation Guidance

System suppliers SHOULD take note of the Implementation Guidance paragraphs usedelsewhere to ensure the Users of the systems experience suitable two way communication. Thissection provides some further suggestions, free of IPR, that they may wish to implement as theaddition of functionality SHOULD not increase the number of steps required for users whereverpossible.

The , and/ fields should be defined ashaving a priority level as geo-locations may have come from updated Automatic Vehicle LocationSystem (AVLS) data or been moved by resources on the ground so, if present have a greatervalue. There is a need for sending systems to recognise this priority and not transmit the X,Y(unless it is the one from the GazRef) or preferably an updated one. Receiving systems MUSTignore partial values and only accept X,Y where both are present and Non zero.

Systems with mapping interfaces should be able to use the meta-data about recipientorganisations (which should include a common boundary file) to find out what areas they areinterested in (i.e. by geography using an overlay) this lets the machine do the work of offeringoptions, which humans can then select or deselect as they require. HUB suppliers SHOULDprovide such metadata.

This can be extended to offer recipients to indicate possible interest by maintaining a TAG onIncident Types in their metadata in the central directory. E.g. Highways Agency may be offered asan automatic option by systems even if out of their geo-spatial area if the National Incident Typemapping is VEHICLE.

The large numbers of organisations offered by a HUB and a central directory will begin to cause aproblem for display in systems, which SHOULD allow solutions such as favourites, groups andfilters on displayed destinations and the ability to add and remove them, perhaps from a HUBscentral directory, dynamically if they become needed. As the NPIA guidance on interoperabilityadvises, all technology should be used day to day for familiarity, with the ability to scale up ifneeded in a larger emergency.

Deleted: ,


11/30



Page 11 of 30

3 INTERFACES

3.1 Incident Creation

3.1.1 Incident Creation Message

The Incident Creation message is used by a sending organisation to notify another organisation

of an incident that has been recorded by the sender that requires direct response by the receivingorganisation or who may need to be informed of the incident. Prior to version 1d the interface itselfimposed no constraint on whether the same incident could be sent from one system to anotherusing this Incident Creation message. It was down to the individual systems within theorganisations to determine the appropriate business procedures to decide if an incident should besent more than once and how an incident would be handled if it is recognised as a duplicate of anincident already received.

For the avoidance of doubt systems MUST NOT transmit different element values for subsequentICM messages in order to provide an update function to these values then the mode attributeMUST be present with a value of update. The absence of the mode attribute MUST beconsidered a default of create to retain compatibility with previous schema versions.

It is RECOMENDED that the ICAM should be used to handle previous incident creation errors toincrease communications resilience: A repeat attempt to open an incident should still result in an

ICAM of N but, with an#WARNING:

Incident already created as XXXXX or in the case of anupdate mode attribute, where no incident was previously created then supply an ICAM of

N but, with an#WARNING: Updated

Incident XXXXX previously unknown. XXXXX should be the

Human readable form OrigIncidentNum.

The receiving system can decide what to do with Closed incidents either by re-opening themautomatically in which case the response should beYINCIDENT XXXXX

reopened or it SHOULD respond with a suitable message using theNINCIDENT XXXXX already

CLOSED couplet. This is required so that sending systems can respondcorrectly if they send updates to incidents that have been closed by the recipient organisation.

In order to inform sender organisations of the expected time until a resource will attend Systems

SHOULD send an ICM update mode containing a field. Similarly

and would reasonably be expected to use ICMupdate mode.

Note in these instances where recipients use ICM update mode care should be taken to includethe correct incident URN as this reverses the normal direction of flow as per ICAM messages orany IUM messages.

ICM close mode Comment [A4]: It has beenproposed that systems wouldbenefit from the addition of aformal notification when asending organisation closes anincident rather than just usingthe SHOULD to make an IUMcompulsory. This does notmean the receiving organisationshould close the incident, thatdecision will remain with them itmerely allows state information

to be recorded by systems.


12/30



Page 12 of 30

The following is the complete structure of the IncidentCreationmessage shown without any data values:

Deprecated

Deprecated


13/30



Page 13 of 30


14/30



Page 14 of 30

Table 1 specifies each of the data items in the Incident Creation message, how they are expected to beused and any constraints on them. Items marked with an asterisk (*) hold constrained values that will needto be translated by the receiving system to its own set of constrained values and SHOULD be mapped onsend to Nationally Agreed values (see section 2.2.1).

Table 1 Incident CreationElements

Element Description Format Mandatory Notes

MessageIdUnique ID of themessage

String(18) Yes

MarkingScheme*

Identification of themarking schemeused to code theincident

String(6) NoPlease note this field must only bepresent if SecurityLevel is present.

SecurityLevel*Security marking ofthe incident

String(24) NoPlease note this field must only bepresent if MarkingScheme ispresent.

DestinOrganisationCode for therecipientorganisation

String Yes Destination organisation.

OrigOrganisationCode for theOriginatingorganisation

String Yes Originating organisation.

OrigIncidentURN

Unique ReferenceNumber of theincident in theoriginatingorganisation

String(24) Yes

The unique identifier of the incidentin the originating system. This willnot normally be displayed to theuser but, could be the same asOrigIncidentNum in some systems.

OrigIncidentNum

Number of incidentin originatingorganisation asknown by the users

within thisorganisation

String(24) Yes

The incident number as displayedto the user within the originatingC&C system. This could be usedfor cross-reference purposes andwill allow operators to know theincident number on the remotesystem. The NSPIS C&C incident

numbers are re-incremented from 1each day.

Truncation may be required insome C&C systems to the mostsignificant digits.

OrigIncidentDate

Creation date ofincident inoriginatingorganisation(DDMMYYYY)

Numeric(8) No

Systems SHOULD obtain time fromthe PSN time source when used totransmit and receive on thatnetwork.

OrigIncidentTime

Creation time ofincident inoriginatingorganisation

(HHMMSS)

Numeric(6) No

Systems SHOULD obtain time fromthe PSN time source when used totransmit and receive on thatnetwork.

CallerDetailsEnclosing elementfor all caller details

N/A NoOnly one set of caller details areallowed.

CallerTitle Title of the caller String No

Comment [A5]: Note that allnon defined strings, to meet theintroduction of validation mustnot exceed 300 characters inlength. Suppliers who have alength longer than this for anyfield in legacy systems shouldmake this known to the BAPCOMAIT Standard working group.


15/30



Page 15 of 30


CallerForenameForename of thecaller

String No

CallerSurnameSurname of thecaller

String No

CallerNumber

Phone number of

the caller String No

CallerAddressComplete addressof the caller

String NoThis is free text that captures thehuman description the original calltaker gave

CallerMobile

EISEC dataprovided by themobile supplier viaBT

String No

CallerGazType* Reference Type ofthe Gazetteer

Numeric(2) NoPlease note this field must only bepresent if CallerGazRef is present.

CallerGazRefThe reference inthe Gazetteer

String No

Content of the agreed primary keyfield for the selected gazetteer.Please note this field must only beincluded if CallerGazType ispresent. See section 2.2 DataManagement

CallOrigin*

Origin of originalcall

String(8) Yes

Origin of original call e.g. Kiosk,mobile, private sub, Officer e-calletc. See section 2.2 DataManagement. Systems SHOULDpass this through to operators andany nuisance detection systemsalong with address and numberdata etc. They SHOULD not use itas the source of the incident whichshould be based on a humanreadable form of theOrigOrganisation

Priority*Priority of theincident

String(20) No

This is also known as the GradeCode. This is the originalorganisations one use and for NationalInter Agency Priority.

DescriptionDescription of theincident

String No

Location

Detailed location asstored in theoriginating C&Csystem

String Yes

This is a text description (probablythat originally taken by the callreceiver) that can be used byreceiving organisations where noaddressable location can bematched and for confirmation ofraw data

CoordinateSystemHow to interpret thesupplied X/Y

String(8) No

E.g. OSGR (for Northing andEasting), OSGB36 or WGS84 forLat/Long using these or anotherinternationally agreed geo-spatialprojection.


16/30



Page 16 of 30


X (was Easting)

The X co-ordinate

in the defined co-ordinate scheme String(7) No

Note this replaces the earlier OSgrid reference element Eastingwhere 7 digits were used to coverareas in Scotland.

Truncation may be needed in some

C&C systems.For backward compatibility whereno CoordinateSystemis presentsystems should allow Easting andNorthing fields and assume it isOSGR.

Y (was Northing)The Y co-ordinatein the defined co-ordinate scheme

String(7) No

Note this replaces the earlier OSgrid reference element Northingwhere 7 digits are used to coverareas in Scotland.

Truncation may be needed in someC&C systems.

For backward compatibility where

no CoordinateSystemis present

systems should allow Easting andNorthing fields and assume it isOSGR

IncidentGazTypeReference Type ofthe Gazetteer

Numeric(2) NoPlease note this field must only bepresent if IncidentGazRef ispresent.

IncidentGazRefThe reference inthe Gazetteer

String No

Content of the agreed primary keyfield for the selected gazetteer.Please note this field must only bepresent if IncidentGazType ispresent.

HazardFlag

Indication thatsending agency

has risk informationassociated for theincidents locationor vicinity

String(1) No

To enable agencies to warn eachother that they hold riskinformation. Log update

messages can be used toexchange information that theofficers feel is acceptable whichmay be a telephone number todiscuss the issue.

KnownSceneSafetyIssueWarning thatincident scene isknown to be unsafe

String(1) No

Warning that incident scene isknown to be unsafe; if receivingagency is responding they willfollow their own protocols to attendscene or wait for support e.g. fromPolice. Y or N, NULL or absenceshould be used to meanUNKNOWN not No


17/30



Page 17 of 30


RVP Rendezvous Point String

No This is an enclosing type it is onlyexpected to contain one instancebut, in a multiple agency situationthis may grow.

To cover C4 (Command, Control,

Coordination and Communication)sites like Strategic and TacticalHolding or marshalling areas forCBRNe or MTFA type incidents.

C4SType* RVP, FCP etc String(8)

This defines the type of C4 sites asfound in the common UK/NATOmap symbolswhich should be usedas the constraint list for content.

https://www.gov.uk/government/publications/emergency-responder-interoperability-common-map-symbols.

RVP.GazType Numeric(2) NoPlease note this field must only bepresent if RVPGazRef is present.

RVP.GazRef String NoContent of the agreed primary keyfield for the selected gazetteer.Please note this field must only bepresent if RVPGazType is present.

RVP.AddressTextual descriptionof RVP

String(300) NoContains a text description /additional information of location ofRVP

RVP.CoordinateSystemHow to interpret thesupplied X/Y

String(8) No

E.g. OSGR (for Northing andEasting), OSGB36 or WGS84 forLat/Long using these or anotherinternationally agreed geo-spatialprojection.

RVP.XOS grid reference

northing

String(7) No

7 digits are used to cover areas inScotland.


RVP.YOS grid referencenorthing

String(7) No

7 digits are used to cover areas inScotland.


RVP.Status

Control field forsystems to maintainmultipleoccurrences

String(7) YesThis will contain ADD, REMOVE orUPDATE to allow multiple C4Spoint data to be managed correctly.

RVPSeqNo

A sequentialnumber allocated toeach RVP in an

incident

String No

This allows multiple RVP. Note thatif many organisations are involvedthe sequence number will only beunique when associated with the

origin of the message inOrigOrganisation.

Comment [A6]: It would beprudent to rename the

container and other fields toC4S now for consistency withits increased flexibility, as atthis point no systemsimplement them.

Comment [A7]: A similar fieldwill be added to Vehicles andPeople for the same purpose inthe released standard.


18/30



Page 18 of 30


Type* Type of incident String Yes

Code for the type of the incident this is the original organisationcode and could be used betweensimilar organisations such as fire toexchange richer data if they bothconform to the National FireIncident Type usage.

SubType * Sub type of incident String NoCode for the sub-type of theincident.

AttendanceRequested*

To differentiatebetween thoseoccasions wherethe originatingorganisation isinforming thedestinationorganisation of theirattendance andwhere amobilisation of

resources isrequired.

String No

However this does not mean thatthe receiving organisation isrequired to respond just that thesender requests it. Equally anoperator may choose to do so fromreceived information and localintelligence.

Value can be Y or N

NotificationReason*

To enable theoriginatingorganisation tospecify why theyare requestingresources from thedestinationorganisation.

String No

Police may be required for trafficcontrol, crowd control, evacuationor to investigate suspiciouscircumstances. Will enable thedestination organisation to send theappropriate resources. Has animplication for fire when AttributeBased Mobilising becomes moreprevalent. See section 2.2 forNational Values

ResourceETA

Time to attendincident fromreceivingorganisation(HHMMSS)

Numeric(6) No

Allows originating sendingOrganisation to confirm a resourcehas been dispatched and providean estimated time of arrival of thefirst resource. Omission of the tagitem should be taken as anindication of no ETA rather than theuse of a zero figure which wouldmean already in attendance.Systems should be able togenerate this figure to saveoperator time.

In reverse using the ICM updatemode it will allow receivingorganisations to return their firstresource likely ETA

VehiclesInvolved

Enclosing tag which

containsinformation aboutall the vehicles orvessels involved

N/A No

Comment [A8]: In order toalign O-NAT work it may benecessary to add some form of

ID field as well.


19/30



Page 19 of 30


Vehicle

Enclosing tag whichcontainsinformation aboutone vehicleinvolved

N/A No No limit to the number of instances.

VRM VehicleRegistration Mark

String(11) No The field size is indicative.Truncation may be needed in someC&C systems.

VINVehicleIdentificationNumber

String(17) No

VehicleMake Make of the vehicle String No

VehicleModelModel of thevehicle

String No

VehicleVariant

To record, ininvestigative andintelligencesystems,incomplete

informationobtained from anysource about amotor vehiclemodel.

String No

Not used by all C&C systems, so itis left as a free text field. Data

mappings could be agreed in thisfield.

VehicleColourColour of thevehicle

String No

VehicleInvolvementInvolvement of thevehicle

String No

Not used by all C&C systems, so itis left as a free text field. Datamappings could be agreed in thisfield.

VehicleCommentAdditionalcomments aboutthe vehicle involved

String No

VehicleSeqNo

A sequentialnumber allocated toeach vehicle in anincident

String No

Not used by all C&C systems, so itis left as a free text field.

Note that if many organisations areinvolved the sequence number willonly be unique when associatedwith the origin of the message inOrigOrganisation

Vessel

Enclosing Tag thatcontains the detailsabout the vesselsinvolved

String No No limit to the number of instances

VesselNameThe humanreadable name

String No

VesselMMSIMobile MaritimeService Identity

String No

This is a unique 9 digit number

given to vessels but, can change ifa vessel owner flags the vessel to adifferent country. This can apply toboth commercial and leisurevessels as it is normally associatedwith communications equipment.

Comment [A9]: Due to theaddition of XSD validation thenumber of instances must belimited suggest 50 note this isa limit on transmission in asingle message not the totallimit that a receiving or sendingsystem could hold

Comment [A10]: Needs to belimited due to validationsuggest 10 note this is a limiton transmission in a s inglemessage not the total limit thata receiving or sending systemcould hold


20/30



Page 20 of 30


VesselMO

InternationalMaritimeOrganisation Hullnumber

String No

For commercial vessels this is aunique number givenon construction and remains thesame for the duration that thevessel exists regardless ofownership etc.

VesselSeqNo

A sequentialnumber allocated toeach vessel in anincident

String No



PersonsInvolved

Enclosing tag whichcontainsinformation aboutall the personsinvolved

N/A No

Person

Enclosing tag whichcontainsinformation aboutone personinvolved

N/A No No limit to the number ofinstances.

PersonForenameForename of theperson involved

String No

PersonForename2Second Forenameof the personinvolved

String NoNot used by all C&C systems, so itis left as a free text field.

PersonForename3Third Forename ofthe person involved

String NoNot used by all C&C systems, so itis left as a free text field.

PersonSurnameSurname of theperson involved

String No

PersonSexGender (code) of

the person involvedString(1) No M, Male; F, Female; U, Unknown

PersonSexDescriptionGender(description) of theperson involved

String No


PersonAddressAddress of theperson involved

String No

PersonNumberPhone number ofthe person involved

String No

PersonDateOfBirth

Date of birth of theperson involved(formatDDMMYYYY)

Numeric No

PersonInvolvementInvolvement of theperson

String No


Comment [A11]: Consideration of the need to include a tomeet information sharingprotocols this could be:IMPLIED, EXPLICIT,

WITHDRAWN to reflectemergencies subsequentgathering and the real casewhere they request we DONOT

Comment [A12]: Due to theintroduction of XSD constraintthere should be a limit suggest50 note this is a limit ontransmission in a singlemessage not the total limit thata receiving or sending systemcould hold


21/30



Page 21 of 30


PersonArrestInd

To indicate that theperson has beenarrested inconnection with theincident

String No


PersonCasualtyIndTo indicate that theperson is a casualtyin connection withthe incident

String NoNot used by all C&C systems, so itis left as a free text field. Datamappings could be agreed in thisfield.

PersonConscious*

To indicate that theperson related tothe incident isconscious

String No

Added for receiving ambulanceC&C as this is key to their incidenttriage.

The absence of this field impliesUNKNOWN. Otherwise Y/N

PersonBreathing*

To indicate that theperson related tothe incident isbreathing

String No

Added for receiving ambulanceC&C as this is key to their incidenttriage


PersonSeriousBleeding*

To indicate that theperson related tothe incident isbleeding

String No

Added for receiving ambulanceC&C as this is key to their incidenttriage


PersonSuspectInd

To indicate that theperson is a suspectin connection withthe incident

String No


PersonVictimInd

To indicate that theperson is a victim inconnection with theincident

String No


PersonWitnessInd

To indicate that the

person is a witnessin connection withthe incident

String No

Not used by all C&C systems, so it

is left as a free text field. Datamappings could be agreed in thisfield.

PersonCommentAdditionalcomments aboutthe person involved

String No

PersonSeqNo

A sequentialnumber allocated toeach person in anincident

String No




22/30



Page 22 of 30

3.1.2 Incident Creation Acknowledgment Message

The Incident Creation Acknowledgement message is used to report back to the originatingsystem the success or failure of the receipt of an IncidentCreationmessage.

The following is the complete structure of the IncidentCreationAcknowledgementmessage shownwithout any data values:

Table 2 Incident Creation Acknowledgement Elements


MessageIdUnique ID of theIncidentCreation messagebeing acknowledged

String(18) Yes

OrigOrganisationCode of the organisationsending theacknowledgment

String Yes

OrigIncidentURN

Unique reference numberof the Incident created as

a result of receiving theIncidentCreationmessage, i.e. in the C&Csystem which sends theacknowledgement

String(24) Yes

This is the URN of theincident as used in the C&Csystem which received theIncidentCreationmessage.

If the incident creation failsthen a blank field can be sent.

OrigIncidentNum

Number of the Incidentcreated as a result ofreceiving theIncidentCreationmessage, i.e. in the C&Csystem which sends theacknowledgement

String(24) No

This is the incident number asknown by operators of theC&C system which receivedthe IncidentCreationmessage. The NSPIS C&Cincident numbers are re-incremented from 1 each day.

OrigIncidentDate

Creation date of theincident created as aresult of receiving theIncidentCreationmessage, i.e. in the C&Csystem which sends theacknowledgement (formatDDMMYYYY)

Numeric(8) No

This is the incident creationdate used in the C&C systemwhich received theIncidentCreationmessage.


23/30



Page 23 of 30


DestinOrganisationCode for the recipientorganisation


DestinIncidentURN

Unique reference numberof the incident in the C&Csystem which sent the

original IncidentCreationmessage

String(24) YesThis element is here for auditpurposes.

SuccessfulFlag to indicate whether ornot the incident creationwas successful

String(1) Yes Possible values are Y or N.

ErrorDescriptionText description of theerror in the event of afailure

String(300) No

Full error text should be usedinstead of an error code inorder to isolate each C&Csystem from the other.


24/30



Page 24 of 30

3.2 Incident Log Update

3.2.1 Incident Update Message

The Incident Update message is used by a sending organisation to notify another organisation ofupdates to an incident that has either been previously sent to that organisation or previouslyreceived from that organisation. The updates to an incident that may be sent between systems are

log entries (also known as log lines and comments); they are not actual field updates if this isrequired then another Incident Create Message (ICM) with a 'mode attribute of update MUST besent. To prevent update messages from being too large and to avoid the receiving C&C systemfrom being cluttered with a large number of log entries from a remote system, an update messageshould not contain more than one hundred log entries this is enforced in the XSD.

Although Systems are required to generate an Incident Creation Acknowledgement Message(ICAM) on receipt of an Incident this only indicates successful transmission through a HUB and/orinto a C&C system.

There is a need to improve the user experience through an acknowledgment sequence thatprovides positive delivery notification which, to avoid extending the interface, should beimplemented through this existing Incident Update Message (IUM) mechanism.

I.e. System developers MUST ensure the sending system generates an automatic IncidentUpdate Message (IUM) when a user has interacted with a generated incident utilising aIncident Creation Message has been

READ. This message MUST set the flag to Y. The receiving system could usefully include other data if it wishes such as the IncidentNumber from the original creation message. System developers MAY wish to consider this fieldas being a state of the main incident header so that all IUMs after a human interaction will havethe flag set.

In a similar vein it is suggested that developers SHOULD automate the transmission of an Incident

Closed message though a Incident XXXXX has been

CLOSED whenever a recipient organisation closes an Incident. Thereceiving system may wish to append the sending organisation name if the user interface does notdisplay this otherwise on messages.

The receiving system can decide what to do with Closed incidents either by re-opening themautomatically or it should respond with a suitable message using theNINCIDENT XXXXX already

CLOSED couplet. This is required so that sending systems canrespond correctly if they send updates to incidents that have been closed by the recipient

organisation.

Comment [A13]: Note thatthis would not be needed if thestandard required the use of anICM with a close attributewhich is an open discussionissue. Legacy Receivingsystems could convert it to alog entry like this.


25/30



Page 25 of 30

The following is the complete structure of the IncidentUpdatemessage shown without any datavalues:

Table 3 - IncidentUpdateElements

Element Description FormatMandator

yNotes

MessageIdUnique ID of the

message

String(16) Yes

For this message the length ofthe MessageId element is only16 characters due to alimitation of one of the C&C

systems participating inexchange of incidents with theHighways Agency.

OrigOrganisation

Code of theorganisation sendingthe incident updatemessage

String Yes

OrigIncidentURN

Unique referencenumber of the Incidentin the C&C systemwhich sends theincident update

String(24) NoThe unique identifier of theincident from which the updatesare being sent.

DestinOrganisationCode for the recipientorganisation


DestinIncidentURN

Unique referencenumber of the incidentin the C&C systemwhich receives theincident update

String(24) Yes

The unique identifier of theincident, on the receivingsystem, to which the updatesare to be applied.


26/30



Page 26 of 30


yNotes

OperationallyUrgent

A flag to denote thatthe contents of thismessage or log entryrequire urgentattention/action of thereceiving organisation.

String(1) No

Y/N but, Null or absence of theelement means for informationonly. It could be used to informthe receiving agency that theincident has escalated e.g.someone has declared a MajorIncident. Equally it could beused to inform the other agencythat they are no longer requirede.g. original ICM stated HouseFire Persons Reported.However the first attendancefrom Fire has established thatall persons are accounted forand that there are nocasualties. This would enableother agencies, particularlyHealth to stand down or re-direct their resources which is

just as important during timesof high demand.

ManualAcknowledgementFlag to indicate if thismessage originatedfrom a human

String(1) Yes

To enable the originatingorganisation to know that theinformation passed has beenacted on by a human thismeets international maritimerequirement and general goodpractice for 'Positive DeliveryNotification' (PDN).

This should be N for anysystem generated / autotransmitted messages and Yfor human created or actionedtransmission.

Comments

Enclosing element

which contains all thelog entries being sent

N/A YesCannot contain more than 100Comment elements.

Comment

Enclosing elementwhich contains thedetails of a log entrybeing sent

N/A Yes

CommentDescriptionContents of the logentry

String Yes

CommentDate

Date the log entry wascreated on the C&Csystem from which theupdate comes (formatDDMMYYYY)

Numeric(8) Yes

CommentTime

Time the log entry was

created on the C&Csystem from which theupdate comes (formatHHMMSS)

Numeric(6) Yes

Comment [A14]: To create atrue PDN this should bemandatory Post 1c versions.


27/30



Page 27 of 30


yNotes

CommentPriority

Priority of the log entryin the C&C systemfrom which the updatecomes

Numeric(1) NoData mappings could beagreed in this field.

CommentType

Type of log entry in

the C&C system fromwhich the updatecomes

String No

CommentOwner

Id of user that createdthe log entry on theC&C system fromwhich the updatecomes

String No

CommentLineNoA sequential numberallocated to each logentry in an incident

String NoNot used by all C&C systems,so it is left as a free text field.


28/30



Page 28 of 30

3.2.2 Incident Update Acknowledgment Message

The Incident Update Acknowledgement message is used to report back to the originating systemthe success or failure of the receipt of an IncidentUpdatemessage.

The following is the complete structure of the IncidentUpdateAcknowledgementmessage shownwithout any data values:

Table 4 - IncidentUpdateAcknowledgement Elements


MessageIdUnique ID of themessageacknowledged

String(16) Yes

For this message the length ofthe MessageId element is only 16characters due to a limitation ofone of the C&C systemsparticipating in the exchange ofincidents with the HighwaysAgency.

OrigOrganisation

Code of theorganisationsending theacknowledgment

String Yes

OrigIncidentURN

Unique referencenumber of theIncident in the C&Csystem whichsends theacknowledgement

String(24) No

This is the URN of the incident asused in the C&C system whichreceived the IncidentUpdatemessage.

Note that this element is notmandatory as it will not beavailable if the incident updatefails on the receiving C&Csystem.

OrigIncidentNum

Number of theIncident in the C&Csystem which

sends theacknowledgement

String(24) No

This is the incident number asknown by operators of the C&Csystem which received theIncidentUpdate message. The

NSPIS C&C incident numbersare re-incremented from 1 eachday.


29/30



Page 29 of 30


OrigIncidentDate

Creation date of theincident in the C&Csystem whichsends theacknowledgement(formatDDMMYYYY)

Numeric(8) No

This is the incident creation dateused in the C&C system whichreceived the IncidentUpdatemessage.

DestinOrganisationCode for therecipientorganisation


DestinIncidentURN

Unique referencenumber of theincident in the C&Csystem whichreceives theacknowledgement

String(24) Yes

Note that this element ismandatory. This is to cope withthe situation when an incident isexported twice to the samedestination. Having this field willenable the C&C system thatreceives the acknowledgement touniquely identify the incident.

Successful

Flag to indicatewhether or not the

incident update wassuccessful

String(1) Yes Possible values are Y or N.

ErrorDescriptionText description ofthe error in theevent of a failure

String(300) No

Full error text should be usedinstead of an error code in orderto isolate each C&C system fromthe other.


30/30

DOCUMENT CONTROL



Page 30 of 30

APPENDIX A - REFERENCES

References/Bibliography

NSPIS C&C Inter-Force Incident Exchange Interface V1b PO0890 NSPIS C&C/1530-XFI-049-042

APPENDIX B - GLOSSARY OF TERMS

Glossary of Terms

Term Definition

AVLS Automatic Vehicle Location System

BT British Telecom

C&C Command and Control

DTD Document Type Definition

EISEC Enhanced Information Service for Emergency Calls

HA Highways Agency

IP Internet Protocol

IPR Intellectual Property Rights

IT Information Technology

JESG Welsh Joint Emergency Services Group

NPIA National Policing Improvement Agency (most Information Services nowreturned to the Home Office)

NSPIS National Strategy for Police Information Systems

PSN Public Service Network

PDN Positive Delivery Notification an indication that a human and not a machinehas seen the information.

TCP/IP Transmission Control Protocol/Internet Protocol

User An individual using an organisational C&C system that has a MAIT interface

URN Unique Reference Number

VIN Vehicle Identification Number

VRM Vehicle Registration Mark

XFI XML/FML Interface

XML Extensible Markup Language

MAIT DRAFT 1d Exchange Candidate 5

Documents

Transcript of MAIT DRAFT 1d Exchange Candidate 5