4. Reading the error report

Every validation — in the web validator, through the API or in a scenario — produces the same validation report. This chapter explains each part.

The verdict#

At the top you see Valid or Has errors, the resource type, and the profile that was used.

A resource is valid when it has no issues of severity fatal or error. Warnings and information messages never make a resource invalid.

Which profile was used?

If you chose Auto-detect, the sandbox uses the first NP Core profile in meta.profile. If there is none, it uses the general NP Core profile for the resource type (for example NP Core Patient for any Patient). Check the profile name in the verdict — validating a lab result against the generic Observation profile gives different results than against NP Core Laboratory Result Observation.

Severity#

Severity	Meaning	Must you fix it?
Fatal	The content could not be processed at all (e.g. broken JSON). Nothing else was checked.	Yes, first
Error	A SHALL rule of FHIR or NP Core is broken. Receivers may reject the data.	Yes
Warning	A SHOULD rule or best practice is not followed, or a code could not be fully checked.	Review; fix when you can
Information	Notes from the validator, e.g. about must-support or slices that did not match.	No

Fix fatal issues first and re-validate: once the content parses, more issues may appear.

Location paths#

Each issue has a location in FHIRPath-like notation:

Patient.identifier[1].system
Patient.address[0].extension[2].valueCoding.code
Bundle.entry[3].resource/*Observation/bp-1*/.component[0].valueQuantity

Indexes start at 0: identifier[1] is the second identifier.
Bundle.entry[3].resource is the fourth entry of a Bundle; the validator often adds the resource type and id in a comment /*Observation/bp-1*/.
A slice name appears after a colon: Patient.identifier:healthId.

In the web validator, click the location to jump to that line in the editor; the line is highlighted. When the validator reports a line and column (JSON and XML), the jump is exact.

Categories#

The sandbox groups issues into categories so you can see what kind of work is needed. Use the category filter in the results panel.

Category	Typical cause
Missing or repeated elements (cardinality)	A required element or slice is missing, or appears too often
Identifiers	Wrong or missing identifier `system`, missing Health ID / NHFR / council number
Codes & terminology	Code not in the bound value set, unknown code system, wrong display
References	Reference points to the wrong resource type or cannot be resolved
Data formats	Bad date, wrong JSON type, invalid characters, malformed JSON
Profile rules	Fixed/pattern value not matched, element not allowed, unknown extension
Structure	Unknown property, empty element, wrong order (XML)
Business rules (invariants)	An NP Core or FHIR rule such as `np-prac-1` or `np-addr-1` failed

Terminology: warnings vs errors#

Terminology issues are the most confusing, because the same mistake can be an error or a warning depending on the binding strength:

Binding strength	Code not in value set gives
`required`	Error
`extensible`	Warning if a suitable code exists in the value set, otherwise allowed
`preferred` / `example`	Information or nothing

Other terminology messages you may see:

"Unknown code system" — usually a typo in system, or a local code system. Check the system URI against the Profiles browser.
"Wrong display" — the display text does not match the code system's display. Usually a warning. Copy the official display, or omit display.
"Unable to check … external terminology" — the sandbox does not have a full copy of large external terminologies such as SNOMED CT or LOINC, so it cannot always confirm a code. This is a warning, not a failure of your data. Double-check the code yourself.

The issue card#

Each issue card has:

Title — a short plain-language name of the problem.
What it means — the problem in simple words.
Why — why FHIR or NP Core has this rule.
How to fix — concrete steps.
Example — a JSON snippet with a Copy button.
Open in IG — the IG page that defines the rule.
Raw validator message — the original text from the HL7 validator (include it when asking for help).

Download JSON report saves the full report, including the raw OperationOutcome. Attach it to your bug tracker.
Print gives a clean printable view of the results.
Every validation is saved in Run history, where your team can open it again.

API responses#

Through the API you receive the same information. POST /api/validate returns the report as JSON; the FHIR endpoint returns a FHIR OperationOutcome where each issue has the explanation in diagnostics and in an extension. See Machine testing via the API.