Integration boundary
API, SDK, profile and adapter contracts for explicitly named target systems and versions.
Platform architecture
Open integration boundaries. Project-specific runtime ownership.
MEMM structures technical responsibility into distinct layers. The model describes architecture and development direction; it is not a blanket promise of production operation, platform coverage or specification conformance.
Platform boundaries
Runtime boundary
Processing, state and failure contracts with named technical ownership.
Access & policy
Separate identity, policy and execution decisions inside the agreed scope.
Release references
Binding source state, configuration, verification environment and result to a concrete version.
Regulatory Change Containment
A specification change should not automatically become a cross-system redesign.
The objective is not to avoid Zulassung, qualification or regulatory review. The objective is to bound the technical change surface: external deltas are handled where they arise, while host contracts remain stable as long as the defined product boundary is not crossed.
Illustrative anti-patternDistributed change surface
External
delta
delta
Web ClientBackendBusiness logicRegression / Evidence
When external protocol or specification semantics are distributed across several host layers, even a bounded delta can touch multiple teams and release surfaces at once.
MEMM target modelBounded change surface
External
delta
delta
MEMMControlled Boundaryadapt · validate · version · evidence
Stable
Contracts
Contracts
Web / UIBackendBusiness processes
MEMM is intended to keep external changes inside a controlled product surface. Only when a delta actually changes the agreed boundary does it become a host or architecture change.
From delta to release
Four controlled questions before a host change.
The four steps are an architecture and review logic, not a statement about Zulassung scope or actual savings in a specific project.
01AdaptationWhat changed externally?
02ValidationWhich boundary is actually affected?
03VersioningDoes a public contract change?
04EvidenceWhich evidence must be renewed?
Product boundary: MEMM promises neither less regulation nor fewer Zulassung steps. The architecture aims to avoid unnecessary cross-system changes where external deltas can be contained inside the agreed MEMM scope. Go deeper on specification change →
Integration Contracts
Stable product contracts instead of protocol-internal coupling.
Applications and partners should integrate against named interfaces, data shapes and error semantics rather than internal details of external engines or moving specification drafts.
4contract layers
C1API / SDKcall and lifecycle boundaries
C2Service / Workflowhand-offs and state boundaries
C3Data / Profilesversioned data shapes
C4Errors / Lifecyclerejection, retry and migration
Four equal categories — not weighting, maturity or progress.
Healthcare application / OEMProduct logiccustomer-side context
Versioned contractsAPI / SDKService / WorkflowData / ProfilesErrors / Lifecycle
MEMM product boundaryRust-based coreinternal implementation remains separate from the public contract
External contextsTI-M / FHIR® / servicesversion- and project-specific
TI 2.0 control boundaries
Keep external TI services separate from internal product responsibility.
Software-based TI access, digital identities and Zero Trust change the integration environment. MEMM treats them as named external and control boundaries rather than silently merging them into one product core.
TI access remains external
TI-Gateway and approved access services are outside the MEMM product boundary. MEMM is not described as a connector or TI-Gateway replacement.
Identity evidence is versioned
The current development model maps external EUDI Wallet, Health ID and eID-LE evidence through a versioned adapter boundary into canonical identity and attribute contexts. Verification and application authorization remain separate.
Zero Trust remains an architecture reference
Explicit identity, attribute, policy and execution decisions support a Zero-Trust-oriented separation. No ZETA integration or general OIDC/federation support is inferred.
Architecture & quality goals
Ownership should remain explicit and reviewable.
These are development and verification criteria. Whether they are met by a concrete version depends on that release and its evidence.
Event-oriented state changes
Changes should flow through named event and subscription paths. Externally required polling remains an explicitly documented boundary.
Explicit rejection
Missing configuration, unknown versions or insufficient permissions should result in typed rejection instead of silent fallbacks.
One canonical owner
State, workflow, identity, routing and evidence references should each have a named authoritative owner.
Bounded resources
Backpressure, limits and controlled retries should avoid unbounded processing and unclear side effects.
Versioned Extensibility
Changing specifications, stable product boundaries.
External profiles, drafts and integration requirements can evolve. Versioned adapters and contracts should absorb these changes without automatically changing the product core promise.
Changing external worldProfiles · Drafts · Provider APIs · Target systemseach may have its own version and lifecycle
Stable product boundaryDomain state · Error semantics · Release identitychanges are reviewed in a controlled, release-bound way
Boundary: separating adapter and product boundaries is an architecture principle. It does not mean a particular external profile, draft or platform is supported by a concrete MEMM version.
Shared Responsibility
Responsibility boundaries are clarified before integration.
This is an orientation model, not a universal RACI. Actual roles depend on deployment, contract, regulatory role, target system and release.
Healthcare application & business context
- product and process context
- organization-specific business logic
- local operating and integration decisions
Agreed product boundary
- versioned interfaces and artifacts
- named runtime and error boundaries
- release-specific technical references
External services & infrastructure
- provider-side infrastructure and operations
- external identity, trust and communication services
- requirements and decisions of external bodies
Possible integration models
Embedded, private service or operated — only after scope confirmation.
| Model | Possible use | Clarify before commitment |
|---|---|---|
| In-process / Embedded | OEM integration with a tight product boundary | target platform, binding, lifecycle, update and support model |
| Private Service | organization-owned platform service | API, identity, network, operations, monitoring and ownership |
| Managed / Operated | project with named runtime responsibility | availability, support, security response and evidence scope in contract |
Go deeper
Technical architecture topics.
Public briefs on integration contracts, specification change and responsibility boundaries without exposing internal implementation artifacts.
TI 2.0TI 2.0 architectureHow software-based TI access, digital identities and Zero Trust relate to the MEMM product boundary without implying TI-Gateway, ZETA or general TI 2.0 conformance.Open knowledge brief →Integration ContractsVersioned API contractsMaking API version, capabilities, data contracts, lifecycle and error semantics explicit so integrations do not depend on silent fallbacks.Open knowledge brief →Versioned ExtensibilitySpecification Change ControlUsing versioned adapters and anti-corruption boundaries so changes in external drafts and profiles do not silently become changes in stable domain logic.Open knowledge brief →
Classification: Matrix, FHIR®, TI, TI-M, TI-Flow, ZETA, ePA and gematik refer to external standards, infrastructures or integration contexts. This site does not claim certification, approval or commissioning by gematik or another authority. Supported profiles, versions and operational boundaries are confirmed in writing before use.