Start a free trial
Menu

AMedP-5.1

AMedP-5.1 patient data exchange format for common core information

The nation or NATO Command Structure building a computerised medical reporting system that will exchange casualty or patient reports with an ally or a NATO command

AMedP-5.1 sets a common list of data elements for medical data exchange between nations and NATO commands, so computerised reporting systems can share casualty and patient information without relying on one shared national coding system.

Edition
A
Published
2018-05

What it is

AMedP-5.1 is the NATO Allied Medical Publication that carries the technical detail behind STANAG 2231, and it "has been prepared under the reference of STANAG 2231." Its aim is "to standardize data elements for medical data exchange among and between nations and between nations and NATO headquarters." It is not a message standard in its own right. It is a shared dictionary of individual data elements - who the patient is, where and how they were injured, who first treated them, which facility is treating them now, their triage status, their evacuation priority, their basic vital signs, and a set of free-text fields for clinical narrative - that a nation's own computerised reporting systems draw on when they need to describe the same thing the same way another nation's system will recognise.

A dictionary, not a fixed report

The document is explicit that it does not create a report format: it states plainly that it is "not the intent of this document to create any required report format." Instead, whoever designs a specific message - a disease-surveillance report, a casualty movement request - picks only the fields that message needs from the shared list. The document illustrates this with two worked examples built from different subsets of the same dictionary, describing the approach as similar to building with a set of standard bricks: no single message is expected to use every field the document defines. In both examples the chosen fields sit between an "HL7 Identification block" and an "HL7 Message Closing Block," so the dictionary is designed to populate an HL7-formatted message rather than to stand alone as one.

The document does not address confidentiality, consent, access control or security for the data it standardises. No clause anywhere in the text says how the information these fields carry should be protected once it has been exchanged.

What it leaves to each nation

AMedP-5.1 does not reach into a nation's own internal medical records. It "does not mandate the use of any specific storage format or database system within the national medical records systems," and separately states that it "does not mandate that the nations adopt SNOMED-CT as a storage coding system for their own national reference systems" in place of ICD-9, ICD-10 or any other national coding system. The common format only comes into play once information crosses the boundary the document describes: it "applies only when transferring information between nations or between nations and NATO commands," with force "within and between NATO members' medical facilities, and between national medical force structures and the NATO Command Structure."

That boundary is the reason the document exists in the first place. Chapter 1 sets out the problem directly: many reporting requirements are "still paper-based," terminology is not coordinated between them, and nations record clinical data under different national and NATO coding systems - the document names ICD-9, ICD-10, ICPC-1 and ICPC-2 - which "are not always mutually intelligible," so a recipient may have no idea what a transmitted code actually means.

The formatting rules behind every field

A short set of mechanical rules applies across the whole dictionary. Date and time are always given in Zulu time as an unbroken 14-digit string, a format the document deliberately departs from the date-time group used in AAP-6 because, in its own words, its version is "a more logical form for automated systems" - it even notes that "a proposed change to AAP-6 to recognize this fact will be submitted." Alphanumeric fields carry no diacritical marks or separators and are left-justified; numeric fields are right-justified; and every message is required to open with the sender's armed forces of origin, a service or system identifier, and the date-time group before anything else.

What the dictionary actually covers

The data elements themselves, set out in an annex, run to around a hundred numbered fields grouped by subject: identification of the patient and their armed forces of origin; the location and circumstances of the injury and whether protective equipment was worn; the training level of the first person who treated them; environmental conditions at the point of injury; the treating medical facility, its role, location and bed capacity; triage status; medical care and evacuation requirements, including priority and dependency categories for aeromedical evacuation; the evacuation vehicle's capability and capacity; and a run of basic clinical data - vital signs, the Glasgow Coma Scale, medications and how they were given, interventions performed, IV fluids and blood group. A separate, later block covers hospital-stay data, and it is worth noting where the design changes: history, examination findings, orders, test results, diagnosis and treatment recommendations are all left as free text rather than forced into a code, alongside numeric fields for outcomes such as ventilator days and time in intensive care.

Several of these fields do not set their own values; they point outward. Nation and geographic codes come "according to STANAG 1059," military rank codes "according to STANAG 2116," grid references "in accord with STANAG 2211," aeromedical evacuation categories "as found in STANAG 3204," and triage categories "from AMEDP-24." A system implementing this dictionary is, in practice, also implementing those.

Where the related documents sit

The closing annex lists a further set of publications that "should be considered in developing medical reporting systems and formats for use in the multinational NATO environment." That framing reads as advisory for the list as a whole, but several of the same documents are pulled in directly, and more firmly, by the individual field definitions described above.

Getting the document

AMedP-5.1 is free of charge, published by the NATO Standardization Office. We do not sell it or host a copy. It can be retrieved from the NATO Standardization Document Database, where NATO should be credited on reproduction.

How we help

AMedP-5.1 specifies a data format for computerised medical reporting systems exchanging casualty and patient information between nations and NATO commands. ComplyTrain is a compliance and quality-management platform, not a medical information system: it does not exchange, store or process patient data, and this document's field-by-field dictionary is not something it implements or maps to. The fit here is limited, and it would not be honest to suggest otherwise.

Where ComplyTrain can help is one step removed from the data itself. An organisation that develops or operates a system meant to exchange reports under this kind of agreement still has to hold its own evidence that the work was done properly: the procedure describing how the system's data model was built against the field list, the training record showing staff who populate or interpret these reports were trained on the current version, and a record of which related NATO documents a given field implementation relies on. ComplyTrain gives an organisation a controlled place to hold and version that kind of procedure and record, separate from the medical data itself. It does not build, test or operate the reporting system, and it does not touch a patient record.

If you are working out what a NATO medical interoperability requirement means for your own organisation's documentation, the standards explorer lists the related publications this dictionary draws on, or talk to us about the evidence side of that work.

Standards it references

Questions

Is AMedP-5.1 mandatory?

It binds through STANAG 2231, the agreement nations ratify to commit to using it. Ratification is a national act and can carry reservations, as Belgium and the United Kingdom recorded at this promulgation. AMedP-5.1 does not describe a contract mechanism reaching a supplier directly the way a procurement standard does.

Does AMedP-5.1 require nations to use SNOMED-CT?

No. The document states plainly that it "does not mandate that the nations adopt SNOMED-CT as a storage coding system for their own national reference systems," and leaves the choice of national coding system, including ICD-9 or ICD-10, to each nation.

What is the difference between AMedP-5.1 and STANAG 2231?

STANAG 2231 is the agreement by which NATO nations commit to use this publication. AMedP-5.1 is the technical document itself, carrying the data elements and formatting rules the agreement points to.

Does AMedP-5.1 define a specific message format?

No. It defines a common list of data elements and states directly that it is "not the intent of this document to create any required report format." Whoever designs a particular message selects only the fields that message needs.

What edition of AMedP-5.1 is current?

Edition A, Version 2, promulgated in May 2018. The document does not name an earlier edition it supersedes.