Mapping Procedures to Insurance Packages in an HMIS: NHCX Requirements

Of everything NHCX asks an HMIS to do, this is the change teams see last and pay for most: the procedure a clinician performs and the package a payer pays for are two different objects, and something in your product has to own the correspondence between them.

The mismatch

A surgeon records an angioplasty with a clinical code. The payer's catalogue does not contain angioplasties — it contains benefit packages, grouped into categories, each with a package code, a value, limits, and its own list of required documents. Choosing which package a given episode is claimed under is a decision, made by a person, using rules.

It is a decision because the mapping is rarely one-to-one. One clinical procedure may be claimable under more than one package depending on approach, implant, or length of stay. One package may cover several procedures performed together. And the package that pays best is not always the package that is defensible — which is exactly why a person makes the call and why the reasoning needs to be recorded.

Why no existing module can hold it

Ask where this belongs in a typical HMIS and you get three answers, none of which works:

• Billing knows the hospital's own tariff. It has no concept of a payer's product catalogue, and its charge master is organised around what the hospital bills, not what an insurer funds.
• The EMR knows what was clinically performed. It has no reason to know what an insurer calls it, and loading payer logic into clinical screens is the wrong place for it.
• A lookup table maintained by one person in a spreadsheet is what most sites end up with. It works until a payer revises a catalogue, and then it silently produces wrong claims.

That is why this reads as a new module — the insurance desk — rather than a change to something existing. It needs its own screens, an owner, and a maintenance process.

What the module actually has to do

1. Hold the payer catalogue. Categories, packages, values, limits and document requirements, fetched from the plan API and cached — a couple of weeks is the intended lifetime, not per-claim.
2. Render document requirements dynamically. Required documents come back attached to the benefit. A static checklist per insurer, maintained by hand, goes stale silently. The checklist should be generated from the response.
3. Support search and selection. A claims operator needs to find the right package quickly, having read the clinical notes.
4. Record the mapping decision. Which package, chosen by whom, against which procedure. This is the audit trail when a payer queries the claim.
5. Trigger the benefits eligibility check. Package selection is what makes the second eligibility call possible — see the two-call eligibility sequence.
6. Learn. The same procedure maps to the same package most of the time. Suggesting the prior choice turns a decision into a confirmation, which is where the operational time saving comes from.

The data model consequences

Two schema changes follow from this and are worth getting right at the start.

The mapping is an entity, not a column. It has a procedure, a package, a chooser, a timestamp and often a justification. Storing the package code on the claim row loses the reasoning, which is the thing you need when the claim is queried.

Payer catalogues are versioned. A package that existed when you cached it may be revised. A claim submitted last month was mapped against the catalogue as it stood then. If you overwrite the cache in place, you lose the ability to explain a historical claim.

Where it sits in the flow

Between the clinical work and the pre-authorization. The clinician finishes; the claims operator opens the episode, reads the notes, selects category then package, and the system runs the benefits check against that selection before anything is submitted. That ordering is not arbitrary — the eligibility answer depends on which package you are asking about.

Getting this module right is also what makes automation possible later. A recorded mapping history is training data: the same procedures, the same packages, the same payers, thousands of times. Products that never captured the decision have nothing to learn from.

If you are scoping NHCX for a hospital information system, our healthcare interoperability team has built the full flow end to end against the sandbox. For the architectural half — the asynchronous layer, the callback path, the claim state model — see our healthcare software product engineering practice. Talk to our team to walk through your product.