HL7 FT1 Segments Need Encounter Resolution First

HL7 v2 DFT messages with FT1 segments still arrive nightly at many clinic interfaces. Engineers map segments to ledger codes; clinicians wonder why charges appear for visits that were cancelled on the chart. The segment is not wrong — the identity model is.

FT1 translation requires encounter resolution

Treat FT1 as edge payload. Translate to internal ChargeItemCreated only after encounter_id resolves against the monolith aggregate root. Patient national identifiers alone are insufficient — merges and duplicate registrations fork revenue.

ASTM E1394 from analysers should share the same pipeline: validate → publish result event → idempotent billing projection.

FHIR profiles at the perimeter

Expose Invoice for patient bills and Claim for payer traffic per HL7 definitions — do not merge serializers. ChargeItemDefinition resources (Order Catalog IG) model tariff maps with effective dates; internal engines should version maps the same way.

Reference: FHIR Claim for adjudication boundaries.

API shape integrators should demand

  • GET /encounters/{id}/charges without joining finance_shadow_db
  • Idempotent POST for lab validation → charge projection
  • Outbound FHIR read-only; clinical writes through encounter services only
  • Contract fixtures for FT1, ORU, ASTM in CI

Promed HIS implements encounter-native billing clinically — evaluation notes: practice revenue module; platform: practice management software.

Vendor due diligence

Ask whether ASTM ACK loops can create duplicate ChargeItems — demand idempotency keys in code review, not slides.

Ask Competitor A whether middleware owns Patient merge — if yes, clinical safety and revenue integrity both ride a bus you do not control.

Protocols are edges; encounter identity is the product.