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
The service does not accept a custom JSON schema.
You send standard FHIR JSON. For translation that means a FHIR Parameters resource containing:
source resource or bundlesourceProfile canonicaltargetProfile canonicalThe service returns a FHIR Parameters resource containing the translated R4 result and, when requested, a validation outcome and the intermediate logical model.
Run the published image:
docker run --rm -p 8080:8080 dev.cumuluz.org:5000/cumuluz-public/cumuluz-translate:latest
Or run the local compose setup:
docker compose up --build
Check the server:
curl http://localhost:8080/health
Expected response:
ok
The public deployment is currently available at:
https://translate.cumuluz.devThe same paths are used on the hosted deployment and the local deployment.
If you are integrating against the service for the first time, start with:
GET /fhir/stu3-r4/metadataGET /fhir/stu3-r4/OperationDefinition/bgz-transformGET /fhir/stu3-r4/translation-indexThese endpoints tell you:
The IG source includes concrete request and response JSON examples that match the live service. The patient example is intentionally rich so it shows the current mapped fields more clearly:
ig/input/examples/patient-transform-request.jsonig/input/examples/patient-transform-response.jsonig/input/examples/patient-validate-request.jsonig/input/examples/patient-validate-response.json{
"resourceType": "Parameters",
"parameter": [
{
"name": "source",
"resource": {
"resourceType": "Patient",
"meta": {
"profile": [
"http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient"
]
}
}
},
{
"name": "sourceProfile",
"valueCanonical": "http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient"
},
{
"name": "targetProfile",
"valueCanonical": "http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient"
}
]
}
Submit it:
curl -sS \
-H 'Content-Type: application/fhir+json' \
-d @request.json \
'http://localhost:8080/fhir/stu3-r4/$transform'
{
"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"
}
]
}
Submit it:
curl -sS \
-H 'Content-Type: application/fhir+json' \
-d @validate.json \
'http://localhost:8080/fhir/r4/$validate'
Use FHIR JSON.
In practice the runtime accepts standard JSON requests used in the tests and examples, but application/fhir+json is the clearest content type to send for interoperable clients.