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.

Main Target Families

The service currently documents three main target families for BgZ-facing routes:

  • nl-core 2020
  • eu-base
  • EPS

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

The service also supports explicit PZP 2020 ACP target profiles for the implemented PZP 2017 to PZP 2020 profile-pair routes.

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

EPS

EPS is the HL7 Europe Patient Summary target family. It is a document-oriented target on top of EU Base/Core rather than a replacement for eu-base.

In this repository, EPS is currently supported for:

  • Patient -> patient-eu-eps
  • Problem -> condition-obl-eu-eps
  • Procedure -> procedure-eu-eps
  • AllergyIntolerance -> allergyintolerance-obl-eu-eps
  • MedicationRequest -> medicationrequest-obl-eu-eps
  • MedicationStatement -> MedicationStatement-eu-eps
  • PZP ACP-AdvanceDirective and ACP-TreatmentDirective -> consent-eu-eps
  • PZP ACP-HealthProfessional-Practitioner -> practitioner-obl-eu-eps
  • PZP ACP-HealthProfessional-PractitionerRole -> practitionerrole-obl-eu-eps
  • PZP ACP-MedicalDevice.Product-ICD -> device-eu-eps
  • PZP ACP-MedicalDevice -> deviceUseStatement-eu-eps
  • STU3 source Bundle -> bundle-eu-eps document Bundle

The EPS StructureMaps import the corresponding logical-to-eubase maps or neutral shared logical-to-R4 helper groups, then set the EPS profile. They do not import PZP target maps. Bundle output assembles the document envelope and Composition sections after supported entries have gone through the logical model and EPS resource maps. PZP Practitioner and PractitionerRole EPS routes are single-resource transforms; they are not standalone EPS document Bundle entries until the Composition section model has an appropriate section or reachable reference path.

The broader EHDS/EPS package contains more model profiles than the implemented route set. See EHDS / EPS Coverage for the complete implemented/gap matrix across BgZ and PZP source routes.

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
  • EPS if the output should be a European Patient Summary profile or document Bundle
  • PZP 2020 ACP if the source is one of the supported PZP 2017 ACP profile pairs
  • base R4 only when the local package set does not currently provide a supported profile for that route

PZP 2020 ACP

PZP 2020 ACP profiles are supported for explicit PZP 2017 ACP source profile pairs. These routes are not a general resource-type conversion mode. Each source profile has one registered PZP 2020 target profile, and each route goes through a shared logical model with explicit source-to-logical and logical-to-PZP StructureMaps.

The current PZP target family includes Patient, Encounter, Procedure, Consent-based ACP directives, RelatedPerson, Practitioner, PractitionerRole, CommunicationRequest, Device, DeviceUseStatement, Goal, and Observation-based ACP choices.

PZP 2017 ACP sources also have explicit non-PZP target routes where the shared logical model validates against the installed generic parent profile. ACP-Patient targets nl-core-Patient, patient-eu-core, and patient-eu-eps; other supported generic PZP targets use the installed nl-core parent profile, a concrete EPS profile where registered, or, for non-nl-core-derived profiles, the base R4 parent profile.

The inverse is not true for generic BgZ input. BgZ resources are not accepted as PZP ACP targets, and PZP ACP-Procedure is not exposed as an EU Base or EPS Procedure source route. Those unsupported routes return OperationOutcome errors instead of inventing missing ACP-specific or performed-time semantics.