Healthcare Guides

It is the architecture behind the 2026 MedTech Breakthrough Award for Best Overall Healthcare Cybersecurity Solution.

Post-n-Track performs the functions healthcare data intermediaries have always performed — accept, translate, validate, route — with one architectural difference: the transaction is not retained after it is delivered. There is no central repository of customer transaction history based on PHI/PII.

This is not a smaller retention window or stronger encryption at rest. It is the absence of the thing those controls protect. Encryption at rest secures a repository that still exists and is still reachable by valid credentials. Gen 3 does not create the repository.

Organizations that want their intermediary to also be their data warehouse are asking it to also be their breach surface. Post-n-Track declines that combination on purpose.

Post-n-Track inverts that. Deterministic engines do the work that touches PHI. Models never interact with the underlying protected data. The determinism is what makes the transaction correct; the model is what makes it explainable.

This is the direct consequence of the zero-residency commitment rather than a bolt-on: an architecture that never centralized PHI does not have to un-centralize it to adopt AI safely.

Concentration is the vulnerability

Healthcare's worst data events share a shape. An intermediary accumulates PHI from many organizations because its architecture requires storage to function. That repository becomes the highest-value target in the sector, because compromising one vendor yields what compromising hundreds of providers would.

The controls layered on top — encryption, access management, monitoring — are necessary and they are not sufficient, because they all protect something that continues to exist. An attacker with valid credentials is authorized. Encryption at rest is transparent to them.

The operational half nobody costs

A compromised intermediary is not only a privacy event. The same system that held the data was moving it. When it goes down, claims stop, remittances stop, eligibility stops, and cash flow stops across every organization connected to it — simultaneously.

This is why intermediary concentration is a business continuity question and not only a security one, and why it is increasingly a board question rather than a CISO question.

Data Guardians, not Data Owners

An architecture that never retains the data is structural. It does not depend on anyone's continued good intentions, and it does not depend on the next acquirer's view of what the data is worth. That is the difference between a promise and a property.

Three standards, three worldviews

X12 models administrative transactions as hierarchical envelopes with positional segments, designed for batch exchange between trading partners. HL7 v2 models clinical events as pipe-delimited messages with pervasive local customization. FHIR R4 models resources with REST semantics and explicit references.

These are not three encodings of one model. They are three models. An X12 837 'subscriber' and a FHIR Coverage/Patient relationship are not the same abstraction, and the mapping between them requires decisions, not just transformation rules.

Where mappings go wrong

The failures cluster: identifiers that are unique in one system and ambiguous in another; dates with different precision and timezone conventions; codes from different code systems asserting the same clinical fact; and HL7 v2's Z-segments, which are by definition non-standard and carry meaning nobody outside the sending organization knows.

Mapping is therefore an ongoing relationship with each trading partner rather than a one-time build. Vendors who quote it as a one-time build are quoting the first version.

Engineering in transit

PNT Data performs translation and normalization as the transaction moves, not as a load into a staging repository. The engineering happens in flight and nothing persists afterward.

This constrains the design in useful ways: transformation must be deterministic and stateless with respect to payload, which is also what makes it auditable.

The cost curve

Every gate a bad transaction passes multiplies the cost of the error. A structural problem caught before transmission costs a keystroke. The same problem discovered as a denial costs a rework cycle, possibly an appeal, and the risk that timely filing expires while it is being worked.

This is why validation placement matters more than validation sophistication. A modest ruleset applied at ingestion outperforms an excellent one applied after the fact.

Two kinds of edit

Implementation guide conformance is deterministic: does the transaction obey 005010X222A1, or 005010X279A1, or the relevant guide. Segment presence, loop placement, identifier format, date validity. These are knowable in advance and there is no excuse for transmitting a transaction that fails them.

Payer-specific edits are the harder class, because payers layer local requirements on top of the guide and those requirements change without notice. Keeping them current is ongoing operational work rather than a build.

Validation without retention

Validating a transaction requires reading it. It does not require keeping it. PNT Data validates at the boundary and returns the conformance result to the submitter; the transaction itself is not retained.

Provenance and payload are different things

The question 'what happened to my claim' is answered by state, not content: it was received at this time, validated with this result, routed to this payer, acknowledged at 999, accepted at 277CA, adjudicated. None of that requires the claim body.

Conflating the two is why intermediaries argue they must retain PHI to give you visibility. They must retain metadata. The payload retention is a separate decision made for separate reasons.

Compliance as a byproduct

An append-only record of what moved where and when is what an auditor asks for, what a trading partner attestation depends on, and what a dispute is resolved with. Generated automatically by normal operation, it costs nothing extra and cannot be reconstructed after the fact if it wasn't.

Increasingly, regulation asks for exactly this. Attestation and provenance requirements mandate evidence that a well-instrumented routing layer already produces.

What visibility looks like without a repository

Status, lineage, and outcome per transaction; the acknowledgment chain in full; validation results and their reasons; and a durable record of routing decisions. What is absent is the ability to re-read the claim body months later — which is a capability the submitter's own system already has, because it is the system of record.

Why 'AI-ready' usually means 'centralized'

The default architecture for healthcare AI is a data lake: extract from source systems, land it, normalize it, then point models at it. Every step of that is a PHI accumulation step, and the resulting asset carries the same concentration risk as any other repository — with a newer and less mature access model on top.

The instinct is understandable and the consequence is not usually priced. A healthcare AI data lake is a breach surface that did not exist last year.

Determinism first

Most of what healthcare data operations need from automation is deterministic, not probabilistic. Whether a claim conforms to 005010X222A1 is a rule. Whether an AAA 72 is a data error or a coverage finding is a rule. Whether a TRN02 matches a CCD+ trace is a comparison. None of these should be a model's judgment call, because the correct answer is knowable and a model can only approximate it.

What models are good at is the part that is genuinely interpretive: explanation, summarization, triage of ambiguity, and surfacing patterns for a human to ratify. Those tasks do not require the raw PHI — they require the structured result of the deterministic step.

The architecture follows from the constraint

An organization that already never centralized PHI does not have to un-centralize it to adopt AI safely. The zero-residency commitment that makes Post-n-Track a security architecture is the same commitment that makes AI composable on top of it.

What the 271 actually returns

A successful 271 carries coverage status in the EB segment: active coverage, plan detail, and — depending on the payer's implementation — service-type-level benefits, copay, coinsurance, deductible accumulators, and plan date ranges. Payers vary enormously in how much of this they populate. A 271 from one payer may return thirty service types with financial detail; another returns active/inactive and little else. This variance, not the standard, is what makes eligibility hard.

An unsuccessful 271 carries an AAA segment instead. The AAA segment appears at different loop levels depending on what failed — 2100A for the information source, 2100B for the information receiver, 2100C for the subscriber, 2100D for the dependent. The loop level tells you who the payer thinks is at fault, and it is the first thing to read.

AAA 72 and AAA 41 — the two that matter

AAA 72 means invalid or missing subscriber identification. It is the single most common eligibility rejection. It does not mean the member has no coverage. It means the identifier submitted did not resolve at that payer. The causes are mundane and fixable: a member ID transcribed with a prefix the payer does not expect, a name mismatch against the payer's file, a date of birth off by a digit, a dependent submitted in the subscriber loop, or an identifier that was valid before the member's plan year rolled.

AAA 41 means authorization or access restrictions — the inquiry was structurally valid but the submitter is not permitted to ask it. This is a trading-partner problem, not a patient problem. It typically indicates the submitter is not enrolled with that payer for eligibility, or is asking outside a permitted relationship.

The workflow consequence is direct. An organization that routes AAA 72 into the same bucket as inactive coverage will convert a correctable data-entry error into a self-pay determination or a denied claim. The correction path for AAA 72 is to re-inquire with corrected demographics or to run coverage discovery. The correction path for inactive coverage is entirely different. Collapsing them is a measurable and avoidable source of denial volume.

Why front-end validation matters more than retry logic

Most eligibility failures are generated before the 270 is ever transmitted. The identifier is wrong at registration, or the payer selection is wrong, or the subscriber/dependent relationship is coded incorrectly. A system that transmits whatever it is given and retries on failure is spending payer-side transactions to discover data quality problems it could have caught locally.

Shift-left validation means enforcing the 005010X279A1 conformance rules — segment presence, identifier format, date validity, loop placement of subscriber versus dependent — at ingestion, before transmission. The transaction that never had to be sent is the cheapest one.

PNT Data validates 270 inquiries against the implementation guide at the boundary and returns conformance failures to the submitter immediately rather than transmitting a transaction that will predictably return AAA 72.

Eligibility verification versus coverage discovery

These are different questions and they are frequently conflated. Eligibility verification asks: is the coverage we have on file for this patient active, and what does it cover? Coverage discovery asks: does this patient have coverage we don't know about?

The second question matters after a self-pay registration, an emergency encounter with incomplete demographics, or an AAA 72 that could not be resolved by correction. It is also the question underneath a meaningful share of write-offs that did not need to happen.

The transactions are related but the workflows are not interchangeable. A 270 requires you to know which payer to ask.

Medicare eligibility and HETS

Medicare eligibility runs through the HIPAA Eligibility Transaction System rather than a commercial payer endpoint, and it has its own access regime. HETS requires an approved trading-partner relationship, and a trading-partner attestation requirement took effect May 11, 2026. Organizations accessing HETS through an intermediary should confirm their attestation posture directly rather than assume it is handled.

MBI lookup is a related but separate capability: retrieving a beneficiary's current Medicare Beneficiary Identifier when it is unknown or has changed.

Frequently asked questions

AAA 72 means the subscriber identifier submitted on the 270 was invalid or missing — the payer could not resolve the member. It does not mean the patient has no coverage. Common causes are a transcribed member ID, a name or date-of-birth mismatch against the payer's file, a dependent submitted in the subscriber loop, or an identifier that changed at plan year rollover. The correction path is to re-inquire with corrected demographics or to run coverage discovery — not to treat the patient as self-pay.

AAA 41 indicates authorization or access restrictions: the inquiry was structurally valid but the submitter is not permitted to ask it of that payer. This is almost always a trading-partner enrollment issue rather than anything to do with the patient, and it is resolved with the payer, not by re-inquiring.

Eligibility verification confirms whether coverage already on file is active and what it covers, using a 270 inquiry directed at a known payer. Coverage discovery identifies coverage the provider does not know about — relevant after self-pay registration, incomplete demographics, or an unresolvable AAA 72. Verification requires knowing which payer to ask; discovery does not.

005010X279A1 is the mandated implementation guide version for the eligibility inquiry and response pair. Conformance includes correct AAA error handling and correct loop placement of subscriber versus dependent information.

Because AAA rejections are frequently misread as coverage determinations. An AAA 72 routed into the same workflow bucket as inactive coverage converts a correctable data error into a self-pay determination or a claim submitted to the wrong payer. Separating inquiry failures from coverage findings is the single highest-yield change most organizations can make to eligibility workflow.

Medicare eligibility runs through HETS rather than a commercial endpoint and requires an approved trading-partner relationship. A HETS trading-partner attestation requirement took effect May 11, 2026. Organizations accessing HETS through an intermediary should confirm their own attestation posture rather than assume it is covered.

Two streams, one match

A payer sends a healthcare payment as an ACH transfer and the corresponding explanation as an X12 835. These travel different paths: the money through the banking system, the 835 through the EDI path. They arrive at different times, sometimes days apart, and nothing about the banking transaction inherently identifies which remittance it belongs to.

The link is the trace number. CAQH CORE operating rules require the payer to carry a reassociation trace number in the CCD+ addenda record of the ACH payment, and the same value in the TRN02 element of the 835. Match the two and the payment posts automatically. Fail to match and someone opens a spreadsheet.

This is not an exotic edge case. It is the routine mechanism by which healthcare cash gets posted, and it fails often enough that 'unposted cash' is a standing line item in most revenue cycle operations.

Why reassociation fails

The failure modes are unglamorous and they compound.

The bank strips the addenda. Not every bank delivers the CCD+ addenda record to the depositor by default. Some deliver it only on request, in a separate report, or in a format the practice management system cannot ingest. The trace number exists; it just never reaches the person who needs it.

Aggregated payments. One EFT covering multiple 835s, or one 835 spanning multiple payments, breaks the one-to-one assumption most posting logic makes.

Trace number formatting variance. Leading zeros, prefixes, and truncation between the banking system and the EDI path can leave two values that represent the same trace but do not compare as equal.

Timing. The 835 arrives before the money, or well after. Posting logic that assumes same-day arrival creates a backlog it then treats as an exception queue.

Payer variance. Some payers' TRN02 practice does not match the operating rule cleanly, and the receiver absorbs the difference.

• Bank does not deliver the CCD+ addenda to the depositor
• One EFT to many 835s, or one 835 to many payments
• Trace value formatting drift between banking and EDI paths
• Arrival timing gaps between money and remittance
• Payer-specific TRN02 practice variance

What the 835 actually tells you

Beyond the payment amount, the 835 carries the reasoning. CARC (Claim Adjustment Reason Codes) state why the paid amount differs from the billed amount. RARC (Remittance Advice Remark Codes) supply supplemental explanation. Together they are the raw material of denial management — and of the appeal decision.

The 835 also carries MSP information where Medicare is secondary, and the adjustment detail a secondary claim needs. A secondary 837 that does not accurately carry forward the primary's payment and adjustment data from the 835 will be denied, and that denial will look like a coding problem when it is actually a data carry-forward problem.

This is why 835 handling and denial management are the same problem viewed from two ends. The remittance is where the payer told you exactly why, in a structured format, and most organizations reduce it to a dollar figure and a posting.

Enrollment is a separate obstacle

EFT and ERA enrollment are governed by the CAQH CORE EFT & ERA Enrollment Data Rule (vPR.2.0), which standardizes the data elements a payer may require. In practice, enrollment remains payer-by-payer, form-by-form, and is a common reason an organization has electronic remittance from some payers and paper from others years after going electronic.

This is administrative rather than technical work, and it is the reason ERA adoption rates lag ERA capability. Any migration plan that treats EFT/ERA enrollment as an afterthought will discover it on the critical path.

Reassociation without retention

Reassociation requires comparing two identifiers. It does not require retaining the remittance payload. PNT Data performs reassociation as a matching function on trace values and returns the match to the receiving organization, whose own system remains the system of record for the remittance itself.

Frequently asked questions

Reassociation is matching an ACH healthcare payment (EFT) to its corresponding Electronic Remittance Advice (X12 835). The match is made by comparing the reassociation trace number in the ACH CCD+ addenda record to the TRN02 element of the 835. Successful reassociation allows automated payment posting; failure sends the payment to manual reconciliation.

TRN02 is the reassociation trace number data element in the X12 835. Under CAQH CORE operating rules, its value must match the trace number carried in the CCD+ addenda record of the corresponding EFT, which is what makes automated payment-to-remittance matching possible.

The most common causes are: the bank does not deliver the CCD+ addenda record to the depositor; one EFT covers multiple 835s or vice versa, breaking one-to-one matching; trace number formatting drifts between the banking and EDI paths (leading zeros, prefixes, truncation); the payment and remittance arrive days apart; or payer-specific TRN02 practice varies from the operating rule.

CCD+ is the ACH format used for healthcare payments. Its addenda record carries the reassociation trace number that links the payment to its 835. If a bank does not pass the addenda through to the depositor, the trace number never reaches the organization that needs it, and reassociation cannot be automated regardless of what the payer did correctly.

CARC codes state why a payment differs from the billed amount; RARC codes add supplemental explanation. Both are carried in the 835. They are the structured record of the payer's reasoning and the basis for any appeal — which is why treating the 835 as a payment amount rather than an explanation discards the most useful denial-management data available.

Frequently because the primary's payment and adjustment data from the 835 was not carried forward accurately into the secondary 837. The denial presents as a coding problem but originates as a data carry-forward problem between the remittance and the secondary claim.

The loop structure, briefly, because it explains the failures

An 837 is hierarchical. Loop 1000A identifies the submitter, 1000B the receiver. Loop 2000A carries the billing provider, 2000B the subscriber, 2000C the patient when the patient is not the subscriber. Loop 2300 is the claim itself; 2400 carries the service lines.

Almost every structural rejection traces to a hierarchy error rather than a content error. The most common is the subscriber/patient distinction: when the patient is the subscriber, patient information belongs in loop 2000B and loop 2000C must not be present. When the patient is a dependent, 2000C is required. Systems that populate both, or populate 2000C unconditionally, generate rejections that look like data problems and are actually structural ones.

Understanding this matters because the rejection message a payer returns rarely says 'your hierarchy is wrong.' It says something narrower and less useful, and the correction is applied at the symptom.

837P and 837I are not variants of one form

They share a base standard, and the resemblance ends there. The 837P is built around a rendering provider and CPT/HCPCS procedure coding at the service line. The 837I is built around a facility, a type-of-bill code, revenue codes, occurrence and value codes, condition codes, and a statement-covers period.

The practical consequence is that institutional claims fail for reasons professional claims cannot. A missing or wrong type-of-bill, a revenue code that does not pair with the HCPCS submitted, an occurrence code date outside the statement period — none of these have a professional analogue. Organizations that treat 837I as '837P with different fields' find this out through denials.

837D adds a third structure again, with tooth numbers, surfaces, and oral cavity designations.

Submission is not acceptance: the acknowledgment chain

A claim passes through several gates and each one reports differently. The TA1 reports interchange-level problems — the envelope itself was malformed. The 999 (formerly 997) reports syntax: did the transaction conform to the X12 implementation guide. The 277CA — Claim Acknowledgment — reports the payer's front-end business edits: was the claim accepted for adjudication.

The 277CA is the one organizations most often under-use. A claim can pass the 999 cleanly and be rejected at 277CA for a payer-specific business reason. That claim is not in the payer's adjudication queue and nobody is working it, but the submitter's system may show it as 'submitted.' Claims that sit in this gap age silently until someone notices the AR.

Only after 277CA acceptance does adjudication occur, and only then does an 835 follow. The distinction between 'we sent it,' 'it parsed,' 'they accepted it,' and 'they adjudicated it' is four different states, and collapsing them is a reliable way to lose money slowly.

• TA1 — interchange envelope acknowledgment
• 999 — syntax and implementation guide conformance
• 277CA — payer front-end business edit acceptance or rejection
• 835 — adjudication result and payment explanation

Front-end validation is cheaper than every alternative

The cost of a claim error scales with how late it is found. Caught at the point of submission, it is a correction. Caught at 999, it is a resubmission cycle. Caught at 277CA, it is a resubmission cycle plus aged AR. Caught at adjudication as a denial, it is a rework cycle, a possible appeal, and a timely-filing risk. Caught after timely filing has expired, it is a write-off.

Shift-left validation means enforcing implementation guide conformance and known payer edits at ingestion, before transmission, and returning the failure to the submitter while the claim is still in front of the person who can fix it.

PNT Data validates 837 transactions against the implementation guide and payer-specific edits at the boundary. Specific edit coverage by payer is maintained per payer. SOURCE TBD — link to payer directory when published. Clean claim rate improvement is measurable per organization and should not be quoted as a general figure. SOURCE TBD.

Routing without retention

Validation and routing require reading the claim. They do not require keeping it. PNT Data authenticates, validates, translates where required, and routes the 837 to the payer, then retains no PHI at rest. The submitter's system remains the system of record — which it is in any case, since that is where a correction and resubmission originate.