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

Target Profiles

Target Profiles

Why This Page Exists

The translator does not stop at resource type. A Patient request can produce more than one valid R4 shape, and the same is true for Condition, Procedure, and the other supported routes.

This guide therefore treats the R4 target profile as part of the public contract. The client must choose which R4 family it wants, and the service must return output that fits that family.

The Two Target Families

The service currently documents two main target families:

  • nl-core 2020
  • eu-base

These are not interchangeable labels. They represent different target-side profile sets with different expectations, slicing rules, and terminology behavior.

nl-core 2020

nl-core 2020 is the Dutch R4 target family used when the result should fit the Dutch profile set that the project currently prefers for Dutch output.

In this repository, nl-core 2020 is the target family for routes such as:

  • Patient -> nl-core-Patient
  • Problem -> nl-core-Problem
  • Procedure -> nl-core-Procedure-event
  • FunctionalOrMentalStatus -> nl-core-FunctionalOrMentalStatus
  • AllergyIntolerance -> nl-core-AllergyIntolerance
  • Encounter -> nl-core-Encounter
  • CareTeam -> nl-core-CareTeam

Why it matters:

  • it is the preferred Dutch R4 basis for profiles that have a Dutch home
  • it usually carries Dutch-specific cardinalities, slicing, and extension rules
  • it is the profile family the translator uses when the requested target route is explicitly Dutch

Practical effect:

  • the translator must set the resulting resource meta.profile to the requested nl-core profile
  • validation is performed against that profile, not against plain base R4
  • the output may need Dutch-specific extensions or slices to be present even when the base resource type would otherwise be valid

eu-base

eu-base is the broader European R4 target family used when the desired output should fit the cross-border European profile set.

In this repository, eu-base is the target family for routes such as:

  • Patient -> patient-eu-core
  • Problem -> condition-eu-core
  • Procedure -> procedure-eu-core
  • FunctionalOrMentalStatus -> medicalTestResult-eu-core
  • AllergyIntolerance -> allergyIntolerance-eu-core
  • MedicationRequest -> medicationRequest-eu-core
  • MedicationStatement -> medicationStatement-eu-core

Why it matters:

  • it provides a different target contract than nl-core
  • it is the right choice when the receiving system expects the European family rather than the Dutch family
  • it may accept or require a different set of extensions, slices, and terminology bindings than nl-core

Practical effect:

  • the translator must preserve the requested eu-base profile on the output resource
  • validation is performed against the corresponding eu-base target profile
  • some resource types are available only in one target family in the current package set, so the route registry is explicit rather than inferred

nl-core 2020 Versus eu-base

The two families overlap in shape, but they are not the same contract.

Use nl-core 2020 when:

  • the Dutch output profile is the intended consumer contract
  • the source route has a clear Dutch semantic home
  • local Dutch slicing or extension requirements matter

Use eu-base when:

  • the consumer expects the European profile family
  • the route has a stable eu-base target in the installed package set
  • you want a cross-border output profile that is not tied to the Dutch nl-core shape

The service does not silently switch between them. The request should specify the target family explicitly, and the translation matrix must contain that exact pair.

How The Service Uses The Target Profile

The target profile affects three steps:

  1. The translation registry selects the route.
  2. The target-side map writes the correct profile-specific R4 structure.
  3. The validator checks the result against that exact target profile.

That means the target profile is part of the translation semantics, not just a validation annotation.

A Simple Rule Of Thumb

  • nl-core 2020 if the output should be Dutch-profile-first
  • eu-base if the output should be European-profile-first
  • base R4 only when the local package set does not currently provide a supported profile for that route