Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AMedP-5.1
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.
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.
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.
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.
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.
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.
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.
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.
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.
Tell us how you need to work with AMedP-5.1 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
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.
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.
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.
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.
Edition A, Version 2, promulgated in May 2018. The document does not name an earlier edition it supersedes.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
Medical device manufacturers operate under more regulatory pressure than almost any other sector outside pharmaceuticals. The rules govern how you design a device, how you make it, how you track it after it ships, and how you respond when something goes wrong.
Learn how EU dual-use export controls apply to encryption, sensors, and software, how classification works under Annex I, and why sending source code by email can count as an export.
A practical way to turn in-your-head risk management into a register that survives staff turnover and answers the risk questions now showing up in tenders.