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 translation service does not map directly from STU3 source semantics into target profiles. It passes through a logical layer that keeps the shared meaning explicit and inspectable.
That logical layer is not an implementation detail hidden in code. The source definitions live in the repository's logical-models/ project, and the published IG includes the generated StructureDefinition artifacts for the three core route models.
The published IG includes only the logical model artifacts needed for the core route set:
LogicalPatientLogicalProblemLogicalProcedureThe full logical-model source tree remains in the repository under logical-models/input/fsh, but the published IG keeps the surfaced set focused so the warning volume stays manageable.
The most important logical models for the current implementation are:
These are the models that matter most for the initial supported concept set and they are the easiest place to understand the translation shape.
The logical models are intentionally close to the target-side meaning.
They:
sourceProfile and targetProfileAfter a build, the generated logical model artifacts are available in the IG output and published as StructureDefinition pages for the three core models.
The build also stages the generated JSON into a gitignored input folder so the IG Publisher can include them without polluting the repository history.
That order shows the semantic contract before the concrete model details.