How does hospital HIS direct connection to the Leqi interface connect charging and medical insurance data? Kailing Technology unifies orders and writes back invoicing results

In front of the inpatient settlement window, the patient had just completed discharge and only asked one question: "Where is the invoice for this settlement of mine?" The charging system showed settlement completed, while the medical insurance return separated results such as pooled fund, personal account, and personal cash; the patient side showed pending invoicing, while the window computer showed submitted. The two systems each had a status, and staff could not use one number to explain where this invoice had gone.

Kailing Technology's hospital HIS integration solution establishes a unified order from this settlement: charging details and final medical insurance results are first merged into the same order primary key, then the invoiceable scope, item mapping, invoicing request, result write-back, and patient delivery are completed. The window, HIS, patient side, and invoicing link all update around one order, and when the patient queries again, any entry point can locate the same business.

▍A unified order first gives charging, medical insurance, and invoicing a common primary key

After the counter confirms discharge settlement, HIS uses this settlement business number to generate an invoicing order, which stores the source system, visit type, invoicing entity, amount, and current status. Both the medical insurance settlement flow and charging details are linked to this primary key, and subsequent requests no longer create new business numbers separately.

Whether a patient queries from the official account, collects a ticket from a self-service machine, or returns to the window for consultation, the entry point first uses settlement information to find the unified order, then reads the same status. Even if the patient switches entry points, the invoicing business will not be regenerated; staff can directly answer whether the order is in verification, issuance, write-back, or delivery.

Outpatient payment and inpatient settlement use their own confirmation nodes, but after entering the invoicing chain they use a consistent order structure. Multiple payments, prepayments, and settlement supplements retain detailed relationships, the main order summarizes the settlement result for this time, and finance can drill down from the total amount to the source records.

▍Charge details and medical insurance settlement results are merged at the order level

This hospitalization business first goes through pre-settlement, and settlement is completed only after the medical insurance system finally returns. The system writes the results required for invoicing, such as total expenses, pooled payment, personal account, personal cash, reductions, and refunds, into the order version, while retaining the medical insurance settlement transaction corresponding to this result.

Item details in the charging system are aggregated by order number, and the medical insurance return is used to verify the settlement composition. The interface processing record captures the source, time, and version of each batch of data; after the final settlement arrives, the order changes from pending settlement to pending verification, and earlier pre-settlement data no longer triggers invoicing tasks.

If the charging amount cannot be reconciled with the final medical insurance result, the order enters a discrepancy status, the counter can see "waiting for settlement review," and the medical insurance office and finance receive the corresponding to-dos. After the handler corrects the source data and re-merges it, the system retains the before and after versions, avoiding direct overwriting that makes accounts difficult to trace.

▍The issuable scope and charge item mapping are completed before the request

At project launch, the hospital configures "business type - invoice type - target capability" as routing: outpatient, inpatient, and other charging businesses are respectively matched to medical charging electronic receipts or fully digitalized e-invoices, and point to the corresponding receipt capability or Leqi invoicing link. After this order enters pending verification, the system reads the routing, then compares the settlement total, invoiced amount, refunded amount, and this application.

Item names in the charging system may be as detailed as examinations, treatments, and materials, while the invoicing side uses confirmed item codes. After a mapping hit, invoicing details are formed; when a newly added item has no corresponding relationship, the order remains in the item pending maintenance status, and finance continues only after completing the mapping and review.

What the counter sees is an explainable processing reason, not a vague interface failure. Amount discrepancies enter settlement review, missing items enter configuration maintenance, and missing buyer information returns to patient confirmation; each type of issue has a fixed role and recovery entry point.

▍Invoicing requests advance along the order status; on timeout, check the original result first

After verification passes, the system uses the order primary key to generate a unique invoicing request number. Medical charging electronic receipt orders enter the corresponding receipt capability; orders configured as fully digitalized e-invoices and already connected to Leqi enter the Leqi invoicing process. The Kailing implementation team is responsible for orchestration and interface implementation, the hospital's existing HIS retains the charging facts, and each target capability returns the processing result.

After the request is sent, the order changes from pending issuance to issuing. If the interface briefly times out, the system first queries the original processing result using the request number; if it finds success, it proceeds to write-back, and if it finds failure, it records the reason and enters retry or manual review, preventing counter staff from repeatedly clicking and causing duplicate issuance.

Every request, response, query, and status change is written into the order trail. Finance can see which call the current result came from, and the IT department can locate interface logs by request number, so business staff and technical staff discuss the same order.

▍The issuance result is written back simultaneously to HIS, the window, and the patient side

After successful issuance, the invoice number, issuance time, file, or delivery information is first linked to the unified order, then written back to HIS. HIS updates the invoice status of that settlement, and when the charging window reopens the patient record, the issued result seen is consistent with the finance backend.

On the patient side, the order is read to determine whether it can be queried or downloaded. The hospital may also choose delivery via official account, mini program, SMS link, email, self-service kiosk, or counter based on its existing capabilities. If the patient has not received the message, the counter first checks the order: if the invoice has been issued but delivery failed, the delivery task is resent rather than reissuing the invoice.

If issuance succeeds but the HIS write-back temporarily fails, the system marks the order as pending write-back and retains the successful receipt, and continues pushing after the interface recovers. The write-back count, latest result, and error reason are all visible; technical staff handle the write-back task, and the invoicing side will not generate the receipt again.

▍A partial refund finds the original invoice along the original order and completes red-offset write-back

After a patient is discharged, a partial refund occurs. HIS first confirms the refund items and amount, then sends the reverse event to the original order. The system locates the original settlement and original invoice by the order primary key, compares the refunded amount with the processable range, and generates the corresponding red-letter processing task.

After the red-letter result is returned, the original invoice, red invoice, and remaining valid amount remain on the same order chain; HIS and the patient side update the status synchronously. When the counter queries again, it can explain which part has been refunded, how far the red-letter processing has progressed, and how subsequent receipts will be delivered.

Uninvoiced refunds, full refunds after invoicing, partial refunds, and reissuance after red-letter reversal each use clear statuses. When medical insurance retrospective adjustments bring a new settlement version, the system retains the original result and reverse records, so finance can restore business changes over time.

▍Reconciliation exceptions return to the specific order and responsible position

Daily reconciliation compares HIS settlement status, final medical insurance result, invoicing result, HIS write-back, and patient delivery by order. If there is a discrepancy in quantity or amount on any side, the list directly provides the order primary key, discrepancy type, and last successful node, so finance does not need to export multiple tables and guess manually.

Settlement discrepancies go to the charging or medical insurance role, item mapping goes to the finance configuration staff, issuance exceptions go to the receipt handler, and write-back exceptions go to the IT staff. The handler enters the original order from the exception item, reruns the corresponding step after repair, and the other successfully completed steps remain in their original state.

Kailing Technology turns exceptions into assignable tasks through unified orders and status write-back. Hospitals can view daily quantities of pending verification, issuing, pending write-back, pending delivery, and red reversal, which can both reveal backlogs and trace specific requests and handlers.

▍Privacy minimum fields and the status chain must be accepted together

The interface only transmits the identity, contact information, charging entity, items, amount, and settlement status required for invoicing. Diagnoses, medical records, and medical insurance details unrelated to invoicing remain in the hospital business system; necessary fields use encrypted transmission, tiered authorization, and controlled display.

Logs record the order number, request time, processing status, and error type, and sensitive fields are controlled by role in queries and exports. Counter staff view patient delivery, finance handles issuance and red-letter reversal, and IT staff troubleshoot interfaces; each role can complete its tasks while seeing only what is needed for the work.

During acceptance, five types of samples are tested continuously: normal inpatient settlement, unmapped project, write-back timeout, patient switching entry point, and partial refund. Each operation returns to the same order, and the status can advance forward and be traced backward, after which the hospital uses the passed samples as the regression baseline after go-live.

▍FAQ

Q: After medical insurance pre-settlement is completed, what status is the order in?

A: The order retains the pre-settlement record and waits for final settlement. After the final result arrives and merging is completed, it then enters validation of project, amount, and buyer fields.

Q: If a patient switches from the window to the official account for inquiry, will a new order be generated?

A: No. Different entry points locate the same order primary key through settlement information and read the unified invoicing and delivery status.

Q: The invoice has been issued but HIS does not show success; how should this be handled?

A: The system retains the successful issuance result and generates a pending write-back task; after the interface recovers, it continues writing back to the original order without re-initiating invoicing.

Q: How is a partial refund linked to the original invoice?

A: HIS sends the confirmed refund event to the original order; the system locates the original settlement and original invoice along the order primary key, processes the red-letter result, and then writes back to HIS and the patient side.

Use a unified order to connect charging, medical insurance settlement, and invoicing results. Learn about Kailing Technology's hospital HIS integration solution: https://www.kailingteck.com/leqi-zhilian/ .

As a national high-tech enterprise, Kailing Technology focuses on the digital and intelligent transformation of enterprise business-finance-tax and operations management, providing software products, system integration, implementation and delivery, and operational services for various government agencies, institutions, group enterprises, and SMEs.

The company has now formed ten core product lines, including: AI digital employee system, enterprise expense control management system, customer relationship management system, reverse invoicing management system, invoice issuance for individuals management system, electronic archives management system, tax fully digitalized e-invoice Leqi system, tax invoice management system, group tax filing system, and AI OCR recognition system. It is committed to connecting enterprise business, finance, tax, funds, and archive data to help customers improve operational efficiency, business-finance-tax compliance capabilities, and digital management levels.

If you have any business-finance-tax digital transformation needs, welcome to contact us. Beijing Kailing Technology will serve you wholeheartedly.

Keywords: Hospital HIS direct connection to Leqi, medical insurance data invoicing, hospital charging invoicing, invoicing result write-back, hospital fully digitalized e-invoice