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

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Behavior: Capability Statements

The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.

Cumuluz R4 Validation CapabilityStatement

CapabilityStatement for the R4-facing validation surface exposed under /fhir/r4.

Cumuluz STU3 to R4 Translation CapabilityStatement

CapabilityStatement for the cross-version translation surface exposed under /fhir/stu3-r4.

Behavior: Operation Definitions

These are custom operations that can be supported by and/or invoked by systems conforming to this implementation guide.

BgZ 2017 STU3 to R4 Transform

System-level operation for translating a supported Dutch STU3 source resource or bundle into a supported R4 target profile.

QuestionnaireResponse Extraction

System-level operation for extracting supported QuestionnaireResponses into an R4 resource Bundle selected by profile or questionnaire canonical.

Structures: Logical Models

These define data models that represent the domain covered by this implementation guide in more business-friendly terms than the underlying FHIR resources.

Logical Model: Allergy Intolerance

Canonical intermediate logical model for AllergyIntolerance translation. It is shaped to the AllergyIntolerance core structure, aligned with eu-base as the structural baseline, and extended only where Dutch zib and nl-core allergy semantics require explicit fields.

Logical Model: Allergy Intolerance Note

Named logical child type for AllergyIntolerance notes so author metadata can survive the intermediate logical model.

Logical Model: Allergy Intolerance Reaction

Named logical child type for allergy reaction details in the intermediate allergy intolerance model.

Logical Model: Allergy Intolerance Reference

Named logical child type for AllergyIntolerance references that may carry the Dutch practitionerrole-reference extension.

Logical Model: Appointment

Canonical intermediate logical model for Appointment translation. It is shaped closely to R4 Appointment while preserving Dutch STU3 additions only where they have a target home.

Logical Model: Appointment Participant

Named logical child type for appointment participants that may carry a Dutch practitionerrole-reference extension.

Logical Model: Care Team

Canonical intermediate logical model for CareTeam translation. It is shaped closely to R4 CareTeam while preserving Dutch STU3 practitioner role handling explicitly where needed.

Logical Model: Care Team Participant

Named logical child type for care team participants that may carry a Dutch practitionerrole-reference extension.

Logical Model: CommunicationRequest

Canonical intermediate logical model for CommunicationRequest translation. It is source-family neutral and includes the R4 request semantics needed across STU3/BgZ sources.

Logical Model: Consent

Canonical intermediate logical model for Consent translation. It is source-family neutral and maps the R4 Consent shape that can be reached from STU3/BgZ sources through the converter.

Logical Model: Device

Canonical intermediate logical model for Device translation. It is source-family neutral and mirrors the R4 Device resource shape for STU3/BgZ reuse.

Logical Model: DeviceUseStatement

Logical intermediate model for DeviceUseStatement translation. It is source-family neutral and captures the R4 request/requester shape independent of the STU3 source.

Logical Model: Encounter

Canonical intermediate logical model for Encounter translation. It is shaped to the R4 Encounter structure where practical, while keeping the Dutch STU3 zib encounter additions explicit.

Logical Model: Encounter Hospitalization

Named logical child type for encounter hospitalization details that survive the logical handoff.

Logical Model: Encounter Participant

Named logical child type for encounter participant details.

Logical Model: Encounter Reference

Named logical child type for encounter references that may carry a Dutch practitionerrole-reference extension.

Logical Model: Extraction Bundle

Generic intermediate bundle graph populated by maps before materialization into a FHIR Bundle.

Logical Model: Extraction Entry

Generic mapped instruction for one resource entry in an extraction Bundle. The map owns target routing metadata and the logical resource body.

Logical Model: Functional Or Mental Status

Canonical intermediate logical model for FunctionalOrMentalStatus to Observation translation. It is shaped to the Observation core structure, aligned with eu-base medical test result semantics as the structural baseline, and extended with Dutch zib and nl-core functional or mental status semantics only where needed.

Logical Model: Functional Or Mental Status Component

Named logical child type for Observation.component content in the intermediate functional or mental status model.

Logical Model: Functional Or Mental Status Reference Range

Named logical child type for Observation.referenceRange content in the intermediate functional or mental status model.

Logical Model: Goal

Canonical intermediate logical model for Goal translation. It is source-family neutral and aligns to the R4 Goal structure for translation reuse.

Logical Model: Medication Dispense

Canonical intermediate logical model for administration agreement to medication dispense translation. It is shaped closely to R4 MedicationDispense with explicit Dutch source additions only where needed.

Logical Model: Medication Dosage

Named logical child type for medication dosage details in the intermediate medication models.

Logical Model: Medication Performer

Named logical child type for medication dispense performers.

Logical Model: Medication Reference

Named logical child type for medication-related references that may carry a Dutch practitionerrole-reference extension.

Logical Model: Medication Request

Canonical intermediate logical model for medication agreement to medication request translation. It is shaped closely to R4 MedicationRequest with explicit Dutch source additions only where needed.

Logical Model: Medication Statement

Canonical intermediate logical model for medication use to medication statement translation. It is shaped closely to R4 MedicationStatement with explicit Dutch source additions only where needed.

Logical Model: Metadata

Canonical intermediate logical model for BgZ metadata translation. It is shaped closely to R4 Provenance and preserves only the BgZ metadata content currently translated by this service.

Logical Model: Metadata Agent

Named logical child type for provenance agents in the intermediate metadata model.

Logical Model: Observation

Canonical intermediate logical model for Observation translation. It is source-family neutral and aligns with the R4 Observation resource for reuse across source variants.

Logical Model: Patient

Canonical intermediate logical model for Patient translation. It is shaped to the full Patient core structure, aligned with eu-base as the structural baseline, and extended with Dutch zib and nl-core patient semantics using future-oriented normalized field names.

Logical Model: Patient Communication

Named logical child type for patient communication details in the intermediate patient model.

Logical Model: Patient Communication Proficiency

Named logical child type for patient language proficiency details in the intermediate patient model.

Logical Model: Patient Contact

Named logical child type for patient contact details in the intermediate patient model.

Logical Model: Patient Link

Named logical child type for patient linkage details in the intermediate patient model.

Logical Model: Patient Nationality

Named logical child type for patient nationality details in the intermediate patient model.

Logical Model: Practitioner

Canonical intermediate logical model for Practitioner translation. It is source-family neutral and mirrors the R4 Practitioner profile surface for STU3/BgZ-neutral reuse.

Logical Model: PractitionerRole

Canonical intermediate logical model for PractitionerRole translation. It is source-family neutral and mirrors the R4 PractitionerRole structure for STU3/BgZ-neutral conversion workflows.

Logical Model: Problem

Canonical intermediate logical model for Problem to Condition translation. It is shaped to the full Condition core structure, aligned with eu-base as the structural baseline, and extended with Dutch zib and nl-core problem semantics using future-oriented normalized field names.

Logical Model: Problem Body Site

Problem body site details kept together so anatomical location, laterality, and future body structure references survive the intermediate logical model without losing their relationship.

Logical Model: Problem Evidence

Named logical child type for condition evidence details in the intermediate problem model.

Logical Model: Problem Stage

Named logical child type for condition stage details in the intermediate problem model.

Logical Model: Procedure

Canonical intermediate logical model for Procedure translation. It is shaped to the full Procedure core structure, aligned with eu-base as the structural baseline, and extended with Dutch zib and nl-core procedure semantics using future-oriented normalized field names.

Logical Model: Procedure Body Site

Procedure body site details kept together so anatomical location and laterality survive the intermediate logical model without losing their relationship.

Logical Model: Procedure Focal Device

Named logical child type for procedure focal device details in the intermediate procedure model.

Logical Model: Procedure Performer

Named logical child type for procedure performer details in the intermediate procedure model.

Logical Model: Questionnaire Answer

Normalized single questionnaire answer slot populated from a version-specific QuestionnaireResponse item.

Logical Model: Questionnaire Form

Shared intermediate logical model for QuestionnaireResponse extraction. Version-specific StructureMaps normalize questionnaire items into named generic answers and groups before extraction maps interpret those names into clinical logical resources.

Logical Model: Questionnaire Telecom

Normalized grouped questionnaire telecom answer populated from a repeated phone or email item group.

Logical Model: RelatedPerson

Canonical intermediate logical model for RelatedPerson translation. It is source-family neutral and mirrors the R4 RelatedPerson shape for STU3/BgZ-neutral reuse.

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

BgZ Patient Stub

Lightweight local profile stub that anchors the BgZ Patient canonical used in the published examples.

Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide.

Translation target profile

Selects the target profile for one Bundle entry in a transform request.

Validation issue count: error

Counts the number of validation issues with severity error.

Validation issue count: information

Counts the number of validation issues with severity information.

Validation issue count: warning

Counts the number of validation issues with severity warning.

Validation relaxed issue count

Counts validation issues relaxed by the runtime.

Terminology: Naming Systems

These define identifier and/or code system identities used by systems conforming to this implementation guide.

Dutch BSN NamingSystem

Minimal NamingSystem definition so examples that use the BSN identifier system can resolve offline.

Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

bundle-transform-request
patient-transform-request

Example BgZ transform request for a single Patient.

patient-transform-response

Example transform response for a single Patient.

patient-validate-request

Example R4 validation request for a translated Patient.

patient-validate-response

Example validation result for a translated Patient.

patient-validate-response-fail