Versioned Profiles

TI-Flow/FHIR® versioning: Flowtypes, profiles and reproducible delivery

A TI-Flow integration needs external profile change to be explicit and versioned. The planned MEMM contract binds a process to an explicit Flowtype/profile generation, renders FHIR® deterministically outside the local workflow transaction and retains a reproducible delivery boundary for replay.

Topics:TI-FlowFHIR ProfilesFlowtypesVersion PinningReplay
Version-bound development architecture

This page documents the intended versioned integration contract. Only the BPMN/VBucket foundation was confirmed as fully implemented by the product owner, so TI-Flow is deliberately not presented here as complete.

From canonical intent to external representation

  • A process references an explicit Flowtype/profile generation instead of a global current version.
  • Unsupported features or unknown profile generations fail closed.
  • FHIR® mapping is deterministic and does not belong inside the shard-local ACID transition.
  • A durable delivery boundary keeps intent, mapper/profile provenance and the payload generation needed for exact replay together.

Parallel versions instead of a big-bang profile switch

Running processes can remain on their approved generation while new processes use another version. This reduces the need to treat regulatory or external profile change as one global instantaneous switch.

What this page explicitly does not claim: This is not a claim for a currently complete Flowtype or FHIR® profile matrix. Supported versions, resources and operations must be stated for the specific release and project scope.