100% OPERATIONALALL FEATURES PRESENTED ARE ALREADY IMPLEMENTED IN ICU DATA EXPERT
SOURCES & EVIDENCE
Commercial claims kept separate from scientific references.
This page documents the main external references used to contextualise the value of documentation, coding and automation. External results are not presented as guaranteed ICU DATA EXPERT performance.
Swiss randomised trial — DRG coding optimisation
+6.5% reimbursement per hospital day in the precoding group.
Three guides to prepare a discussion between unit reviewers, coding teams and IT. They propose a checking method; they do not replace official rules or local validation.
MDSi: check data before submission
For quality reviewers and the unit’s data leads.
The Swiss Society of Intensive Care Medicine publishes MDSi documents and their validity period. For 2026, its data page lists regulation V33. This reference must be distinguished from the way software collects and prepares information.
Identify the reference applicable to the data year, the unit concerned and the person authorised to release the submission. Keep this information with the exported batch.
Check a sample for assignment to the correct ICU episode, admission and discharge times and identifier consistency. Do not confuse a patient record with an ICU stay.
Review missing fields and flagged inconsistencies, then document the checks. A missing value must not silently become a normal value by default.
Compare the prepared file with the checked data, retain its version and review the receiving system’s response. A generated file is not yet an accepted file.
Suggested review record
An identified batch, resolved or explained anomalies, reviewer approval and the associated submission response.
In the workflow presented by ICU DATA EXPERT, a data interruption prompts a review: it does not by itself establish that ventilation stopped. Any reconstructed duration must remain linked to documented evidence from the stay.
Identify the episode, the start and end of the suspected interval and the origin of the signal: missing samples, incomplete documentation or a change in context.
Compare the interval with available record evidence: ventilatory support, device insertion or removal events and patient movements. Do not invent missing times.
Have any correction validated by the authorised reviewer. Retain its origin, justification and the information needed to retrieve it.
After recalculation, check the total, individual periods and their presentation in the documents. The coding team then applies the rules relevant to the case; a correction does not automatically imply additional reimbursement.
Suggested review record
A confirmed, corrected or unresolved period with the reason recorded, accompanied by the recalculated result and professional validation.
For IT leads, database administrators and clinical workflow reviewers.
Technical acceptance must cover the whole chain, not just engine startup. With PostgreSQL, a hot standby replica is read-only and may lag behind its source. Encryption and verification of server identity are separate checks.
Describe the source, replica, transformation layers, engine and document destinations. Identify inter-machine flows and authorised accounts without including secrets in the checklist.
Prepare permission, encryption and certificate checks for each connection with IT. For PostgreSQL libpq clients, verify-full also checks the server name; the exact setting depends on the client used.
Test data lag, an interruption and recovery outside production. Check what is reported to the reviewer and distinguish process availability from data freshness.
Use synthetic or properly anonymised test cases to compare source data, calculations and documents. Record expected results, discrepancies, the go-live decision and the planned rollback.
Suggested review record
An architecture record and test matrix approved by technical and workflow owners. This is a preparation aid, not an installer or a compliance certificate.