mait draft 1d exchange candidate 5
TRANSCRIPT
-
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).
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
2/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
3/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
4/30
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
5/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
6/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
7/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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/12/2019 MAIT DRAFT 1d Exchange Candidate 5
8/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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).
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
9/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
10/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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: ,
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
11/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
12/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 12 of 30
The following is the complete structure of the IncidentCreationmessage shown without any data values:
Deprecated
Deprecated
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
13/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 13 of 30
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
14/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
15/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 15 of 30
Element Description Format Mandatory Notes
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
16/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 16 of 30
Element Description Format Mandatory Notes
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
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
17/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 17 of 30
Element Description Format Mandatory Notes
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.
Truncation may be needed in someC&C systems.
RVP.YOS grid referencenorthing
String(7) No
7 digits are used to cover areas inScotland.
Truncation may be needed in someC&C systems.
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
18/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 18 of 30
Element Description Format Mandatory Notes
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
19/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 19 of 30
Element Description Format Mandatory Notes
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
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
20/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 20 of 30
Element Description Format Mandatory Notes
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
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
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
Not used by all C&C systems, so itis left as a free text field. Datamappings could be agreed in thisfield.
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
Not used by all C&C systems, so itis left as a free text field. Datamappings could be agreed in thisfield.
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
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
21/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 21 of 30
Element Description Format Mandatory Notes
PersonArrestInd
To indicate that theperson has beenarrested inconnection with theincident
String No
Not used by all C&C systems, so itis left as a free text field. Datamappings could be agreed in thisfield.
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
The absence of this field impliesUNKNOWN. Otherwise Y/N
PersonSeriousBleeding*
To indicate that theperson related tothe incident isbleeding
String No
Added for receiving ambulanceC&C as this is key to their incidenttriage
The absence of this field impliesUNKNOWN. Otherwise Y/N
PersonSuspectInd
To indicate that theperson is a suspectin connection withthe incident
String No
Not used by all C&C systems, so itis left as a free text field. Datamappings could be agreed in thisfield.
PersonVictimInd
To indicate that theperson is a victim inconnection with theincident
String No
Not used by all C&C systems, so itis left as a free text field. Datamappings could be agreed in thisfield.
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
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
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
22/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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
Element Description Format Mandatory Notes
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
23/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 23 of 30
Element Description Format Mandatory Notes
DestinOrganisationCode for the recipientorganisation
String Yes Destination organisation.
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
24/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
25/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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
String Yes Destination organisation.
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
26/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 26 of 30
Element Description FormatMandator
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
27/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 27 of 30
Element Description FormatMandator
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
28/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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
Element Description Format Mandatory Notes
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
29/30
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
Page 29 of 30
Element Description Format Mandatory Notes
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
String Yes Destination organisation.
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.
-
8/12/2019 MAIT DRAFT 1d Exchange Candidate 5
30/30
DOCUMENT CONTROL
MAIT 1d XML Interchange FormatInterface Specification
Issued: 28 March 2014Issue: DRAFT 1d Candidate 5
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