Cumuluz Translate Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Validate

Validate

Main Endpoint

POST /fhir/r4/$validate

This endpoint validates an R4 resource against a requested target profile.

The service validates on the R4 side only. It does not expose source-side STU3 validation as part of the public contract.

Accepted Request Shapes

The validation surface accepts either:

• a FHIR Parameters request with resource and profile
• a direct R4 resource request where the profile is carried in meta.profile

The Parameters form is the clearest and is the preferred form for clients.

Parameters Request

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "resource",
      "resource": {
        "resourceType": "Patient",
        "meta": {
          "profile": [
            "http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient"
          ]
        }
      }
    },
    {
      "name": "profile",
      "valueCanonical": "http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient"
    }
  ]
}

Type-Level Validation Endpoints

The service also exposes type-level validation routes for currently supported R4 resource types:

• POST /fhir/r4/Patient/$validate
• POST /fhir/r4/Condition/$validate
• POST /fhir/r4/Procedure/$validate
• POST /fhir/r4/Observation/$validate
• POST /fhir/r4/AllergyIntolerance/$validate
• POST /fhir/r4/Encounter/$validate
• POST /fhir/r4/CareTeam/$validate
• POST /fhir/r4/Appointment/$validate
• POST /fhir/r4/MedicationRequest/$validate
• POST /fhir/r4/MedicationStatement/$validate
• POST /fhir/r4/MedicationDispense/$validate
• POST /fhir/r4/Provenance/$validate

These routes reject mismatched resource types.

For example, POST /fhir/r4/Procedure/$validate rejects a Patient body with an OperationOutcome.

Response

The validation response is a FHIR OperationOutcome.

Current HTTP behavior is:

• 200 when the outcome contains only information or warning
• 400 when the outcome contains error or fatal

That means clients should inspect both:

• the HTTP status
• the issues in the returned OperationOutcome

Practical Interpretation

The validator is intentionally useful for target-side quality checks, but not every warning means the translation failed.

Current known behavior includes:

• informative or warning-level messages for some offline package or slice-resolution cases
• non-blocking warnings where the output is still structurally acceptable for the intended route

Example Files

• ig/input/examples/patient-validate-request.json
• ig/input/examples/patient-validate-response.json

Clients that need a strict go/no-go decision should treat error and fatal as blocking and review warnings according to their own policy.

Target Families

Validation follows the same target families as translation.

• validate against nl-core 2020 when the translated output is meant to fit the Dutch profile family
• validate against eu-base when the translated output is meant to fit the European profile family

For background on the target families themselves, see Target Profiles.

Validation Metadata

GET /fhir/r4/metadata returns a FHIR CapabilityStatement describing the R4-facing validation surface and the supported target profiles per resource type.