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
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
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. |
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. |
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: 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: 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: 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. |
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. |
These define constraints on FHIR data types for systems conforming to this implementation guide.
| 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. |
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. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| 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. |