MEMMDigital Health Platformby ITL Software GmbH
Home / Technical Knowledge / Normative document matrix
PTV · ATV · Draft

How do gematik PTVs, ATVs and drafts map to MEMM product boundaries?

The website connects product and provider types to fixed document versions and selected AFO, section and interface references. Specification & Trust explains which requirement governs each architecture boundary. The mapping interprets the sources and does not claim complete implementation verification.

Topics:PTVATVDraftApprovalTI-MTI-Flow
ITL Software GmbHTechnical classificationReviewed: 17 Oct 2026
The key relationship

From role to a reviewable statement

  1. PTV / ATV

    Identify product type and provider role separately

    pins
  2. Source + version + requirement

    Check the applicable selection and draft status

    bounds the statement
  3. Named assessment scope

    Statement, responsible role and evidence reference

Reading path through the document matrix. A source mapping is not implementation evidence or approval.

Different documents, different obligations

  • PTV: normative product/manufacturer scope; product type version differs from the document version.
  • ATV: normative provider/operator scope; listing an ATV does not establish ITL as that provider.
  • Draft: prerelease planning reference, subject to change or withdrawal.

Evidence discipline

Public architecture explanations name document version, role, requirement or section, and meaning together. Implementation evidence additionally needs a test procedure, reproducible result and reviewer decision. The website explains selected requirements; its mapping is not a complete test catalogue.

Versioned primary sources

What this page explicitly does not claim: The source review of 17 October 2026 uses supplied primary PDFs, versioned FHIR packages and pinned JSON/OpenAPI schemas. The editorial explanation is not approval, certification or a claim of complete implementation.
Continue reading

Related architecture topics

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.Read technical brief →TraceabilityRelease EvidenceA release-oriented evidence model that keeps source state, artifact identity, configuration, test context and review reference connected without publishing private evidence.Read technical brief →TI-Flow / FHIRTI-Flow architectureArchitecture model for a canonical TI-Flow process and task context kept separate from concrete FHIR® profile generations and external service boundaries.Read technical brief →ePA · FdV · Record servicesePA record accessThe ePA 3.1.3-3 frontend and record-system boundaries, explained through pinned interfaces and FHIR packages, with the Common-version difference recorded.Read technical brief →