Cumuluz Translate Implementation Guide
0.1.0 - ci-build
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
Use POST /fhir/r4/$validate to validate an existing R4 resource against a requested R4 profile. This independent operation definition is different from transform-time validation, which also validates the source and logical stages and applies route governance. The system-level and type-level endpoints are available.
The preferred request is FHIR Parameters:
| Parameter | Cardinality | Meaning |
|---|---|---|
resource |
1..1 |
R4 resource to validate |
profile |
0..1 |
target profile canonical; defaults to resource.meta.profile |
mode |
0..1 |
create or update; delete is unsupported |
The endpoint also accepts a direct R4 resource body when meta.profile identifies the profile. The complete synthetic request is published as Patient validation request.
curl -sS \
-H 'Accept: application/fhir+json' \
-H 'Content-Type: application/fhir+json' \
--data @ig/input/examples/patient-validate-request.json \
'http://localhost:8080/fhir/r4/$validate'
Type-level forms such as POST /fhir/r4/Patient/$validate are also available. They reject a resource with a different resourceType. Use the CapabilityStatement for the complete current type list rather than copying a static inventory into client code.
Every processed validation request returns an R4 OperationOutcome. HTTP status tells whether the request was processed; issue severity tells whether the resource passed validation.
| Situation | HTTP status | Client decision |
|---|---|---|
validation ran with no error or fatal |
200 |
resource passed; warnings may remain |
validation ran with error or fatal |
200 |
resource failed validation |
| request could not be processed | 400 |
correct the envelope, mode, profile or resource type |
See passing validation response and failing validation response.
A client must evaluate OperationOutcome.issue[*].severity. It may use these count extensions for automation:
| Extension suffix | Meaning |
|---|---|
validation-issue-count-error |
error plus fatal issues after service filtering |
validation-issue-count-warning |
warning issues |
validation-issue-count-information |
informational issues |
validation-relaxed-issue-count |
narrow logged HAPI slice-compatibility exceptions |
The relaxed count is not permission to ignore other errors. Store the outcome with the validated resource when auditability is required.
validationMode on $transform controls the full source-to-target pipeline:
| Mode | Result |
|---|---|
enforce |
blocks on unrelaxed error/fatal issues and blocked governance decisions; the only conforming mode |
report |
returns output and diagnostics; always non-conformant |
none |
skips validation when operator-enabled; always non-conformant |
QuestionnaireResponse extraction uses its separate validate boolean.
GET /fhir/r4/metadataGET /fhir/r4/OperationDefinition/r4-validate