What functions are needed for a hospital HIS direct connection to the Leqi interface? Kailing Technology covers order verification, issuance, red-letter reversal, and query

At 9:30 a.m., a patient in front of the outpatient window had just completed payment, but the invoice was still not visible on the mobile end. The window staff opened the HIS, and the order status showed "submitted"; finance opened the invoicing platform and saw "processing." The patient asked where the invoice was. The two roles sent screenshots to the group chat, and no one knew whether the request had succeeded or whether it could be retried.

Only by tracing this outpatient order forward does the project team discover that direct connection between the hospital HIS and the Leqi interface is far more than one invoicing application: after charging is triggered, the entity, item, and amount must be validated, an idempotent request generated, queries and callbacks received, and files delivered; when a refund occurs, red-letter reversal must also be initiated from the original invoice, and each status must be written back to HIS. Kailing Technology undertakes interface orchestration and implementation in the project, connecting these actions into a queryable, recoverable order chain.

▍Charge completed: HIS generates a unique invoicing order

The project team first returns to HIS to view this outpatient charge. The order includes the hospital invoicing entity, patient or purchaser, charging item, actual received amount, payment method, and settlement status; only after charging confirmation is completed does HIS issue the invoicing trigger. Businesses that are registered but not charged, pre-settled, being paid, or already canceled remain in their original status and do not enter the invoicing queue.

The window, official account, and self-service machine may all submit requests, so the hospital first locks a business primary key common across entry points. When a patient clicks repeatedly on mobile, the system recognizes it as the same order and returns the existing progress; when the window supplements information, it updates the original task and records the version. In this way, "multiple entry points" do not create multiple pending issuance tasks.

Based on the hospital's existing architecture, Kailing Technology receives HIS orders via API, files, or intermediate tables, and writes the source system, trigger time, and original status into the interface ledger. Implementation acceptance first checks whether one charge can stably generate one task, then continues testing subsequent actions.

Layered architecture of HIS, invoicing middleware, and Leqi capability interface

▍Before application: entity, project, amount, and invoice type are verified

After an order enters the invoicing middleware layer, the system first reads the item configuration by business type, such as outpatient charging and inpatient settlement, and routes the request to the target capability corresponding to medical charging electronic receipts or fully digitalized e-invoices; it then verifies the invoicing entity, patient or purchaser information, and maps HIS charging items to invoicing items. Missing information falls directly to the specific field.

Amount validation simultaneously reads actual received, refunded, invoiced, and currently invoicable amounts. The project team reduces the original order amount, then submits invoicing again, and the system should indicate "the requested amount exceeds the currently invoicable amount"; when a new charging item is added to the order but no mapping is configured, the page should indicate the specific item, rather than returning only a string of failure codes.

Window staff can therefore answer patients: whether the order is pending information supplementation, pending item mapping, or has an amount mismatch. Finance sees the same exception on the workbench and assigns it for handling. After the issue is corrected, it continues from the original order, and all fields and operation records that have already passed are retained.

Verification of entity, items, and amounts before hospital invoicing

▍Applying: idempotency control returns repeated clicks to the same request

After validation passes, the Kailing interface orchestration layer initiates an application carrying necessary data such as the business primary key, invoicing entity, buyer, item, amount, and invoice type, and generates a unique request number. The interface ledger stores the correspondence between request numbers and order numbers, and window submissions, patient mobile clicks, and backend supplementary uploads all first query this set of relationships.

The project team had the patient click twice consecutively, and also simulated a network interruption after submission. The normal result is that the system returns the same request progress, and the page enters "accepted, pending result," rather than immediately creating a second application. The operator first queries the original task by order number or request number, and after determining the status decides whether to wait, supplement information, or resume.

The visible value of idempotent design is that the window dares to query when encountering a stuck state, yet will not issue duplicate invoices because of urging. Each submission, query, and recovery carries time and source, and technical staff can also locate interface logs along the request number.

▍Processing: inquiry and callback jointly complete the final result

After the invoicing platform completes processing, it returns status, invoice number, invoicing time, and file information through an asynchronous callback; when the callback has not yet arrived, the hospital side can actively query. The Kailing interface layer verifies the callback source, identifies duplicate notifications, and updates the valid result to the original order. Both paths point to the same final status.

Returning to the outpatient order from the opening, the project team queried by request number and found that the platform had already issued the invoice, but the callback was not received by HIS during a network fluctuation. The interface layer retrieved the result again and wrote it back again, and the window status updated from submitted to issued, making the finance platform and HIS consistent again.

If the query still shows processing, the page retains the current acceptance time and the next query action; if it returns failure, it shows a handleable reason. Patients, the window, and finance see the true progress of the same order at different stages, and phone calls and work groups no longer bear the burden of status synchronization.

▍Issued: invoice files are delivered along the same order

After invoice issuance is complete, the system obtains the corresponding file or delivery information and writes the accessible status back to HIS. Patients can obtain it from the hospital's existing official account, mini-program, self-service machine, or window, and the specific entry points all read the same order result. After one entry point delivers successfully, the other entry points can also query the same invoice number.

File delivery and issuance status are recorded separately: when an invoice has been generated but the file has not yet been obtained, the system shows "issued pending delivery" and schedules a retrieval task. This way, a file failure is not misjudged as an invoicing failure, and patients are not shown a blank success page.

▍Refund occurs: enter red-letter reversal from the original invoice and write back the status

Two days later, the patient handled a partial refund due to project cancellation. The HIS first completed refund confirmation. The interface layer found the original invoice based on the original order, read the refunded amount, the red-letter reversal scope, and the current status, and then initiated red-letter processing. The original blue invoice, refund record, and red invoice are linked to each other, and the old records remain queryable.

In partial refund scenarios, the remaining invoicable range is updated according to the original charging item and amount; full refunds, refunds without invoicing, and re-issuance after red-letter reversal each enter their corresponding paths. The project team simulates a red-letter reversal timeout, and the system first queries the original request, then resumes processing, preventing duplicate tasks from being generated for the same original invoice.

The red reversal result returns to the HIS charging order, patient query portal, and finance ledger. The window can see continuous statuses such as "refunded, red reversal in progress, red reversal completed" from the original order, and finance can also trace from the red invoice to the original invoice and refund, so the forward and reverse chains are closed.

State machine for hospital charging, invoicing, refund, and red-letter reversal

▍Daily operation: status write-back and reconciliation identify discrepant orders

Every key result is written back to the original order: validation passed, accepted, issued successfully, file pending delivery, delivery completed, refund, and red reversal. HIS, the invoicing platform, and the finance ledger use the same business primary key, so the hospital can query by order, invoice number, time, and status, while the patient portal only shows results the patient is authorized to access.

Daily reconciliation compares HIS actual receipts with invoiceable amounts, platform applications with invoiced amounts, and file delivery and refund red-reversal results. If the three ends have different statuses, the list directly shows the order number, current discrepancy, most recent interaction, and handling role. Finance handles specific orders every day, with no need to wait until month-end to hunt for differences against totals.

Kailing Technology is responsible for orchestrating orders, invoices, callbacks, and logs into the hospital's existing processes, and cooperates with HIS, the invoicing platform, and in-hospital roles to complete joint debugging. Project results should be demonstrated by status being written back, discrepancies being located, and failures being recovered, not merely by a single success returned in the test environment.

▍Launch acceptance: a set of exception orders completes the interface closed loop

The acceptance team prepared samples for normal outpatient visits, duplicate clicks, unmapped items, inconsistent amounts, application timeout, lost callback, file retrieval failure, full refund, and partial refund. Each sample was initiated from real operations in the HIS, and results were checked on the window, patient side, finance side, and interface ledger.

Pass criteria are written as actions: duplicate requests return the original task, missing mappings are located to the project, timeouts are queried first, lost callbacks can be retrieved, file failures are recovered separately, refunds enter red-letter reversal from the original invoice, and the final status is consistent across all three ends. After the issue is fixed, the same data is run again to form a reviewable record.

The hospital accordingly accepts order verification, idempotent issuance, query callback, file delivery, red-letter reversal, write-back, and reconciliation. That outpatient order that once showed three different statuses on three pages also becomes the go-live benchmark: every role can find the stage and the next step.

▍FAQ

Q: Will repeated clicks by the patient generate multiple invoicing requests?

A: The system identifies the same order through the business primary key and request number. Repeated clicks return the current status of the original task.

Q: What should be done if the window shows submitted but the patient cannot see the invoice?

A: Staff query the platform result by order number, check the callback and file delivery status, and then retrieve or restore from the original task.

Q: Can I immediately reapply after the invoicing interface times out?

A: First use the order number or request number to query the original application, confirm the status, and then perform the corresponding recovery action to avoid duplicate issuance.

Q: How should the original invoice be handled for a partial refund to a patient?

A: After the HIS confirms the refund, the system links the original invoice and original item, initiates processing according to the red-letter reversal scope, and writes the result back to the order and financial ledger.

Use outpatient, inpatient, and refund samples to verify the full interface chain, and learn about Kailing Technology's hospital HIS invoicing solution: www.kailingteck.com .

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 the Leqi interface, hospital automatic invoicing, order verification, invoice red-letter reversal, invoicing result query, HIS interface