Kōami
Resources

Ideas on running connected healthcare

Practical writing on clinical operations, workforce, imaging, supply chain and interoperability - from the team building Kōami.

Product
Product· 4 min read

Why We Built Kōami as One Connected Ecosystem

We kept walking into hospitals that were running four or five systems which could not talk to each other, and watching staff re-key the same patient into every one of them. A person would be registered at the front desk, typed again into the lab system, typed a third time at the pharmacy counter, and once more into the billing software before they were discharged. Every one of those keystrokes was a chance to introduce an error, and every reconciliation between the systems was a chance to lose money, time, or trust. Kōami is our answer to that. It is a connected ecosystem of clinical-grade software - hospital operations, workforce, inventory, imaging and field service - that shares one identity and one data model, so the work flows instead of the paperwork. This piece explains the problem we set out to solve, the principles we built on, and how the pieces fit together in practice. ## The real cost of disconnected systems The bill for fragmentation rarely shows up as a single line item. It hides in the extra minutes at every counter, the duplicate records that have to be merged, the claims that bounce because a charge was captured in one system and billed from another. It shows up when a ward runs out of a consumable that the store thought it had, because the two were counting from different books. Individually, none of these is a catastrophe. Together, across thousands of patients a month, they are the difference between a hospital that runs smoothly and one that is always fighting its own tools. The staff feel it first, because they are the ones bridging the gaps by hand. > A product is only as good as the seams between its parts - so we tried not to have any. ## One identity, one data model The foundation of the ecosystem is deliberately boring: a single identity and a single data model. A patient is registered once and carries the same Unique Medical Record across every product. A staff member has one account, one set of permissions, and one place their credentials live. An item of stock is the same item whether the ward is consuming it or the store is reordering it. That shared spine is what lets the products behave like one system instead of five. When a discharge in the hospital module deducts consumables in inventory and frees a bed on the occupancy board, nobody has to reconcile anything - because there was only ever one event, seen from three angles. ## Five products, each strong on its own We did not want to force anyone to adopt everything at once. Each product stands on its own and solves a real problem the day you switch it on: - Kōami Hospital connects registration, OPD, IPD, EMR, pharmacy, lab, radiology and billing to one patient record. - Kōami Workforce handles rostering, geofenced attendance, statutory payroll and credential compliance for a round-the-clock hospital. - Kōami Inventory keeps stock, batches and expiry under control, and reorders before anything runs out. - Kōami PACS streams imaging studies to a browser-based viewer with AI-assisted findings and structured reporting. - Kōami Field Service dispatches technicians and tracks SLAs so biomedical equipment stays up. Most customers start with one - usually where the pain is loudest - and add the rest over time. Because they share the data model, each new product lights up already knowing your patients, your staff and your stock. ## Interoperability, not a walled garden A connected ecosystem is not the same as a closed one. Hospitals already run software they cannot and should not replace overnight, so Kōami is built to exchange data with the world around it through open REST APIs and webhooks. The goal is that adding Kōami never means ripping out something that already works; it means giving the pieces a common language. ## Security as a foundation, not a feature Because everything shares one identity, we could make security a property of the whole platform rather than a bolt-on per product. Single sign-on with multi-factor authentication, granular role-based access, and audit logging that spans every product mean the right people see the right data, and every access is accountable. Getting this right once, at the foundation, is far better than getting it slightly wrong five times. ## What this looks like on a normal Tuesday Consider an ordinary admission. A patient is registered once and admitted; orders, medicines and results flow through EMR, pharmacy and lab. The right clinicians are auto-rostered to the ward, their attendance captured on a geofenced check-in. Consumables are deducted from stock in real time, triggering an automatic reorder before the shelf runs low. An imaging study is read in the browser with AI findings alongside. A flagged biomedical device raises a work order, and a technician is dispatched before it fails. No one re-typed anything, and no one reconciled anything - the systems simply agreed, because they were never really separate. ## The road ahead We are early, and we are building alongside a first group of hospitals and clinics who are shaping the platform around how care actually works. That is the whole idea: start where the pain is, prove the value on real data, and let the ecosystem grow with you. If that sounds like the kind of partner you want, we would love to talk.

Read article
Operations
Operations· 5 min read

Live Bed Management from ADT to Discharge

Ask a bed manager how many beds are free right now and you will often get a pause, a phone call, and a number that is already wrong by the time it is spoken. The bed board on the wall said one thing at eight this morning; the ward knows another; the emergency department, holding patients on trolleys, is working from a third. A bed that a system marks as occupied may have been vacated an hour ago and not yet cleaned; a bed marked free may already be promised to a transfer nobody logged. Bed management is the circulatory system of a hospital, and when the picture is stale, everything downstream - admissions, transfers, discharges, the emergency department's ability to breathe - runs on guesswork. Getting it right is less about counting beds and more about keeping the count true, minute by minute, as patients move. ## The problem is not beds, it is truth Most hospitals do not have a bed-counting problem. They have a bed-truth problem. The physical beds are there; what is missing is a single, current, trustworthy statement of their state. When the information lives in a whiteboard, a ward register, and several people's heads, it drifts out of sync the moment anyone moves. The states a bed can be in are not just "full" and "empty." A useful picture distinguishes: - Occupied - a patient is in the bed now. - Ready - clean, made up, and available to admit immediately. - Vacated but dirty - the patient has left, the bed needs turning over before reuse. - Blocked - out of service for maintenance, isolation, or infection control. - Reserved - held for a known incoming admission or transfer. A bed marked simply "free" hides all of this. The emergency department cannot tell an immediately-usable bed from one that is still dirty, so it either waits unnecessarily or sends a patient to a bed that is not actually ready. Kōami tracks these states distinctly, so "free" means genuinely ready, and the difference is visible rather than assumed. ## ADT as the single source of movement Every change in bed state comes from a patient movement, and those movements have a name: admission, discharge, and transfer - ADT. If bed status is updated separately from the ADT events that cause it, the two will always disagree. The only reliable design is to make the movement drive the status, so they cannot diverge. > A bed board is only as honest as the last movement someone remembered to log. Tie it to ADT and honesty stops depending on memory. When an admission is recorded, the bed becomes occupied automatically. When a transfer is ordered, the origin bed enters turnover and the destination is reserved. When a discharge completes, the bed moves to vacated-but-dirty and a housekeeping task is raised. Because Kōami drives bed status directly from ADT, the board reflects reality as a consequence of the movements that were going to be recorded anyway, not as a second, easily-forgotten step. The nurse does not update the bed board; the act of admitting the patient updates it. ## Closing the loop with housekeeping The gap that costs hospitals the most is the one between "patient discharged" and "bed ready." A discharged patient does not free a bed; a cleaned bed does. In many hospitals that turnover is a phone call away from happening, which means it happens late, and beds sit dirty and unusable while patients wait for them. Making the loop automatic changes the economics of the whole ward: - A completed discharge raises the cleaning task the instant it happens, not when someone calls. - Housekeeping sees the queue of beds to turn over, prioritised by demand. - When cleaning is marked done, the bed flips to ready and re-enters the live count immediately. - The admissions and emergency departments see that readiness the moment it exists. That closed loop is where the waiting-for-a-bed problem is actually solved. The bed that a discharge freed at eleven becomes a bed the emergency department can use at half past, because the turnover was triggered, tracked, and reported without a single chase-up call. Kōami connects discharge, housekeeping, and the live bed count so the handoff carries itself. ## Occupancy you can act on, not just admire Bed occupancy is one of the most quoted numbers in hospital management and one of the least useful when it arrives a day late. A monthly average occupancy figure tells the board something; a live occupancy view tells the operations team what to do in the next hour. The two are different tools, and the live one is where daily decisions get made. A real-time picture lets the bed manager act before a squeeze becomes a crisis. When occupancy in one ward crosses a threshold, it shows now, while there is still time to expedite a discharge, open a flexed bed, or redirect an admission. When the emergency department is holding patients, the bed manager can see exactly which beds are close to ready and push the turnover on those specifically. Occupancy broken down by ward, by specialty, and by bed type turns a single blunt percentage into an actionable map. Kōami keeps this view current so the number is a lever, not a postmortem. ## The whole patient journey, one connected flow Bed management does not live alone. It is the hinge between admission and discharge, and it only works when it is connected to both. The discharge that frees a bed, the OPD or emergency admission that fills one, the transfer between wards, the housekeeping turnover - these are not separate systems that need reconciling. They are one flow of the patient through the hospital, and the bed state is simply the visible trace of that flow. When they are connected in one ecosystem, the benefits compound. An earlier-initiated discharge frees a bed sooner, which the emergency department sees sooner, which shortens someone's wait on a trolley. A transfer logged properly keeps two wards' counts honest at once. The bed board stops being a thing someone maintains and becomes a thing the hospital's own movements keep true. That is the real goal of live bed management: not a perfect count for its own sake, but a hospital that always knows where its next bed is coming from - and can act on that knowledge while it still matters.

Read article
Operations
Operations· 6 min read

Scheduling the Operating Theatre Without Collisions

The operating theatre is the most expensive room in the hospital and the one least forgiving of a scheduling mistake. A collision there is not a double-booked meeting room; it is an anaesthetised patient, a scrubbed team, and a surgeon waiting because the previous case overran and nobody rebalanced the list. The OT schedule sits at the intersection of surgeons, anaesthetists, nurses, equipment, and the patient's own preparation, and every one of those has to line up in the same room at the same time. Scheduling it well is less about a prettier calendar and more about respecting the constraints that, when ignored, turn into cancellations, overtime, and a theatre that runs at a fraction of its capacity. ## Why theatre scheduling is genuinely hard People who have never built an OT list underestimate it because a calendar looks simple. The difficulty is that a single slot is not one resource but a set of resources that must all be free together, and each has its own rules: - The surgeon has to be available, and not already listed in another theatre. - The anaesthetist has to cover the case, and cannot be in two rooms at once. - The theatre itself has to be free, cleaned, and turned over from the previous case. - The specific equipment or implant set has to be present, sterilised, and not committed elsewhere. - The patient has to be prepared - fasted, consented, pre-assessed, and physically ready. Book a slot that satisfies four of these and misses the fifth, and you have a cancellation waiting to happen. A booking system that only tracks the room is not scheduling the OT; it is scheduling the furniture. Real OT scheduling checks every constraint at the moment of booking, so the collision is caught on screen rather than discovered in the corridor. ## Booking against every constraint, not just the room The core move is to make a booking impossible to confirm until all the resources it needs are actually free. When the scheduler proposes a case, Kōami checks the surgeon, the anaesthetist, the theatre, and the required equipment set against everything else already on the list, and refuses the clash instead of quietly accepting it. A double-booked surgeon is flagged where it can still be fixed. > The cheapest cancellation is the one prevented at booking. Every other kind is paid for in wasted theatre time and a patient sent home unoperated. That validation is what separates a scheduling system from a shared diary. It also lets the scheduler see the real picture - which surgeon has capacity on Thursday, which theatre has a gap, whether the implant set booked for the morning case will be back in time for the afternoon one. Estimated case durations feed the layout, so the list reflects how long procedures actually take rather than an optimistic guess, and the turnover time between cases is built in rather than assumed to be zero. ## Turnaround is where theatres win or lose time Ask why a theatre managed six cases instead of eight, and the answer is usually not the surgery. It is the gaps between cases - the turnaround, when one patient leaves, the room is cleaned, the next set is prepared, and the next patient is brought in. Those gaps are where capacity quietly evaporates, and they are almost always longer than anyone admits. Scheduling has to treat turnaround as a real, planned interval, not dead space that magically disappears. That means: - Building realistic cleaning and set-up time into the list, per procedure type. - Sequencing cases so that equipment and staff flow from one to the next without a scramble. - Having the next patient prepared and ready before the current case finishes, not after. - Watching the list live so that when one case overruns, the downstream cases are adjusted deliberately rather than colliding. When the schedule respects turnaround honestly, the theatre stops overrunning into the evening and starts finishing its planned list within the planned day. Kōami keeps the running list visible so the OT coordinator can see slippage as it happens and rebalance - move a short case forward, alert the next surgeon, adjust the afternoon - instead of finding out at handover that the day has fallen an hour behind. ## The safe-surgery checklist as part of the flow A schedule that packs the theatre efficiently but drops the safety steps has optimised the wrong thing. The safe-surgery checklist - the structured pauses before induction, before incision, and before the patient leaves the room - is not paperwork to be squeezed out when the list is tight. It is the guardrail that catches the wrong-site, wrong-patient, wrong-procedure errors that no amount of scheduling efficiency can be allowed to risk. The practical answer is to make the checklist part of the case flow rather than a separate form that competes with it for time. When the pre-operative verification, the sign-in, the time-out, and the sign-out are steps in the same record that carries the schedule, they get done because they are part of moving the case forward, not despite the pressure of the list. Kōami supports the checklist as an integral part of the OT workflow, so the drive for throughput and the discipline of safety pull in the same direction instead of against each other. ## Measuring utilisation to plan better lists You cannot improve theatre efficiency you do not measure, and the measures that matter are specific. Utilisation - the share of available theatre time actually spent operating - tells you whether the room is earning its keep. Start delays tell you whether the first case of the day is dragging the whole list. Turnaround times tell you where the hidden gaps are. Cancellation rates, and the reasons behind them, tell you which constraint keeps breaking. Those numbers turn scheduling from a daily firefight into a plannable operation. If first-case start times slip consistently, you fix the morning preparation, not the surgeon. If a particular procedure always overruns its booked slot, you adjust its estimated duration so future lists are honest. If cancellations cluster around missing equipment sets, you fix the sterilisation loop. Kōami keeps this history so the OT manager tunes the next month's lists against evidence rather than the loudest complaint from last week. Scheduling the theatre without collisions is not a scheduling trick. It is the accumulation of honest constraints checked at booking, realistic turnaround built into the list, safety kept inside the flow rather than outside it, and utilisation measured so the plan gets better each cycle. Get those right and the most expensive room in the hospital finally spends its time doing the thing it exists for - operating - instead of waiting.

Read article
Operations
Operations· 6 min read

Running a Multi-Branch Hospital Group on One System

A hospital group is not one hospital repeated. It is several hospitals, each with its own consultants, its own local suppliers, its own quirks of layout and habit, and a head office that needs to see all of them at once without flattening what makes each one work. The temptation, when a group grows, is to let every branch run its own systems and reconcile the numbers later. That works until it does not - until a patient who was seen at one branch turns up at another and their history is invisible, until central procurement cannot tell which site is overstocked while another runs dry, until the monthly board pack is three weeks of manually merging spreadsheets that never quite agree. Running a group on one system is not about central control for its own sake. It is about giving each branch autonomy where it needs it and the group visibility where it needs that. ## One patient, many branches The clearest test of a group system is what happens when a patient moves between sites. In a federated mess of separate systems, the patient is effectively a new person at each branch - re-registered, re-explained, their allergies and history left behind at the site that first recorded them. That is not just inconvenient. It is a clinical risk, repeated at every internal referral. A single patient identity across the group fixes this. The same person carries one record, one history, one set of allergies and results, wherever in the group they are seen: - A referral from a smaller branch to the group's tertiary centre arrives with the full history attached, not a scribbled note. - Results ordered at one site are visible to the treating clinician at another. - The patient does not repeat their story, or their registration, at every door. Kōami holds that shared identity while still letting each branch run its own OPD, its own wards, and its own local workflows. The record is common; the operation stays local. That balance - shared where it helps the patient, local where it helps the branch - is the whole design principle of a group system. ## Cluster structure without a straitjacket Groups are rarely flat. There are clusters - by city, by region, by tier - and the reporting and control structure has to reflect that reality rather than fighting it. A regional director wants to see their cluster rolled up; a branch administrator wants their own site's numbers without noise from the others; the board wants the whole group on one page. > Centralisation should be a dial, not a switch. Some things belong to the group; many things belong to the branch; wisdom is knowing which is which. The workable pattern is a hierarchy where the group sets the standards - the master data, the item catalogue, the chart of cost centers, the core policies - and each branch operates within them while keeping local control of the things that are genuinely local. Doctor rosters, OT schedules, ward configurations, and local vendor relationships stay with the branch. Pricing might be set centrally with room for local adjustment, or set locally within group-defined bands. Kōami supports that layered structure so the group is coherent without every branch being forced into an identical mould that fits none of them well. ## Inventory that moves across the group Stock is where a group system pays for itself fastest. Each branch running its own isolated store will, reliably, produce the same absurd situation: one site writing off expired reagents while another places an emergency order for the very same item at a premium. They simply cannot see each other. Put the branches on one inventory backbone and that waste becomes visible and fixable. Before any site raises an external purchase order, the system can check group-wide stock and suggest an inter-branch transfer from a location holding surplus. Central procurement can negotiate as a group - real volume, real leverage - while each branch still requisitions against its own cost center and receives against its own GRN. - See on-hand stock across every branch and the central store in one view. - Suggest transfers before purchases, turning one site's surplus into another's supply. - Negotiate group contracts on real aggregate volume, not per-site guesswork. - Keep reorder points local to each branch's actual consumption and lead times. Because Kōami connects inventory and procurement across the whole group, the reorder logic and the three-way match that work for a single hospital simply extend across many, with the group's scale as an added lever rather than an added headache. ## Reporting that reconciles by design The monthly grind of merging branch spreadsheets exists only because the branches were never on the same data model. When they share one system, the roll-up is not a project; it is a query. Occupancy, revenue, OPD throughput, average length of stay, stock value, procurement spend - each can be read per branch, per cluster, or for the group as a whole, using the same definitions everywhere. That last point is the quiet one that matters most. When "bed occupancy" or "average length of stay" means the same thing at every site, comparison becomes fair and useful. You can see that one branch discharges faster, ask why, and spread the practice. When every site defines its metrics slightly differently, comparison is noise and the board learns nothing. A common system enforces common definitions as a byproduct, so benchmarking across the group becomes a management tool rather than an argument about whose numbers are right. ## Rolling out without breaking the branches The risk in unifying a group is a big-bang cutover that disrupts live clinical operations across many sites at once. The saner path is to bring branches onto the shared system in sequence, prove the model at one or two sites, carry the master data and identity forward, and let each branch adopt the common core while keeping its local configuration intact. Kōami's shared-identity, layered-control structure is built for that gradual convergence rather than an all-or-nothing switch that no operating hospital can safely afford. A multi-branch group run well feels, to a patient, like one organisation that happens to have several front doors. It feels, to a branch administrator, like their own hospital with better backup. And it feels, to the group's leadership, like a single trustworthy picture instead of a monthly reconciliation. Getting there is not about imposing sameness. It is about sharing what should be shared - the patient, the standards, the visibility - and leaving to each branch the local judgement that made it worth having in the first place.

Read article
Supply Chain
Supply Chain· 6 min read

Procure-to-Pay Without the Paperwork

Procurement is where good hospitals lose money and time in ways that never show up on a clinical audit. A single purchase can pass through a requisition, a quotation, an approval, a purchase order, a delivery, a goods receipt, an invoice, and a payment - and at every handoff there is a form, a signature, a phone call, and a chance to lose the thread. When those steps live in email, spreadsheets, and a shared drive of scanned PDFs, the finance team spends its month reconciling instead of controlling. Procure-to-pay done well is not about buying software to digitise the paperwork. It is about removing the paperwork so the control that mattered - who approved what, and does the invoice match reality - is enforced by the flow itself. ## The paper trail that quietly costs a fortune Before you can fix procurement, it helps to see honestly where the money and hours leak. In a paper-and-email process, the usual suspects are always the same: - Requisitions that sit in someone's inbox because there is no queue and no owner. - Purchase orders raised without checking an agreed price or preferred vendor, so the hospital pays retail on a contracted item. - Deliveries received against a delivery note that nobody reconciles to the PO, so short-shipments and wrong items slip through. - Invoices paid because they arrived and looked plausible, not because they were checked against what was ordered and what was received. - Duplicate payments, because the same invoice came by email and by post and nobody caught it. None of these are exotic failures. They are the ordinary friction of a manual process, and across a year they add up to real money and a finance team that is always behind. The fix is to make each step create a record that the next step is forced to check. ## One flow from requisition to purchase order The front half of procure-to-pay is getting from "a ward needs something" to "a purchase order is with the vendor" without losing days to chasing. In Kōami that path is a single connected flow. A requisition is raised against a cost center, routed to the right approver by value and category, and - once approved - turned into a purchase order that already knows the preferred vendor and the agreed price. > A purchase order is a promise. If it does not carry the agreed price and the right vendor, you are negotiating again at invoice time, when you have the least leverage. Because the requisition, the approval, and the PO are the same object moving through states rather than three documents retyped, the audit trail is a byproduct, not a chore. Anyone can see who requested, who approved, and on what terms, without opening a filing cabinet. And because inventory and procurement sit in the same ecosystem, a reorder trigger from the store can draft the requisition automatically, so routine replenishment does not wait for someone to notice. ## GRN and the three-way match The moment goods arrive is the moment control is won or lost. A goods receipt note (GRN) records what actually turned up - the quantities, the batches, the condition - against the purchase order that ordered it. That comparison is the first line of defence. If forty units were ordered and thirty-eight delivered, the GRN catches it there, at the loading dock, not six weeks later when finance is puzzling over a mismatched invoice. The real discipline is the three-way match: the purchase order, the goods receipt, and the vendor invoice all have to agree before payment is released. This is the single most effective control in procurement, and it is almost impossible to enforce by hand at volume: - The PO says what was ordered and at what price. - The GRN says what was actually received. - The invoice says what the vendor is charging. When all three line up, payment can proceed with confidence. When they do not, the exception is flagged for a human rather than paid on trust. Kōami runs this match automatically, so the finance team's attention goes to the handful of genuine discrepancies instead of the hundreds of clean transactions. Short-shipments, price creep, and duplicate invoices surface as exceptions rather than slipping through as payments. ## Vendors and cost centers you can actually see Managing vendors well is not about having their phone numbers. It is about knowing, at any moment, how each one performs and what you are actually spending with them. When every PO, GRN, and invoice is connected, the vendor record stops being a contact card and becomes a performance history: who delivers on time, who short-ships, whose lead times have quietly doubled, who keeps sending invoices that do not match. That history feeds better decisions. The lead-time data flows back to inventory so reorder points reflect the vendor's real behaviour, not their promises. The pricing data shows where a contracted rate is being honoured and where it is drifting. And because spend is tagged to a cost center, department heads can see what their unit is consuming and finance can hold budgets against reality rather than guesswork. - Track on-time delivery and fill rate per vendor, from the GRN data you already capture. - Watch price variance against agreed rates so contract leakage is visible. - Attribute every purchase to a cost center so budgets mean something. - Keep the full approval and match trail on each transaction for clean internal review. None of this requires extra data entry. It falls out of running the flow properly, because each step already recorded what it needed to. ## Paying with confidence, and paying once Payment should be the calm end of a controlled process, not the anxious moment where you hope the numbers were right. When the three-way match has already cleared, releasing payment is a decision made on evidence: this was ordered, this was received, this is the correct amount, and this invoice has not been paid before. Duplicate detection stops the same bill being settled twice. The approval chain means no single person can quietly push through a payment that nobody else saw. Procure-to-pay without the paperwork is not a promise of less work for its own sake. It is a promise that the work which remains is the work that matters - negotiating with vendors, managing budgets, resolving real exceptions - while the repetitive checking that used to eat the finance team's month is handled by a flow that never skips a step. Kōami ties requisition, PO, GRN, invoice, and payment into that one flow, so control stops depending on whether someone remembered to reconcile, and starts being simply how the process runs.

Read article
Supply Chain
Supply Chain· 5 min read

Reorder Points That Prevent Stock-Outs

Every hospital store has two failure modes, and they are mirror images of each other. In one, a critical item runs out at the worst possible moment - a suture size mid-procedure, a reagent the lab needs before the morning run, a drug the ward assumed was always there. In the other, a cupboard is quietly stacked with six months of something that expires in three, capital tied up in stock nobody will use in time. Both come from the same root: someone is guessing when to reorder, and human guessing does not scale across thousands of line items. Reorder points exist to replace the guess with arithmetic, and arithmetic that runs by itself does not forget, does not go on leave, and does not panic-order. ## What a reorder point actually is A reorder point (ROP) is the stock level at which you place a new order. It is not a vibe or a gut feel; it is a number you can calculate, and it rests on three inputs you already have or can measure: - Average daily consumption - how fast the item actually moves, not how fast you think it does. - Lead time - how long the vendor genuinely takes from purchase order to goods received, in practice, not on paper. - Safety stock - the buffer that absorbs the normal variation in both of the above. The core relationship is simple: ROP equals average daily usage multiplied by lead time, plus safety stock. When on-hand quantity falls to the ROP, you order enough to bring stock back up toward a defined maximum. That min/max/ROP framing is the whole discipline in one line. The hard part is not the formula. It is keeping the inputs honest and acting on the trigger every single time. ## Why min/max beats intuition at scale A charge nurse can eyeball reordering for the dozen items she touches every day. She cannot do it for the several thousand SKUs a hospital carries across pharmacy, consumables, lab reagents, and OT sets. At that scale, intuition degrades into a mix of over-ordering the familiar and under-ordering the rare-but-critical. > Stock-outs are rarely a supply problem. They are almost always a signal problem - nobody saw the level fall until it was already too late. Setting a minimum and a maximum per item turns thousands of judgement calls into thousands of rules that the system checks continuously. The minimum is your ROP; the maximum caps how much you hold so you do not swing into overstock. Kōami watches on-hand quantity against those thresholds in real time and raises the reorder the moment stock crosses the line, so the trigger does not depend on a person happening to open the right cupboard on the right day. The payoff is not just fewer stock-outs. It is fewer emergency purchases at bad prices, less expired stock written off, and a store manager who spends time on exceptions instead of on counting. ## Consumption is not constant, so the numbers must move The quiet failure of static reorder points is that they are set once and never revisited. Consumption is seasonal and situational. A dengue season spikes certain reagents and fluids. A new surgeon joining the OT changes the demand for a particular set of consumables overnight. A single high-volume month can shift the true average well away from the number someone typed in last year. Reorder points have to breathe with demand. That means recalculating average daily consumption on a rolling basis rather than freezing it, and reflecting real observed lead times rather than the vendor's optimistic quote. When a vendor who used to deliver in three days is now taking eight, the safety stock and ROP for their items should rise to match, automatically, before that slippage becomes a shortage. - Recompute average usage on a moving window so trends are captured early. - Track actual lead time per vendor and per item, and feed it back into the ROP. - Flag items whose consumption pattern is changing sharply for a human to review. - Separate steady movers from lumpy, unpredictable ones - they need different buffers. Kōami keeps this loop running so the thresholds stay tied to reality instead of drifting into fiction the moment they are set. ## From trigger to purchase order without the scramble A reorder trigger that only sends an email is half a solution. The point is to shorten the distance between "stock is low" and "replenishment is on its way." When on-hand crosses the ROP, the system should be able to draft the purchase order itself - the right item, the right quantity to reach maximum, the preferred vendor, the last agreed price - and put it in front of the person who approves it. That person is still in control. What changes is that they are approving a well-formed order rather than assembling one from scratch under time pressure. For low-value, high-frequency items, the approval can be light; for expensive or clinically critical ones, it stays deliberate. Because Kōami connects inventory to procurement, the drafted PO carries straight through to the vendor, and when the goods arrive the GRN posts back against stock, which updates on-hand, which keeps the next ROP calculation accurate. The loop closes on itself. Multi-store hospitals get an extra benefit here. Before raising an external order, the system can check whether another branch or central store is holding surplus, and suggest a transfer instead of a purchase. That turns dead stock in one location into a stock-out prevented in another. ## Getting started without boiling the ocean You do not need perfect data to begin, and waiting for it is how these projects die. Start with the items that hurt most when they run out - the critical, fast-moving, or expensive ones - and set defensible min/max levels using whatever consumption history exists. Let the system run, watch where it over- and under-corrects, and tighten from there. The numbers get better precisely because they are being used. The goal is not a warehouse that is never wrong. It is a store where the boring, repetitive vigilance is handled by arithmetic that never sleeps, so that the pharmacist and the store manager are freed to deal with the genuine exceptions - the recall, the shortage, the new procedure - that actually need a human. Reorder points that run themselves are not about clever software. They are about making sure nobody ever again discovers a stock-out by reaching for an empty shelf.

Read article
Patient Experience
Patient Experience· 6 min read

A Portal Patients Actually Use

Most patient portals fail the same way. They are built as a compliance checkbox or a marketing feature, launched with fanfare, and then quietly abandoned by the people they were meant to serve. Patients log in once, cannot find their report, hit a dead end, and never return. The clinic concludes that patients "do not want digital," which is exactly the wrong lesson. Patients want the specific things a portal can do for them. What they do not want is a second, worse version of the hospital's paperwork, dressed up in a login screen. A portal patients actually use starts from what the patient came for, not from what the IT roadmap wanted to tick off. ## Start from the three things patients actually want Walk up to someone in a waiting room and ask what they wish they could do without calling the hospital, and you will hear a short, consistent list. Not a feature matrix - a handful of real needs: - See my test results as soon as they are ready, and understand what they mean. - Book, move, or cancel an appointment without waiting on a phone line. - Get my prescription and discharge instructions in a form I can actually read later. Everything else is secondary. A portal that does these three things reliably will be used every week. A portal that does thirty things badly will be used once. The discipline is to make the common path effortless and to resist burying it under features that sound impressive in a demo and matter to almost no one. Kōami's approach is to treat the portal as the patient-facing surface of the same record the clinicians use, not a separate island that has to be manually synced. When a result is finalised in the lab, it is available to the patient. When an appointment moves, the patient sees the new time. There is no overnight batch, no re-entry, no divergence between what the front desk knows and what the patient can see. ## Results that explain themselves A lab value on its own is a source of anxiety, not information. A patient who sees "14.2" with no context will either panic or ignore it, and both are bad outcomes. The portal has to do a little of the work that a good clinician does at the bedside: show the reference range, flag whether the value is in or out of it, and where possible give a plain-language line about what the test was for. > A result the patient cannot interpret is not transparency. It is just a number that generates a phone call. There is a judgement call here, and it is worth making deliberately. Some results should reach the patient through their clinician first, not as a raw notification at eleven at night. A sensible portal lets the clinical team set the release rules - immediate for routine results, held for review on the sensitive ones - so that transparency does not come at the cost of a patient reading life-changing news alone and unsupported. Kōami supports that graduated release rather than treating every result the same way. ## Appointments the patient can actually manage Booking is where most portals quietly break. They show a calendar that is not really the clinic's calendar, so the patient books a slot that does not exist, turns up, and finds the doctor on leave. Trust, once broken that way, does not come back. The booking surface has to be the real schedule - the same slots the front desk sees, with the same holds and the same rules. Done properly, self-service booking takes load off the phone lines and gives the patient control at the same time. They can: - Book into a genuinely available slot for the right department and doctor. - Reschedule or cancel within the clinic's own policy window. - Get a reminder ahead of time, and a simple way to confirm they are coming. - See their upcoming and past visits in one place, tied to the same token and queue flow they will meet on the day. Because the portal shares the OPD scheduling and queue system, a booked appointment carries through to the token the patient receives on arrival. The online action and the physical visit are the same thread, not two systems the patient has to reconcile. ## Instructions that survive the car park Some of the most important minutes of a hospital visit happen in the last ten, when a tired patient is handed a prescription and a set of instructions and told to follow them at home. By the time they reach the car park, half of it is forgotten. This is where a portal earns its keep quietly and permanently. The discharge summary, the medication list with timing, and the follow-up plan should all land in the portal automatically, drawn from the same records the clinical team finalised. Not retyped, not a scanned photo of a handwritten note, but structured, legible, and available at two in the morning when the patient's daughter is trying to remember whether the tablet was twice a day or three times. Kōami links the portal to the discharge and prescription flow so this content appears without anyone re-keying it. That connection matters more than it first appears. When instructions live in the portal, the family can act on them, the patient is more likely to actually take the medication correctly, and the clinic gets fewer confused callbacks the next morning. ## Designing for the patient who is not tech-confident A portal that only works for the youngest, most digitally fluent quarter of patients has failed the majority who need it most. The design has to assume a tired, anxious, sometimes older user on a mid-range phone with patchy signal. That means large tap targets, plain language, minimal steps to the common tasks, and graceful behaviour when the connection drops. It means not forcing a password reset odyssey to see a blood test. And it means the front desk can still do everything on the patient's behalf, so the portal is an addition to human help, never a replacement that leaves the less-confident stranded. A portal patients actually use is not the one with the longest feature list. It is the one that shows results they understand, lets them manage appointments against the real calendar, and hands them their instructions in a form that survives the journey home. Build those honestly on top of the same records the clinicians trust, and the login screen stops being a dead end and starts being the front door people choose.

Read article
Patient Experience
Patient Experience· 5 min read

Why Discharge Takes So Long - and How to Fix It

Discharge is the part of a hospital stay that patients remember with the least fondness, and often for the most avoidable reasons. The doctor said "you can go home today" at half past ten in the morning. It is now four in the afternoon, the bed is still occupied, the family has taken a day off work, and nobody can quite say what everyone is waiting for. Meanwhile, downstairs in the emergency department, a patient who needs that exact bed is waiting on a trolley. Discharge delay is not a comfort problem. It is a capacity problem wearing a comfort problem's clothes, and it is almost always caused by process, not by clinical need. ## The morning the decision is made The decision to discharge is a moment. The discharge itself is a chain of tasks, and the gap between the two is where the hours disappear. Once a consultant marks a patient fit to leave, a surprising number of separate things have to happen, usually in sequence, usually owned by different people who cannot see each other's progress: - The discharge summary has to be written, reviewed, and finalised. - Pending investigations have to be chased, resulted, and acknowledged. - Take-home medication has to be prescribed, dispensed by pharmacy, and counselled. - Final billing has to be assembled, including charges that are still being posted. - Insurance or scheme approval has to clear the final amount. - Someone has to physically confirm the bed is vacated so housekeeping can turn it over. Any one of these can stall the whole thing, and because they are handed off by phone call and paper, nobody has the full picture. The nurse thinks pharmacy is the holdup. Pharmacy is waiting on the summary. The summary is waiting on a lab result that came back an hour ago but nobody saw. This is the ordinary anatomy of a six-hour discharge. ## Initiate discharge early, not at the end The single most effective change is to treat "initiate discharge" as an action taken on ward rounds, not a status that appears when the patient is already dressed and waiting. When the treating team flags a likely discharge the evening before, or first thing on the round, every downstream station gets a head start. In Kōami, initiating discharge fans the work out in parallel rather than in series. The pharmacy sees the take-home prescription forming and can pre-pack it. Billing begins assembling the final statement while the patient is still on the ward. The nurse gets a checklist of what remains outstanding, item by item, instead of discovering the gaps at the last minute. > Discharge should be a countdown that everyone can see, not a surprise that lands on the ward clerk at 3 p.m. That shift - from sequential to parallel, from silent to visible - is where most of the recovered hours come from. Nothing about the clinical care changes. The care was already done. What changes is that the administrative tail stops being run one baton-pass at a time. ## The discharge summary as a shared, living document The discharge summary is both a clinical handover and a bottleneck. When it lives in one doctor's head until the last moment, it holds up medication, follow-up, and the patient's own understanding of what happens next. When it is built up through the stay, it is nearly finished by the time discharge is called. A good system lets the summary accrue: the diagnosis, the course of treatment, the medications, and the follow-up plan populate as they are decided, drawing on data already captured in the record rather than being retyped. The consultant reviews and signs rather than authoring from a blank page. Kōami keeps the summary connected to orders, results, and prescriptions, so the take-home medication list and the follow-up appointment are not re-entered by hand into three places. Two practical wins follow. First, the patient leaves with a document that is actually complete and legible, not a hurried scrawl. Second, the follow-up loop closes, because the summary can trigger the follow-up booking and, where relevant, feed the patient portal so the family has the instructions after they get home. ## Billing and approvals that keep pace Money is the quiet reason discharges stall past clinical readiness. Final billing cannot close until every charge is posted, and charges trickle in from pharmacy, from the last round of investigations, from consumables used that morning. If billing only starts assembling when discharge is called, it is starting from behind. The fix is to keep the bill live throughout the stay so that at the moment of discharge only the final few items remain to be reconciled. Where an insurer or scheme is involved, the approval workflow should run alongside, not after, so the pre-authorisation and the final settlement are not a fresh negotiation at 3 p.m. - Keep charges posting in near real time so the final bill is minutes of work, not hours. - Surface the outstanding-charge list to billing before discharge is called. - Run payer approval in parallel with clinical clearance, not after it. - Give the ward a single view of billing status so the nurse can answer the family honestly. When billing keeps pace with care, the financial step stops being the thing that adds two hours to an otherwise finished discharge. ## Turning the bed over on purpose The last mile is physical. A patient marked as discharged in the system but still in the bed is not a freed bed. Housekeeping needs to know the room is vacated, turn it over, and mark it ready, and the admissions or bed-management desk needs to see that readiness the moment it happens. Without that loop, beds sit "discharged but dirty" for an hour while the emergency department queues. Kōami connects the discharge event to bed status and the ADT flow, so a completed discharge triggers the cleaning task and, when the room is ready, releases the bed back into the live count. The waiting patient downstairs moves up not because someone made a lucky phone call, but because the system carried the handoff. Fixing slow discharge is not about pushing people to hurry. It is about starting earlier, working in parallel, keeping the summary and the bill alive through the stay, and closing the loop on the bed. Do that, and "you can go home today" starts to mean today - by lunchtime, not by dusk.

Read article
Patient Experience
Patient Experience· 5 min read

Cutting the OPD Wait with Token and Queue

Ask any hospital administrator where the day starts to go wrong, and most will point at the same place: the OPD. The consultation itself might take eight minutes, but the patient has already spent ninety in a corridor, unsure whether they have been forgotten, whether they missed their name being called, whether the person who arrived after them is somehow ahead. The waiting is not just uncomfortable. It shapes how the patient rates the entire visit, and it quietly burns through front-desk goodwill all morning. A token and queue system does not make doctors faster. What it does is make the wait legible, fair, and predictable - and that turns out to matter almost as much as speed. ## What actually creates the queue Most OPD congestion is not a doctor problem. It is a flow problem, and it usually comes from a handful of concrete causes that stack on top of each other: - Registration and consultation share the same physical line, so new patients and follow-ups fight for the same counter. - Appointments are booked but walk-ins are also accepted, and the two streams are never reconciled at the point of care. - A doctor runs late by twenty minutes at 9 a.m., and because nothing rebalances the load, that twenty minutes is still there at 1 p.m. - Patients have no signal about their position, so they crowd the door of every room to avoid missing a call. When you name the causes plainly, the fix stops being "hire more staff" and becomes "design the flow." A token is just the first step of that design: a stable identity in the queue that the patient can trust. ## Tokens that carry context, not just numbers A paper token with a printed number solves one problem - order - and nothing else. A digital OPD token in Kōami carries context. It knows whether the patient is a new registration or a scheduled follow-up, which doctor and which department they are waiting for, and roughly where they sit in that specific queue. That context is what lets you do the interesting things. You can run parallel queues per doctor instead of one giant line, so a busy cardiologist's backlog does not stall the dermatology patients. You can weight the queue so that a booked appointment holds priority over a walk-in who arrived at the same minute, which is the only fair way to honour appointments at all. And you can hold a token in a "called but not arrived" state for a short grace period, then cycle to the next patient without losing the first one entirely. > A good queue is not the shortest one. It is the one where every patient can see that the rules are the same for everybody. The display board and the patient's phone show the same token state, so the corridor empties out. People stop hovering at the door because they can watch their number advance from a bench, or from the pharmacy, or from the café downstairs. ## Giving the front desk a live picture The counter staff need a different view from the patient. They need to see the whole floor: which doctors are running behind, which rooms have gone quiet, how many walk-ins are still unassigned, and where a bottleneck is forming before it becomes a crowd. Kōami puts that on one screen. When a consultant is thirty minutes behind, the supervisor can see it at a glance and act - open a second room, redirect a few follow-ups to a colleague, or simply reset expectations with the people waiting. That last option is underrated. A patient told honestly that the wait is now forty minutes, and given the freedom to step away, is far calmer than one left guessing. The system supports that by pushing a status update to the patient's phone when their token moves into the next band. Reassignment matters too. If a doctor is called into an emergency, the affected tokens should not evaporate. They should shift, as a group, to another available consultant or to a clearly communicated hold, with the patients notified rather than surprised. ## Measuring the wait so you can shrink it You cannot improve a wait you do not measure. Every token generates timestamps almost for free: when it was issued, when the patient was called, when the consultation started, when it closed. From those, real numbers fall out - average time to first call, the gap between appointment time and actual start, turnaround per department, and the shape of the morning peak. Those numbers change decisions. If registration is the choke point, you add a counter at 9 a.m. rather than at 11. If one clinic consistently overbooks, you cap its slots. If the peak is always 10 to 11:30, you stagger appointment blocks to flatten it. Kōami keeps this history so the OPD manager is tuning against evidence instead of yesterday's argument. - Time-to-first-call tells you if registration and triage are keeping up. - Appointment-to-start delay tells you whether your booking model is honest. - Per-doctor turnaround tells you where to rebalance load. - No-show and grace-period cycling rates tell you how much slack to build in. Over a few weeks these metrics stop being a report and start being a habit. The floor supervisor reads them the way a shift nurse reads vitals. ## Closing the loop with the rest of the visit The queue does not end when the patient sees the doctor. A consultation usually spawns a lab order, a pharmacy pickup, a follow-up booking, or a billing step, and each of those is its own small queue. When the token flows through to those stations, the patient is not starting from zero each time. Their lab request is already waiting when they reach the collection counter; pharmacy can see the prescription before they arrive. Because Kōami connects OPD, orders, and billing in one ecosystem, the token becomes a thread that runs through the whole visit rather than a slip that gets thrown away at the consulting-room door. Cutting the OPD wait is rarely one dramatic change. It is a token that carries context, a fair queue the patient can watch, a live floor view for staff, and a steady diet of timing data that tells you where to push. Do those four things well and the corridor stops being the worst part of the visit - and the eight-minute consultation finally gets to be the point of the morning.

Read article
Revenue Cycle
Revenue Cycle· 5 min read

Capturing Charges as Care Happens

Here is a number that should bother every hospital finance lead: the revenue you lose is rarely the bill you failed to collect. It is the charge you never captured in the first place. A consumable used in theatre and never scanned. An injection given on the ward and never posted. A procedure done at the bedside that nobody billed because the person who did it was busy doing the next one. Charge capture is the discipline of turning care that happened into charges that exist, and the gap between the two is pure, silent leakage. ## The leak nobody sees Uncollected bills are visible. They sit in a receivables report, they get chased, someone owns them. Uncaptured charges are invisible by definition - you cannot chase a charge that was never created. The service was delivered, the cost was incurred, and no revenue record was ever made against it. It does not appear as a loss because it never appeared at all. The leak concentrates in predictable places, all of them characterised by care happening faster than paperwork. - Consumables and implants used in theatre under time pressure - Drugs and injections administered on the ward between other tasks - Bedside procedures done by clinicians who are not thinking about billing - Investigations ordered verbally and performed before any order exists in the system None of these are fraud or laziness. They are the natural result of asking busy clinical staff to also be the billing department, using a workflow that treats charging as a separate task to be done later. Later is where charges go to be forgotten. ## Capture at the point of care, not after it The core principle is simple to state and hard to retrofit: the charge should be created as a byproduct of the clinical action, at the moment and place it happens, not reconstructed afterwards from notes and memory. When a nurse records that an injection was administered, that record should be the charge. When a consumable is taken from theatre stock for a case, that issue should generate the charge. The clinical act and the billable event are the same event, captured once. This is the opposite of the common pattern, where care is delivered all day and a clerk sits down at some point to bill it from the chart. Every hour between the act and the billing is an opportunity to lose it, and every reconstruction from notes is an opportunity to get it wrong. > A charge captured where the care happened is a charge that cannot be forgotten later, because it was never waiting to be remembered. Kōami ties charge capture to the clinical and stock events themselves - the administration record, the consumable issue, the procedure note - so the billable item is created as care is delivered rather than assembled from it afterwards. ## Let the tariff do the pricing Capturing that something happened is half the job; pricing it correctly is the other half. If clinical staff have to know or look up the price of everything they use, capture will fail, because that is not their job and they will not do it. The clinical action should record what was done and how much; the tariff should turn that into a priced charge automatically. When every service and item carries its tariff rate, the person at the point of care never has to think about money. They record the clinical fact - this drug, this dose, this procedure, this implant - and the correct charge follows from the rate card without a manual pricing step. This also keeps charges consistent, since the same tariff prices the same item every time regardless of who captured it. - Record the clinical fact at the point of care, not a price - Let the tariff convert the fact into a correctly priced charge automatically - Price the same item the same way every time, independent of who captured it - Keep the charge linked to the clinical event, so it can be justified if questioned ## What you get when the charge and the care are one When charge capture rides on the clinical workflow, several problems solve themselves at once. The bill at discharge is complete, because it was assembled continuously as care happened rather than reconstructed at the end. The running total is real throughout the stay, so a patient or a TPA can see an accurate figure at any point, not just a rough guess. And the leakage - the injections and consumables and bedside procedures that used to vanish - largely stops, because there is no longer a gap between doing the thing and charging for it. There is a second benefit that is easy to miss. A charge captured at the point of care carries its context - who did it, when, to which patient, against which order or clinical note. That context is exactly what you need when a charge is later questioned by a patient or an insurer. Instead of defending a line item reconstructed from memory, you have a charge tied to the moment of care that produced it. Charge capture is unglamorous, and that is precisely why it leaks. Nobody wakes up thinking about the injection that did not get billed, and no single missed charge is worth chasing. But the sum of them, across every ward and every theatre and every day, is a large number quietly missing from the hospital's revenue. Close the gap by making the charge and the care the same event - captured once, priced by the tariff, tied to the moment it happened. The care was already delivered. The only question is whether you charged for it, and that should never be left to memory.

Read article
Revenue Cycle
Revenue Cycle· 5 min read

Package Billing vs Open Billing, Explained

Two patients have the same operation on the same day by the same surgeon. One is billed a single fixed figure agreed in advance. The other is billed line by line - every investigation, every consumable, every day of the room. Both are legitimate. Which one you use changes what the patient expects, what the hospital collects, and how much argument happens at discharge. Package billing and open billing are two different contracts with the patient about how care becomes a bill, and confusing them is where revenue and goodwill both leak. ## The two models, plainly Open billing is the itemised approach. Every service the patient consumes is captured and charged at its tariff rate: consultations, investigations, procedures, drugs, consumables, room charges per day. The final bill is the sum of everything that actually happened. It is transparent and it is precise, and its total is not known until care is complete. Package billing is the fixed-price approach. A defined set of services is bundled into a single agreed price for a defined episode - a normal delivery, a cataract, a knee replacement. The patient knows the figure up front. The bundle specifies what is included, for how long, and under what conditions, and the hospital absorbs the ordinary variation within those bounds. - Open billing: pay for exactly what was used, totalled at the end - Package billing: pay a fixed price for a defined episode, known at the start - Open billing shifts variation onto the patient; package billing shifts it onto the hospital ## Where package billing earns its keep Packages exist because predictability has value to everyone. The patient gets a number they can plan around. The hospital gets a clean, fast-settling bill and a competitive offer for common, well-understood procedures. Insurers and TPAs like packages because they cap exposure and simplify approval. For high-volume, low-variance work, a package is usually the better instrument. The discipline a package demands is a clear definition of what is inside it. A package that is vague about inclusions is a dispute waiting to happen. The bundle has to state, precisely, the room category it assumes, the length of stay it covers, the procedures and investigations included, and what happens when reality exceeds the bundle. > A package is only as good as its list of what happens when the patient does not fit the package. That last part is where packages actually live or die. Real patients develop complications, need an extra day, or arrive with a comorbidity that changes the work. A workable package defines its boundaries: what is included, what triggers a move to itemised charging, and how the overage is handled. Kōami lets a package carry its inclusions, its room-category and stay assumptions, and its exclusion rules, so the point where a case leaves the package is defined rather than argued. ## Where open billing is the honest answer Open billing is right when the work is genuinely variable and cannot be predicted into a bundle. Complex medical admissions, long ICU stays, cases where the diagnosis itself is still moving - forcing these into a fixed package either overcharges the simple ones or bankrupts the hospital on the complex ones. Itemised billing charges for what actually happened, which is the fair answer when what happens is genuinely uncertain. ## Choosing the right instrument per case The two models are not rivals to pick between once and forever. A single hospital runs both, and often a single admission uses both: a package for the core procedure, open billing for what falls outside it. The important thing is that the choice is deliberate and visible, not an accident of which clerk raised the bill. - Use packages for high-volume, predictable episodes where a firm price serves everyone - Use open billing where clinical variation is real and a fixed price would misprice the case - Expect to combine them: a package core with itemised extras for what exceeds it - Make the tariff the common foundation, so both models price from the same rate card The common thread is the tariff. Both models ultimately reference the hospital's rate card - open billing charges each item at tariff, and a package is essentially a pre-agreed roll-up of tariff items at a negotiated total. When both are built on the same tariff, switching a case from package to open billing at the boundary is a controlled transition rather than a re-pricing exercise from scratch. ## Get the transition right and the rest follows Most billing disputes at discharge are not about the model. They are about the moment a case crossed from one model to the other and nobody told the patient. A package patient who quietly accrued three days of open charges because of a complication, and only discovers it at discharge, is an unhappy patient and a slow payment - even when every charge is legitimate. The fix is to make the boundary explicit and early. When a case exceeds its package - an extra day, an excluded procedure, a higher room category - that transition should be recognised when it happens, communicated to the patient, and reflected in the running estimate. The final bill then contains no surprises, because the patient watched it change in real time rather than meeting it at the counter. Package versus open billing is not a question of which is better. It is a question of matching the instrument to the case: fixed price where the work is predictable, itemised where it is not, and a clean, visible boundary between them when a single patient needs both. Build both on one tariff, define the package edges honestly, and handle the crossover in the open. Do that and the model serves the patient and the hospital instead of becoming the thing they fight about at discharge.

Read article
Revenue Cycle
Revenue Cycle· 5 min read

Pre-Auth and TPA Claims Without the Back-and-Forth

The patient is admitted, the surgery is booked, and now begins the other procedure - the one between the hospital and the insurer. Pre-authorisation requests go out, queries come back, documents get re-sent, and somewhere in that exchange a discharge gets delayed or a bill gets stuck. Anyone who has worked a hospital's insurance desk knows the real enemy is not rejection. It is the back-and-forth: the endless round trips of missing information, mismatched figures, and requests for one more document. Cut the round trips and you have solved most of the problem. ## What pre-auth is really asking for A TPA - Third Party Administrator - sits between the hospital and the insurer, processing cashless claims on the insurer's behalf. Before a planned admission or procedure, the hospital submits a pre-authorisation request: who the patient is, what is wrong with them, what treatment is planned, and what it is expected to cost. The TPA reviews it and, if satisfied, approves a sum for the cashless treatment. Every query in that process is really the TPA saying one of a few things. - We cannot match this patient to a valid policy - The clinical justification does not support the treatment claimed - The estimated cost does not line up with the tariff we expect - A document we need is missing or unreadable Each of those is preventable at source. The back-and-forth is not an inherent feature of insurance; it is the accumulated cost of sending incomplete or inconsistent requests and then answering questions one at a time. ## Get the request right the first time The single biggest lever is a first submission that is complete and internally consistent. A pre-auth that arrives with the correct policy details, a clear diagnosis, the planned procedure, and a cost estimate built from the actual tariff gives the TPA nothing to query. The round trips do not get faster; they stop happening. That means assembling the request from data the hospital already holds rather than re-typing it onto a form. The patient's demographics, the treating consultant, the diagnosis and planned procedure, and the estimate all exist in the system already. Pulling them together, rather than re-keying them, removes the transcription errors that trigger half the queries. > Most pre-auth queries are not clinical disagreements. They are the TPA asking you to confirm something you could have stated clearly the first time. Kōami assembles the pre-auth request from the patient's existing clinical and billing record and builds the cost estimate from the applicable tariff, so the figure the TPA sees is grounded in the hospital's own rate card rather than a guess that invites a query. ## The approximate bill is a negotiation, not a formality The cost estimate - the approximate bill - is where a lot of the friction concentrates. Submit a number that is too low and you will be topping up authorisation mid-stay, one enhancement request at a time. Submit one that is disconnected from your tariff and the TPA queries it. Build it properly and it holds. An approximate bill worth submitting is itemised against the tariff that will actually be charged: room category, procedure, likely consumables, investigations. When it is derived from the same tariff that will generate the final bill, the estimate and the eventual claim are consistent by construction, which is exactly what keeps the final settlement clean. - Build the estimate from the tariff that will produce the final bill, not a separate guess - Itemise it so the TPA can see what each component covers - Account for the room category and package terms up front, since these drive approval limits - Raise enhancement requests early when the clinical picture changes, not at discharge When the approximate bill is anchored to the real tariff, the gap between what was authorised and what is finally claimed shrinks, and the shrinking of that gap is where disputed deductions live. ## Track the claim like the live thing it is A pre-auth is not fire-and-forget. It has a state - submitted, queried, approved, enhanced, and eventually the claim itself - and that state changes while a patient occupies a bed. The hospital that loses money is usually the one that lost track of where each request stood: a query that sat unanswered for two days, an approval that came in but never got attached to the file, a discharge cleared before final authorisation landed. ## Keeping every claim in view until it settles Visibility is the fix. Every pre-auth and every claim should have a clear current status and a clear owner, so nothing sits in a silent queue. When a query comes back, the person who can answer it should know immediately, and the answer should go out with the supporting document attached rather than promised. - Show the live status of every pre-auth and claim in one place, not scattered across inboxes - Flag queries the moment they arrive so response time is measured in hours, not days - Keep the clinical documents linked to the request, ready to send without a hunt - Reconcile the approved amount against the final bill before discharge, not after Kōami keeps each pre-auth and claim as a tracked item with a visible status against the patient's stay, so the insurance desk works from a live picture rather than reconstructing where things stand from a pile of emails. The insurance process will never be frictionless; there is a genuine reviewer on the other side doing a real job. But most of the pain is self-inflicted, manufactured by incomplete first submissions and lost track of afterwards. Send a complete, tariff-grounded request, anchor the approximate bill to the real rate card, and keep every claim visible until it settles. Do that and the back-and-forth mostly disappears, which means the discharge happens on time and the money arrives without a fight.

Read article
Pharmacy
Pharmacy· 5 min read

Ward Indents That Reconcile Themselves

The ward runs out of something at 3 in the morning. The nurse raises an indent to pharmacy. Stock moves up, gets used, and somewhere in the handover the paperwork and the reality quietly part ways. By month end the ward's consumption on paper does not match what actually went into patients, the pharmacy's issue records do not match what the ward thinks it received, and someone spends a day reconciling two versions of the same truth. The ward indent is one of the most repeated transactions in a hospital, and it is where stock accuracy most often goes to die. ## What a ward indent is actually doing An indent is a request from a ward or department to the central pharmacy or store for stock to replenish its own working supply. It is an internal transfer, not a sale and not a dispense against a prescription. The ward holds a small stock of common items - fluids, analgesics, dressings, emergency drugs - and tops it up as it gets used. That sounds simple, and the single indent is. The problem is the chain of events each indent sets off, and how many places it can break. - The ward requests a quantity of each item - The pharmacy reviews, may adjust, and issues stock against the request - Stock physically moves and the ward's on-hand should increase - Consumption at the ward should eventually draw that stock back down Every one of those steps is a chance for the paper trail and the physical stock to disagree. Request more than issued. Issued more than received. Received but never booked into ward stock. Consumed but never recorded. Each gap is small; together they are why ward-level stock figures are so often fiction. ## Make issue and receipt two ends of one transaction The classic failure is treating the pharmacy's issue and the ward's receipt as separate records that happen to be about the same event. Pharmacy writes down what it sent. The ward, maybe, writes down what it got. Nothing forces the two to be the same number, so they drift. The fix is structural: the indent is one transaction with two ends, not two transactions that need reconciling. When pharmacy issues against an indent, that issue is the same record the ward receives against. The quantity issued and the quantity received are the same field, moving stock out of one location and into another in a single booked movement. There is nothing to reconcile because there was only ever one number. > Two records of the same transfer will disagree. One record with two ends cannot. Kōami models the ward indent as a single stock movement between locations, so an issue from pharmacy is a receipt at the ward by construction, and the two can never quietly diverge. ## Reconcile by design, not by effort "Reconcile themselves" is not a slogan; it is a description of what happens when the data is modelled correctly. Reconciliation is the labour of making two records agree. If there is one record, the labour disappears. The month-end exercise stops being detective work and becomes a report you read. That holds only if a few things are true throughout. Stock has to move at the moment of the transaction, not be reconstructed later. The item, quantity, and batch have to be captured once and carried through, not re-entered at each step. And the ward's on-hand has to be a live consequence of issues in and consumption out, not a periodically guessed figure. - Book the movement when it happens, so records never trail reality - Carry item, quantity, and batch through the whole indent without re-keying - Drive ward on-hand from actual issues and actual consumption, continuously - Track batch and expiry across the transfer, so FEFO survives the move to the ward When those hold, the ward's stock position is always current and always ties to pharmacy's issue records, because they are the same underlying data seen from two locations. ## Close the loop with consumption An indent that only tracks stock in is half a system. The other half is consumption - what the ward actually used. Without it, ward stock looks permanently overstated, because everything issued appears to still be sitting there. Linking administration and consumption back to ward stock is what makes the on-hand figure mean something. When consumption draws down ward stock as it happens, replenishment becomes rational. The indent quantity can be driven by real usage rather than a nurse's guess and a fear of running short at 3 in the morning. Over-indenting - the habit that fills ward cupboards with slow-moving stock that then expires - fades, because the system can see what the ward genuinely turns over. ## What ward indents that reconcile themselves buy you - Ward on-hand reflects issues in minus consumption out, kept current - Replenishment quantities are informed by real turnover, not habit - Expiry risk at the ward is visible, because batch and expiry followed the stock - Month-end becomes a report, not a reconciliation project The ward indent will never be interesting. It is plumbing. But it is plumbing that runs constantly and leaks quietly, and the cumulative cost of those leaks - inaccurate stock, wasted reconciliation time, expired ward cupboards - is large precisely because the transaction is so ordinary. Model it as a single movement with two ends, drive on-hand from real issues and real consumption, and the indent stops needing to be reconciled at all. It reconciles itself, which is the only version of this that survives contact with a busy ward.

Read article
Pharmacy
Pharmacy· 5 min read

Keeping the NDPS Register Audit-Ready

There is a particular kind of quiet in a hospital pharmacy when the drug inspector is due and someone remembers the narcotics register has not been reconciled in a fortnight. Controlled substances carry a weight that ordinary stock does not. The rules under the NDPS framework are strict, the penalties are personal, and the register is the document that stands between a compliant pharmacy and a very bad afternoon. Keeping it audit-ready is not a periodic scramble. It is a discipline that either lives in your daily workflow or does not exist at all. ## Why the narcotics register is different Ordinary stock tolerates a bit of slack. A few units of paracetamol unaccounted for is a variance to investigate, not a legal problem. Narcotic and psychotropic substances - the scheduled drugs governed by NDPS - tolerate nothing. Every unit received, dispensed, administered, wasted, or returned has to be accounted for, in sequence, with a running balance that always ties out. The register is a continuous ledger, not a snapshot. It records each transaction against a drug, with the quantity, the date, the source or destination, the person responsible, and the balance remaining after the movement. The defining property is that the balance is never allowed to drift. Physical count and register balance must agree, every time, for every scheduled drug. - Every movement recorded, in order, with no gaps in the sequence - A running balance that reconciles to physical stock on demand - The responsible person named for each transaction - Nothing edited away silently after the fact ## Capture the entry where the movement happens The register fails when it is maintained separately from the actual work - a paper book updated at the end of the shift from memory and scraps of paper. Every gap between the movement and the record is a chance for the two to diverge, and divergence in a narcotics register is exactly what an inspection is looking for. The fix is to make the register entry a byproduct of the transaction itself. When a scheduled drug is received, dispensed to a ward, administered to a patient, or wasted, the register entry is created at that moment, from that action, with the balance recalculated automatically. No parallel book, no end-of-day reconstruction, no arithmetic done by hand under time pressure. > A narcotics balance you calculate by hand at closing is a balance you will eventually get wrong. Kōami records controlled-substance movements as they happen and maintains the running balance continuously, so the register is a live reflection of stock rather than a document someone has to rebuild before an audit. ## Two-person control and the trail it leaves Controlled drugs conventionally demand more than one set of hands. Witnessed administration, witnessed wastage, dual-signature receipts - the point is that no single person can move a scheduled substance without a second person attesting to it. This is as much protection for the staff as it is control over the stock; a clean witnessed trail is what clears a nurse or pharmacist when a count comes up short somewhere else. The register should carry that structure, not sit beside it. Where a movement requires a witness, the record should capture both people. Where wastage occurs - a partial ampoule, a discontinued dose - it should be recorded as its own witnessed event, not quietly absorbed into a balance. - Capture both the responsible person and the witness on movements that require it - Record wastage as an explicit, witnessed transaction with a reason - Keep amendments as visible corrections with their own trail, never as overwrites - Tie each entry to the specific batch it moved, so recalls and discrepancies trace cleanly The test of a good register is not that it never contains a correction. Corrections happen. The test is that every correction is visible, attributed, and explained, so an auditor reads a story rather than finding a hole. ## Ready on demand, not after a scramble Audit-ready is a state, not an event. A register that is genuinely continuous is ready at any moment, because there is no backlog to clear and no reconciliation to perform before someone can look at it. That is the whole objective: to remove the pre-inspection panic by making the register correct all the time instead of correct just before it is examined. That readiness rests on a few plain properties. The balance ties to physical stock now, not after an afternoon of catch-up. The sequence is unbroken. Every entry names its person. Every discrepancy that ever arose has a recorded investigation and resolution attached, so there are no unexplained gaps waiting to be discovered. When the register can be produced and reconciled on request, an inspection becomes a review of good records rather than a test of how fast you can assemble them. - A balance that reconciles to physical count without preparation - An unbroken transaction sequence with no missing entries - Every discrepancy logged, investigated, and closed on the record - The whole ledger retrievable on demand, for any drug and any period Controlled substances are the part of pharmacy where process discipline and legal exposure sit closest together. The register is where that discipline is proven. Build it into the daily flow of receiving, dispensing, administering, and wasting - captured at the moment of movement, witnessed where it must be, corrected in the open - and audit-readiness stops being a thing you prepare for. It becomes the ordinary condition of the register, which is exactly where you want it.

Read article
Pharmacy
Pharmacy· 5 min read

FEFO: Stop Letting Drugs Expire on the Shelf

Walk into most hospital pharmacy stores and you will eventually find it: a strip of something in a back row, three months past expiry, still on the shelf because nobody picked it up in time. It is not theft and it is not fraud. It is just stock that sat while newer stock in front of it got dispensed first. Expiry losses are quiet, they are constant, and they are almost entirely a process problem. FEFO - First Expiry, First Out - is the process that fixes it, if the software actually enforces it. ## FEFO is not FIFO, and the difference is money FIFO - First In, First Out - moves the oldest received stock first. That is fine for a warehouse of tinned food. It is wrong for medicines, because the date that matters is not when you received a batch but when it expires. A batch received later can easily expire sooner, depending on how much shelf life the supplier shipped you. FEFO orders dispensing by expiry date, not receipt date. The batch that expires soonest goes out first, regardless of when it arrived. In a pharmacy carrying dozens of batches of the same molecule, all with different expiry dates, this is the only rule that consistently drains stock before it dies on the shelf. - FIFO asks: which batch did we receive first? - FEFO asks: which batch expires first? - For drugs, only the second question protects against write-offs ## Batch and expiry have to be real data, not a label FEFO is impossible if the system does not know the expiry date of the exact stock in hand. That means every unit has to be tracked at batch level, with its expiry captured the moment it enters the building. The Goods Receipt Note (GRN) is where this discipline starts. When stock is received against a purchase order, each batch number and its expiry date get recorded as the stock is booked in - not estimated, not left blank, captured off the pack. > If the expiry date was not captured at GRN, FEFO has nothing to sort by. Once batch and expiry live in the record, everything downstream can reason about them. Kōami tracks stock at batch and expiry level from GRN onward, so every dispensing decision and every stock count knows exactly which batch it is touching and exactly when that batch runs out. ## Let the system pick the batch The moment of truth is dispensing. A pharmacist filling an order should not have to scan the shelf, compare expiry dates in their head, and consciously choose the soonest-expiring batch. That is cognitive load that fails under pressure, and pressure is the default state of a hospital pharmacy. Instead, the system should suggest the FEFO batch automatically. When an item is dispensed, the software already knows which available batch expires first and proposes it. The pharmacist confirms rather than calculates. Override is still possible - a damaged strip, a batch on hold, a specific clinical reason - but the default action is the correct one. - Suggest the soonest-expiring available batch at the point of dispensing - Skip batches that are quarantined, recalled, or on hold - Allow a deliberate override with a reason, rather than silent free choice - Decrement the exact batch that was actually handed over, so stock stays accurate This is where FEFO stops being a poster on the store-room wall and becomes what actually happens, thousands of times a day, without anyone having to remember the rule. ## See expiry before it becomes a loss FEFO reduces expiry losses; it does not eliminate them. Some stock will approach expiry faster than it can be used - slow-moving items, over-ordered lines, a drug whose protocol changed. The answer is visibility early enough to act while the stock still has value. A near-expiry view that surfaces batches expiring in the next thirty, sixty, or ninety days turns a write-off into a decision. Stock coming up on expiry can be transferred to a higher-turnover location, returned to the supplier where terms allow, or simply flagged so ordering pauses until it clears. The earlier the warning, the more options remain. - Flag batches entering their final ninety days while there is still time to move them - Highlight slow movers whose on-hand quantity will outlast their expiry - Block, or at least warn on, dispensing of already-expired stock so it cannot slip out - Feed expiry risk back into purchasing so you stop reordering what you are about to bin Kōami surfaces near-expiry batches ahead of time and keeps expired stock out of the dispensing flow, so the pharmacist sees the problem while it is still solvable rather than discovering it at the annual stock audit. There is a cultural shift that comes with this too. When expiry is visible early and the FEFO batch is chosen for you, the pharmacy stops treating write-offs as an unavoidable cost of doing business and starts treating them as a signal that something upstream needs attention - usually over-ordering or a protocol that quietly changed. A near-expiry list that keeps surfacing the same slow-moving molecule is telling you to buy less of it, not to keep binning it. Used that way, expiry data stops being a record of losses already taken and becomes a tool for preventing the next ones. Expiry losses feel inevitable because they are diffuse - a few strips here, a bottle there, spread across hundreds of lines and never large enough on any single day to trigger action. Add them up across a year and they are a real number on the budget. FEFO, enforced by software that knows every batch and every date, turns that slow leak off. Capture expiry at GRN, let the system pick the batch, and watch the near-expiry list so nothing sneaks up on you. The drugs get used before they expire, which is the entire reason you bought them.

Read article
Radiology
Radiology· 5 min read

Closing the Loop on Critical Results

A radiologist spots a large pulmonary embolism at 2 in the afternoon. The report is dictated, signed, and sitting in the system within twenty minutes. Good. Now the only question that matters: did the person who can act on it actually find out, and can you prove when? Critical results are not a reporting problem. They are a communication problem wearing a reporting costume, and the gap between "the report exists" and "the right clinician acknowledged it" is where patients get hurt. ## The report is not the message Signing a report puts a finding into the record. It does not put it in front of a human. The referring clinician might be in theatre, off shift, or simply not looking at that patient's chart in the next hour. For a routine finding, that latency is fine. For a critical one - a tension pneumothorax, an acute bleed, a misplaced line, a new mass with impending airway compromise - an hour of silence is a clinical event in its own right. This is why critical results need a channel of their own, separate from the ordinary flow of signed reports. The finding has to be pushed, not waited for, and the push has to land on a specific responsible person, not a shared inbox that everyone assumes someone else is watching. - A named recipient, not a role or a distribution list nobody owns - A defined severity, so a critical finding is visibly different from an urgent-but-not-emergent one - A time expectation attached to that severity - minutes for the emergent, hours for the urgent - A fallback path for when the first recipient does not respond ## Acknowledgment is the whole point A critical result that has been sent but not acknowledged is not closed. It is in flight. The loop closes only when the responsible clinician confirms they have seen it and understood what it means. That confirmation - the critical results acknowledgment - is the single most important artifact in the whole workflow, because it is the moment responsibility for the finding transfers from radiology to the treating team. > A finding you communicated but cannot prove you communicated is, in an incident review, a finding you did not communicate. Acknowledgment has to be an explicit, recorded action. Not "the report was available." Not "the phone rang." A person, a timestamp, and a confirmation that this specific finding was received. Kōami records the acknowledgment as a discrete event tied to the study, the finding, and the clinician who cleared it, so the loop has a defined and auditable close. ## Escalation is what makes it safe People miss messages. That is not a failure to design around by hoping harder; it is a certainty to build for. The strength of a critical results workflow is entirely in what happens when the first attempt does not land. An unacknowledged critical result must escalate on a clock. If the primary clinician has not acknowledged within the window their severity demands, the alert moves - to a covering colleague, to the on-call, to a supervisor, up a defined ladder until someone takes it. Silence can never be the resting state. The system should treat an unacknowledged emergent finding as an active problem that keeps demanding attention until a human resolves it. - Start a timer the moment the result is raised, scaled to its severity - Escalate automatically when the timer expires without acknowledgment - Follow a documented chain so the next recipient is never ambiguous - Keep escalating rather than giving up, because an unread emergent finding is not a state you can safely leave alone The reassuring version of this is boring by design: most critical results get acknowledged quickly and never escalate at all. The escalation ladder exists for the few that would otherwise fall through, which are precisely the ones that end up in a coroner's report. ## The trail you will be glad you kept Every critical result carries a second life as evidence. When something goes wrong and the case is reviewed, the questions are always the same. When was the finding made? When was it communicated? To whom? When did they acknowledge it? What happened in between? A workflow that captures each of those as it happens turns a frightening reconstruction into a simple read of the record. Kōami keeps the full timeline as a byproduct of doing the work: finding raised, notification sent, escalations fired, acknowledgment recorded, each with its actor and its timestamp. Nobody has to assemble it after the fact, because it was never scattered in the first place. The same data that keeps a live result from being forgotten is the data that answers the review board six months later. It is worth being honest about what should count as a critical result in the first place, because a workflow that fires on too much is a workflow people learn to ignore. If every mildly abnormal finding triggers the same urgent channel, the genuinely emergent ones drown in the noise, and acknowledgment becomes a reflex click rather than a considered one. The severity tiers exist precisely so that the emergent finding looks and behaves differently from the merely notable one. A department that defines its critical findings carefully, and reserves the escalating channel for them, keeps that channel meaningful. Alert fatigue is not a side issue here; it is the failure mode that quietly undoes the whole system. Closing the loop on critical results is unglamorous work. It is timers, recipients, and confirmation clicks, not clever imaging. But it is the part of radiology where the discipline of the process is directly the safety of the patient. Make the message its own channel, make acknowledgment explicit, make silence escalate, and keep the trail without anyone having to think about it. Do that, and the finding you caught in twenty minutes actually reaches the person who can act on it - which was the entire point of catching it.

Read article
Imaging
Imaging· 5 min read

Window/Level Presets That Match How You Read

Ask two radiologists to read the same chest CT and watch their hands. One drops to a lung window almost before the images finish loading. The other sits in soft tissue, scrolls, then flicks to bone when something on the ribs catches their eye. The pixels are identical. What differs is the window - the slice of the greyscale each reader chooses to see. Window/level is not a cosmetic setting. It is how you decide what to look at, and presets are how you stop deciding it manually forty times a day. ## What window and level really mean A CT stores far more shades of grey than a monitor can show or an eye can resolve. Each voxel carries a Hounsfield Unit (HU) value, running from around -1000 for air to +1000 and beyond for dense bone, with water sitting at zero. Your display can show maybe 256 shades. Window/level is the mapping between those two worlds. - Window width (WW) is the range of HU values spread across the available greys. A narrow window means high contrast over a small HU band; a wide window means lower contrast over a broad band. - Window level (WL), sometimes called window centre, is the HU value sitting in the middle of that range. A lung window might be WW 1500, WL -600, stretching contrast across the air-filled parenchyma. A soft-tissue window sits nearer WW 400, WL 40, where liver, spleen, and nodes separate cleanly. Bone runs wide, around WW 2000, WL 400. Same scan, three completely different images, because you moved the window. ## Presets are muscle memory, made explicit Experienced readers carry these numbers in their fingers. The value of a preset is that it takes that memory out of the individual's hands and makes it a shared, one-key action. Press a key, land on the exact WW/WL for the tissue you want, every time, on every study. The difference at volume is real. A body radiologist reading a busy list is switching windows constantly - lung, mediastinum, bone, sometimes a narrow window to chase a subtle bleed. Manual mouse-drag windowing on each switch is a small tax paid hundreds of times a shift. Presets collapse it to a keystroke. > The best window preset is the one your hand reaches for without your brain getting involved. Kōami ships sensible defaults for the common tissue windows and, more importantly, lets a reader save their own. Because the preset you actually use is rarely the textbook number - it is the number you nudged to two years ago and never changed. ## Match the preset to the read, not the textbook Standard windows are a starting point, not a rule. How you read shapes what your presets should be. - Stroke work wants a narrow window - something like WW 30 to 40 at WL 35 - to tease out the loss of grey-white differentiation that a routine brain window hides. - Liver lesion hunting benefits from a tighter window than a general abdomen preset, so low-contrast lesions stop blending into background parenchyma. - CT angiography reads want a window set for opacified vessels, not for the soft tissue around them. - Temporal bone and other fine osseous work wants a very wide, sharp window that a general bone preset will not match. The point is that a preset library should reflect the reading a department actually does. A stroke centre and a cancer centre reading the same anatomy still want different one-key windows because they are hunting for different things. ## Presets that follow the study, and the reader The frustrating part of most systems is that presets are dumb about context. You open a non-contrast head and the viewer starts you in a bone window; you open a chest and it starts in soft tissue when you wanted lung. Every mismatch is a manual correction. The fix is presets that key off the study. A modality and body-part combination should open at the window that read most wants, with the alternates one key away. Better still, the system should remember that this particular reader always flips a head CT to a narrow stroke window, and honour it, without overwriting the neighbour who reads it differently. - Bind presets to study type so the first image is already close to right - Keep the full ladder - lung, soft tissue, bone, brain - on adjacent keys for fast switching - Let individual readers save personal presets that travel with them across workstations - Preserve the raw HU data untouched, so windowing is always a display choice and never a permanent edit That last point is the one that gets forgotten. Windowing changes what you see, never what is stored. The full dynamic range is always there in the pixels, and any preset is just a lens you hold up to it. Kōami keeps the underlying data intact and treats every window as a view, so you can flick between them freely and measure HU values that mean exactly what they should. One more practical note: presets are worth revisiting, not setting once and forgetting. The mix of studies a department reads shifts over time, new protocols arrive, and a reader's own eye changes as they gain experience. A window that felt right two years ago may be a keystroke you now fight against. Treating the preset library as something you tune, rather than a fixed inheritance, keeps it matched to the reading actually being done rather than the reading someone did when the system was first configured. Window/level is one of the few tools in imaging that is both completely standard and deeply personal. The physics is fixed; the way you use it is yours. Good presets respect both - solid defaults grounded in the HU scale, and the freedom to bend them to the way you actually read.

Read article
Radiology
Radiology· 5 min read

From Dictation to Structured Reports

Every radiologist has a dictation style. Some read head to toe, some lead with the finding that matters and bury the rest, some circle back three times to the same lung nodule. Free-text dictation lets all of that happen, which is exactly the problem. The referring clinician on the other end does not want your narrative arc. They want to know whether the mass is there, how big it is, and what to do next. Structured reporting is the shift from telling a story to filling in a form that already knows what the reading physician needs. ## What structured reporting actually changes The honest version: structured reporting swaps a blank text box for a template with named fields. Instead of dictating a paragraph, you populate discrete elements - technique, comparison, findings by organ system, impression - each of which lives in its own slot. The output still reads like prose to the clinician, but underneath it is data. That distinction matters more than it sounds. When a lesion size lives in a labelled field rather than mid-sentence, it can be tracked across studies, pulled into a tumour board list, or flagged when it crosses a threshold. When a free-text line says "stable 8 mm nodule, previously 6 mm" the software sees a sentence. When a structured field says diameter equals 8, the software sees a number it can compare. - Fewer missing elements, because the template asks for laterality, size, and comparison every time - Consistent language across a department, so "probably benign" means the same thing from every reader - Findings that map cleanly to standardised systems like BI-RADS, LI-RADS, or Lung-RADS - Report data that can flow downstream instead of being re-keyed by hand ## DICOM SR and why the plumbing matters Underneath the readable report sits a machine-readable one. DICOM SR (Structured Reporting) is the standard that lets a report carry coded content - measurements, findings, and their relationships - as structured objects rather than a flat blob of text. A CT measurement made on the workstation can travel as an SR object and land in the report already populated, with the units and the anatomical site attached. RadReport-style templates give you the clinical scaffolding: a library of report layouts, organ by organ and study by study, that a department can adopt and adapt. Pair that library with SR as the transport, and the measurement you drew on the axial slice does not need to be dictated at all. It is captured where it was made and carried into the field where it belongs. > A number you typed twice is a number you will eventually type wrong. Kōami treats the report as structured data from the first click, so a diameter measured on the image and the diameter printed in the impression are the same value, not two copies that drift apart. ## Where speed comes from, and where it goes Radiologists resist structured reporting for one honest reason: naively done, it is slower. Clicking through twelve fields to say "unremarkable chest" is a worse experience than dictating one sentence. If a template forces the same clicks for a normal study and a complex oncology follow-up, it has failed. The fix is normal defaults and smart branching. A well-built template loads a fully normal report on open, so a clean study is a quick read and sign. You only touch the fields that deviate. Positive findings expand the relevant section; negative ones stay collapsed and pre-populated. The reader spends keystrokes where the pathology is, not where it is not. - Start every study from a normal baseline, not a blank page - Expand detail only for the organ systems with findings - Let voice still drive the workflow for readers who prefer to talk, mapping speech into the structured fields - Keep an escape hatch: a free-text zone for the genuinely unusual case that no template anticipated Done this way, the routine study gets faster and the complex study gets more complete. That is the trade you want. ## The impression is still yours Structure is for the findings. It should never flatten the impression. The impression is where a radiologist earns their keep - synthesis, judgement, the recommendation that ties three findings into one actionable sentence. A good structured system leaves that section as expressive as you need it while still letting you tag the critical result, the follow-up interval, or the recommended next study as discrete, trackable items. The goal is not to turn radiologists into data-entry clerks. It is to stop asking them to be the transport layer for information that software could carry perfectly well on its own. When the measurement, the laterality, and the follow-up date are all structured, the report becomes something the rest of the hospital can act on without a human re-reading and re-typing it. There is a quieter benefit that shows up over months rather than minutes. A department reporting into consistent structured fields accumulates data it can actually look at: how many studies carried a given finding, how often a recommendation was for a specific follow-up, where reporting language drifts between readers. None of that is available when every report is a unique paragraph. Structure is what turns a pile of reports into something a department can learn from without a research project. Structured reporting is not about constraining how you think. It is about capturing what you concluded in a form that survives the trip to the next clinician intact. Get the templates right, keep the impression free, and let the plumbing carry the numbers. The reading gets no harder, and everything downstream gets a great deal easier.

Read article
Imaging
Imaging· 5 min read

Streaming Slices Instead of Downloading Studies

There is a moment familiar to anyone who has waited on medical imaging: the study has been ordered, the images exist, and now everyone stands around while a viewer downloads a study that is hundreds of megabytes, sometimes more, before showing a single slice. The clinician wants one image. The system insists on delivering all of them first. That gap - between what the reader needs to see and what the old model forces them to fetch - is exactly what streaming imaging closes. Instead of downloading a study, you stream its slices, and the difference in experience is the difference between waiting and working. ## Why the Download Model Fails at Scale The download-then-view approach made sense when studies were small and networks were local. A plain radiograph is a modest file; fetching it whole costs nothing anyone notices. But imaging did not stay small. A modern CT or MRI produces hundreds or thousands of slices, and a study can run to a gigabyte. The download model scales badly against that reality in every direction that matters. - Time to first image grows with the size of the whole study, so the reader waits longest exactly when the study is largest and the stakes are often highest. - Bandwidth is spent moving data that may never be looked at, because a reader who needs to check one region does not need every slice at full fidelity. - The client has to hold the entire study in memory, which pushes the hardware requirement up and the portability down. The fundamental error is coupling the unit of transfer to the unit of storage. A study is how the images are stored. It is not how they are read. Kōami's imaging back end breaks that coupling deliberately, treating the study as something you draw from rather than something you must first swallow whole. ## What WADO-RS Actually Streams The mechanism is DICOMweb, the family of web-native standards for medical imaging, and specifically WADO-RS - Web Access to DICOM Objects, the RESTful retrieval part. Where the old WADO fetched whole objects, WADO-RS lets a viewer request imaging at the granularity it needs: a study, a series, a single instance, or the frames within a multi-frame instance, addressed by ordinary web requests. - The viewer can ask for one series, or one image, without pulling the rest of the study along with it. - Frame-level retrieval means a viewer can pull individual slices as the reader scrolls into them, rather than the whole stack up front. - Because it is REST over HTTP, it flows through the same web infrastructure everything else uses - caches, load balancers, ordinary firewalls - with no special protocol tunnel to maintain. > The insight of DICOMweb is small and powerful: address medical images the way the web addresses everything else, and imaging stops needing its own private plumbing. Kōami's viewer speaks WADO-RS to its back end so that the pictures arrive as the reader moves through them, at the resolution the moment calls for. ## Progressive Loading Is the Experience the Reader Feels Streaming is not only about fetching less; it is about ordering the fetch intelligently so the reader is productive within seconds. The techniques stack together, and their combined effect is a viewer that feels immediate even against a large study on an ordinary connection. - First image first: the viewer prioritises the slices the reader is looking at now, so an image appears in seconds while the rest of the series loads behind it. - Progressive resolution: a lower-resolution version can render immediately and sharpen as the full-fidelity data arrives, so there is always something on screen to orient by. - Predictive pre-fetch: as the reader scrolls in one direction, the viewer fetches ahead of them, so the next slices are already waiting by the time the reader reaches them. - Server-side heavy lifting: reconstruction and decompression can be handled by the back end where the client is modest, so a laptop is not asked to do a workstation's job. Kōami combines these so that opening a large study feels less like a download and more like turning to a page in a book that is already open. The reader never experiences the study's total size; they experience only the slices in front of them. ## What Streaming Gives You Beyond Speed The obvious win is that studies open faster, and that alone justifies the approach. But the architecture pays dividends past raw speed, in ways that shape how a whole imaging service can operate. - Reading over ordinary networks becomes practical, so a radiologist on a home connection or a clinician on hospital wifi is not gated by the need to pull gigabytes. - The central archive stays the single source of truth, because the viewer streams from it rather than making local copies scattered across devices that then have to be reconciled. - Modest client hardware suffices, which is what makes browser-based, install-free reading genuinely viable rather than technically possible but painfully slow. Streaming, in other words, is the enabling layer beneath portable, browser-first imaging. Kōami builds on it so that the lightness of the reading experience is backed by an architecture that keeps the data governed, current, and central. Streaming slices instead of downloading studies is one of those changes that sounds like a technical detail and turns out to reshape the daily experience of everyone who touches imaging. The reader stops waiting for data they will not look at. The network stops straining under transfers it does not need to carry. The archive stays authoritative while the images travel to wherever the reader happens to be. WADO-RS and DICOMweb are not exotic; they are imaging finally adopting the ordinary logic of the web. And the result the clinician feels is simply this: they open a study and the picture is there, which is all they ever wanted the system to do.

Read article
Radiology
Radiology· 5 min read

Why the Browser Is Enough for Reading Studies

For most of the history of medical imaging, reading a study meant sitting at a specific machine. The radiology workstation was a heavy box under a desk, loaded with proprietary software, tied to a licence, and physically located in the reading room. If you wanted to read a study, you went to the workstation. The idea that a radiologist might open a full diagnostic study in an ordinary web browser, on whatever screen happened to be in front of them, would once have sounded like a compromise. It is not a compromise anymore. It is, for a great deal of clinical work, simply the better way, and it is worth being precise about why. ## What the Browser Can Now Actually Do The old objection was capability. A browser, the reasoning went, cannot handle the pixel density, the window-level manipulation, the measurement tools, the multi-planar reconstruction that real reading demands. That objection has quietly expired. Modern browsers expose the graphics and compute primitives that image rendering needs, and open toolkits like Cornerstone have been built specifically to drive diagnostic-grade viewing inside them. A browser-based viewer today handles the operations a reading actually requires: - Window and level adjustment in real time, so a chest study can be swung from lung window to mediastinal window without a round trip to a server. - Measurement, annotation, and comparison, including linked scrolling between a current study and a prior for the same patient. - Multi-planar reconstruction and stack scrolling through hundreds of slices, driven by the client where the hardware allows. Kōami's PACS viewer is built on this foundation, using the browser as a genuine imaging surface rather than a thin window onto a screen-scraped session somewhere else. > The question stopped being whether a browser can render a study to diagnostic standard. It can. The question is why you would still tether a radiologist to one particular desk. ## Zero Install Changes Who Can Read, and Where The deepest advantage of a browser-first approach is not technical elegance. It is that it removes the workstation as a chokepoint. When reading requires no installation, no licence transfer, and no specific hardware, the pool of people who can read a study and the places they can read it from both expand dramatically. - A radiologist can open a study from home for an after-hours call without driving to the hospital, because the reading environment is a URL and a login, not a building. - A referring clinician on the ward can pull up the images alongside the report, so the conversation about a patient happens with the actual pictures in front of both people. - A second opinion from a specialist elsewhere becomes a link, not a burned disc couriered across a city. This is the quiet revolution. The technology of browser-based viewing is interesting; the consequence - that expertise is no longer trapped at a physical console - is what actually changes how a hospital or a network operates. Kōami is designed around this reach, treating the viewer as something you send to a person rather than a place you send a person to. ## The Server Does the Heavy Lifting A browser-first architecture does not mean a browser doing everything. The intelligence of the design is in the division of labour: the client renders and interacts, and the server handles the data, the storage, and the streaming so that the client is never asked to swallow a whole study at once. A modern imaging back end speaks DICOMweb, and its streaming member WADO-RS in particular, so that the viewer requests exactly the pixels it needs, when it needs them, rather than downloading a gigabyte before the first image appears. - The archive stays authoritative and central, so there is one source of truth for every study rather than copies scattered across workstations. - Pre-fetching and progressive loading mean the first image is on screen in seconds even for a large study, because the viewer streams rather than transfers. - Compute-heavy reconstruction can be done server-side where the client hardware is modest, so a reading on a laptop is not limited to what the laptop alone could render. Kōami pairs its browser viewer with a DICOMweb back end precisely so that the lightness of the client does not come at the cost of performance. The browser is enough on the front end because the server is doing the right work behind it. ## Being Honest About the Boundaries A responsible case for browser-first reading has to name its limits, because overselling it helps no one. The display still matters: a diagnostic read of fine detail depends on a calibrated, high-resolution monitor, and the browser does not change the physics of the screen it runs on. Colour and grayscale calibration remain the reading site's responsibility. And where AI assists the read - flagging a region, prioritising a worklist - it is decision-support that helps a clinician look in the right place, not an autonomous device that renders a diagnosis. The radiologist reads; the software assists. - A calibrated diagnostic display is still required for primary reading of subtle findings, regardless of the viewer's capability. - Any AI assistance in the viewer is there to support the clinician's judgement, not to replace it, and the reporting clinician remains responsible for the read. Kōami's viewer is built to serve that reality: powerful and portable, while leaving the diagnosis firmly with the person qualified to make it. The browser is enough to read studies not because someone lowered the standard, but because the tools rose to meet it. The rendering is genuine, the streaming keeps it fast, and the archive keeps it safe. What you gain in return is freedom from the physical workstation, and with it a reach that the old model could never offer - the radiologist at home, the clinician at the bedside, the specialist across the country, all looking at the same images through nothing more exotic than the browser already open in front of them. That is not a compromise. It is progress that happens to be convenient.

Read article
Analytics
Analytics· 5 min read

The Five Numbers a Center Head Checks First

A center head running a hospital or a diagnostic chain has access to hundreds of metrics and time to look at perhaps five. The dashboards built for them usually get this exactly backwards, presenting fifty tiles of equal weight in the hope that the important ones are in there somewhere. They are, and they are drowned. The skill in management information is not collecting more numbers; it is knowing which handful a leader should check before their first cup of tea, and making those numbers honest, current, and impossible to misread. Here are the five that consistently earn their place. ## One: Today's Revenue Against the Run Rate The first number is money, but not as a raw figure. A revenue total on its own tells you almost nothing, because you have no idea whether it is good until you compare it to something. What a center head actually needs is today's revenue against the pace required to hit the month's target, and against the same day last month and last year. - Revenue to date this month, against the target, so the leader knows if they are ahead or behind with enough of the month left to react. - The daily run rate, because a month that started strong and is fading looks fine on a cumulative chart and terrible on a daily one. - The mix - OPD, IPD, diagnostics, pharmacy - because a revenue number that is holding up on pharmacy while OPD collapses is a warning dressed as good news. Kōami presents revenue as pace-against-plan rather than a bare total, which is the difference between a number you glance at and a number you can act on. ## Two: Occupancy and Throughput The second number is utilisation, and which form it takes depends on the business. For an inpatient facility it is bed occupancy. For a diagnostic center it is throughput - studies per modality, tests per bench. The underlying question is the same: are the expensive assets being used, and where is the constraint. - Occupancy by ward or utilisation by modality, so an idle CT scanner or a full ICU is visible before anyone has to ask. - The trend, not just today's snapshot, because occupancy drifting down over two weeks is a commercial problem forming quietly. > A dashboard that shows today's occupancy but not last fortnight's trend tells a leader where they are and hides where they are going. Kōami ties utilisation to the trend so the center head sees direction, not just position. ## Three: The Cash Conversion Signal The third number is the one that separates a business that looks profitable from one that actually has cash: how fast billed revenue turns into collected money. A center can post strong revenue and still be starved of cash if claims are stuck in TPA queues and receivables are ageing. - Days in accounts receivable, trending, because a rising number here is cash quietly leaving the building. - The first-pass claim rate, since claims that bounce are revenue that has been earned but not collected, and every bounce lengthens the cash cycle. - The ageing bucket - what share of receivables is over ninety days - because old receivables are the ones most likely to become bad debt. Kōami surfaces the collection health alongside the revenue, so a leader never mistakes billing for banking. Revenue is a promise; collection is the fulfilment, and the gap between them is where businesses get into trouble. ## Four: The Quality Signal That Cannot Be Gamed Every leader needs one number that speaks for the patient, and it has to be one that resists being gamed by the people whose work it measures. Depending on the setting, that is average turnaround time for a lab, or average length of stay against expected for a hospital, or the wait time from registration to consultation for an OPD. - A service metric the patient actually feels - TAT, wait time, or length of stay - reported as a distribution rather than a flattering average. - Against a target, so the leader sees not just the value but whether it is acceptable, and whether it is drifting. The reason this belongs in the top five is that commercial numbers and quality numbers pull against each other, and a leader who watches only the money will optimise the business into a place patients quietly stop coming back to. Kōami keeps a patient-experience metric on the same board as the revenue, so the trade-off is visible and deliberate rather than accidental. ## Five: The Exception That Needs a Person The fifth item is not a metric at all; it is the exception list. The first four numbers tell a leader how the business is doing. The fifth tells them what needs a human decision today - the things that have crossed a threshold and are waiting for someone with authority. - Critical stockouts - the items that will run out within the lead time and threaten clinical care. - Escalations - the complaint, the denied high-value claim, the credit request that exceeds a manager's limit. - Anomalies - a revenue figure or a volume that has moved far enough from normal to warrant a look, flagged by the system rather than hunted for by the leader. Kōami surfaces these as an actionable exception queue, because the highest-value thing a leader can do in the morning is not admire a chart but resolve the two things that only they can resolve. The discipline of a good management dashboard is subtraction, not addition. Any competent system can show a center head five hundred numbers; the useful ones show five and make them trustworthy. Pace against plan, utilisation with its trend, the cash conversion signal, a quality metric that cannot be gamed, and the short list of exceptions that need a person. A leader who checks those five before the day begins knows where the business stands, where it is heading, and what only they can fix - and that is genuinely all the morning requires.

Read article
Revenue Cycle
Revenue Cycle· 5 min read

Raising First-Pass Claim Rates

There is a number buried in every hospital's revenue cycle that quietly determines how much of the money it earns it actually collects, and how much it spends chasing what it earned. It is the first-pass claim rate: the share of claims that get paid on the first submission, without a rejection, a query, or a resubmission. A hospital with a high first-pass rate has cash arriving predictably and a small back office. A hospital with a low one has a growing pile of rework, a lengthening collection cycle, and a finance team that spends its days re-doing work that should have been right the first time. ## Why Claims Fail, and Why It Is Rarely the Clinician When a claim comes back rejected, the instinct is to blame the payer. Sometimes that is fair. Far more often the rejection was earned, at the point of registration or coding or documentation, by an error that was entirely preventable. Understanding the taxonomy of failure is the whole game, because different failures need different fixes. - Eligibility failures - the patient's policy had lapsed, the treatment was not covered, the pre-authorisation was never obtained. These happen at the front desk, before any care is delivered. - Data failures - a mismatched name, a wrong policy number, a missing TPA reference. Trivial to prevent, expensive to chase, and responsible for a startling share of rejections. - Coding and documentation failures - a diagnosis that does not justify the procedure billed, a missing operative note, an unbundled charge. These originate in the clinical and coding workflow. The pattern to notice is that most first-pass failures are born long before the claim is submitted. By the time the claim file is being assembled, the error is already baked in. Kōami's revenue-cycle tooling pushes the checks upstream, to where the errors are actually created, rather than catching them at the end when it is too late to fix cheaply. > Every rupee of denied claim was already earned once. Collecting it a second time costs you a second time. ## Catch It at the Front Desk, Not the Back Office The cheapest denial to fix is the one that never happens, and the front desk is where you prevent most of them. A registration clerk who verifies eligibility while the patient is standing there can resolve a lapsed policy or a missing pre-authorisation in real time. The same problem discovered a month later, after discharge, becomes a phone call to a patient who has left, a query to a TPA, and a claim in limbo. - Verify eligibility at registration, so a coverage problem surfaces while it can still be discussed with the patient. - Validate the payer and TPA details against the scheme's rules at entry, so a wrong policy number is caught by the field, not by the rejection three weeks later. - Flag procedures that require pre-authorisation before they are performed, so the approval is obtained in advance rather than begged for in retrospect. Kōami runs these validations at the point of entry, turning the front desk into the first line of revenue-cycle defence. It is far cheaper to stop a bad claim from forming than to rescue it once formed. ## Scrub the Claim Before It Leaves Between the assembled claim and the payer's inbox there should sit a scrubbing layer - a set of rules that inspects every claim against known payer requirements and holds anything that would predictably be rejected. This is the difference between submitting claims and lobbing them hopefully at a payer. - Completeness checks, so a claim missing a mandatory field or document never gets submitted to be bounced. - Consistency checks, so the diagnosis, the procedure, and the charges tell one coherent story rather than three contradictory ones. - Payer-specific rules, because each TPA and scheme has its own quirks, and a rule engine remembers them all where a human reviewer cannot. The rules are not static. Every genuine rejection is a lesson, and a claim that failed for a reason the scrubber did not catch should teach the scrubber a new rule. A hospital that feeds its denials back into its scrubbing logic watches its first-pass rate climb quarter over quarter. Kōami is built to make that feedback loop explicit, so the rule set gets smarter from the hospital's own history. ## Work Denials as a System, Not a Chore No first-pass rate reaches a hundred percent, and pretending otherwise is how denials rot. Some claims will come back, and the discipline is to work them as a managed queue with ownership and analysis, not as a demoralising pile someone gets to when they can. - Categorise every denial by root cause, because the value of a denial is the lesson it carries about the failure that produced it. - Route denials to the function that owns the fix - eligibility issues to the front desk process, coding issues to the coders - so the same mistake stops recurring. - Track the denial rate by cause over time, so you can see whether the fixes are working and where the next biggest leak is. Kōami treats denials as data, surfacing the patterns so that a hospital fixes the process that generates a category of denials rather than endlessly reworking individual claims. Rework is a symptom; the process that caused it is the disease. Raising the first-pass rate is not a single project with an end date. It is a habit: catch errors where they are born, scrub every claim against what payers actually require, and treat every denial as a lesson rather than a nuisance. Each point of improvement is money that arrives sooner and a back office that shrinks instead of grows. In a sector where margins are thin and the work is hard, getting paid correctly the first time is one of the most humane efficiencies a hospital can build, because the alternative is spending clinical revenue on the administrative cost of collecting it.

Read article
Analytics
Analytics· 5 min read

Turnaround Time: The Metric That Runs a Lab

Ask a lab director what single number they would keep if they could keep only one, and a surprising share will say turnaround time. Not accuracy, which they take as non-negotiable, and not volume, which is a business input. Turnaround time, because TAT is the number that a clinician on the ward actually feels, the number that determines whether a result changes a decision or arrives too late to matter. A potassium result that is perfectly accurate and four hours late did not help the patient in front of the doctor. TAT is where the lab's quality meets the hospital's reality. ## Decide What You Are Actually Measuring The first argument in any TAT project is about definitions, and it is worth having properly because a metric everyone measures differently is a metric nobody can improve. "Turnaround time" can mean any of several intervals, and they behave completely differently. - Order-to-result - from the moment the clinician places the order to the moment the verified result is available. This is what the clinician experiences and arguably the only number that matters to them. - Collection-to-result - from sample draw to result, which excludes the delay in getting a phlebotomist to the patient. - Receipt-to-result - from the sample arriving in the lab to the verified result, which is the interval the lab actually controls. Each is legitimate, and a serious lab tracks more than one, because the gap between them is diagnostic. If order-to-result is terrible but receipt-to-result is excellent, your problem is in phlebotomy and transport, not in the lab. Kōami timestamps each of these transitions, so the total interval can be decomposed instead of argued about. > If you only measure receipt-to-result, you will optimise the one part of the journey the clinician never sees and wonder why they still complain. ## The Median Lies, the Tail Tells the Truth The second mistake is reporting TAT as an average. A mean is dragged around by outliers and hides the shape of the distribution, and the shape is the whole story. What a clinician remembers is not the average result; it is the one that took six hours when they needed it in one. So report percentiles. - The median tells you the typical experience, which is useful for capacity planning. - The 90th percentile tells you what a bad day looks like, and it is the number that generates the complaints. - The maximum, examined case by case, is where you find the sample that got lost on a trolley, the analyzer that went down, the result that failed verification and sat in a queue. Chasing the median down while ignoring the tail produces a lab that looks good on the dashboard and feels unreliable on the ward. The improvement work lives in the tail. Kōami reports TAT as a distribution with percentiles rather than a single reassuring average, because the average is the number that hides the problem. ## Break the Journey Into Steps You Can Fix A long TAT is never one delay; it is an accumulation of small ones, and you cannot fix what you cannot see. The path from order to result has distinct stages, and instrumenting each transition tells you where the time actually goes. - Pre-analytical: order placed, sample collected, sample transported, sample received and accessioned. In most labs this is where the largest and most fixable delays hide - a sample waiting for the next transport run, a mislabelled tube sent back for recollection. - Analytical: sample loaded, instrument run, result produced. This is usually the fastest and most stable stage, which is why labs that only look here run out of things to improve. - Post-analytical: result verified, critical values called, report released. A result that waits in an unattended verification queue is a post-analytical delay masquerading as a slow lab. When you can see that forty minutes of a ninety-minute TAT is transport, you stop buying faster analyzers and start fixing the transport schedule. Kōami's step-level timestamps make that decomposition visible, which is what turns a vague complaint into a specific fix. ## Make TAT a Live Signal, Not a Monthly Report A TAT report that arrives on the fifth of next month tells you about problems you can no longer do anything about. To actually run a lab, TAT has to be a live signal that lets a supervisor intervene while the sample is still in the building. - Flag samples that are approaching their TAT target while there is still time to expedite them, not after they have breached. - Segment targets by priority, because a STAT troponin and a routine lipid panel should never be held to the same clock. - Watch the queues in real time, so a verification backlog building at shift change is visible before it becomes an hour of delayed results. Kōami surfaces in-flight samples against their targets so a supervisor can act on the sample that is running late today, not read about it next month. That shift - from retrospective reporting to live management - is what makes TAT a metric that runs the lab rather than merely grades it. Turnaround time endures as the lab's master metric because it refuses to let the lab grade itself in isolation. It ties the bench to the bedside and insists that a result only counts when it arrives in time to be used. Measure it honestly, by the right interval and the right percentile, break the journey into steps you can actually change, and make it a live signal a supervisor can act on. Do that and TAT stops being a number you report and becomes the number that runs the place.

Read article
Predictive Analytics
Predictive Analytics· 5 min read

Forecasting Bed Occupancy 48 Hours Out

The bed manager's job is a forecasting job that nobody calls forecasting. Every afternoon someone in a hospital is trying to answer a question about tomorrow: will we have a bed for the elective admissions we promised, or are we about to spend the evening boarding patients in the emergency department corridor. They answer it with a whiteboard, a phone, and thirty years of instinct. Instinct is remarkable, and it is also unevenly distributed, unavailable at 3am, and impossible to hand over at a shift change. A 48-hour occupancy forecast is an attempt to write that instinct down. ## Occupancy Is Two Flows, Not One Number The mistake is to treat occupancy as a single figure - beds full, beds empty. It is really the balance of two independent flows, and forecasting each one separately is what makes the whole thing tractable. Admissions add to the ward. Discharges subtract from it. The occupancy in 48 hours is simply today's census plus the admissions you expect minus the discharges you expect, and the art is in estimating each side honestly. - Predictable admissions - the elective surgical list, scheduled transfers, booked procedures - which you largely know in advance and can read straight off the schedule. - Unpredictable admissions - emergency presentations that convert to inpatient - which are genuinely stochastic but follow strong day-of-week and seasonal patterns you can learn from history. - Expected discharges - which is where length-of-stay modelling does the heavy lifting, because a patient admitted three days ago for a condition with a typical stay of four days is probably leaving tomorrow. Kōami models these flows separately and recombines them, so a bed manager sees not just a predicted number but where that number comes from. ## Length of Stay Is the Engine If you can predict when patients will leave, you can predict occupancy, because the admissions side is comparatively easy. That makes length-of-stay estimation the engine of the whole forecast. A patient is not an average; a patient is a case with a diagnosis, an age, a set of comorbidities, and a procedure, and each of those shifts the expected discharge date. The useful output is not a single predicted day but a distribution, because certainty here is false comfort. A post-operative patient recovering normally has a tight, predictable stay. An elderly patient admitted with a chest infection and three comorbidities has a wide, uncertain one. A forecast that pretends both are equally knowable will mislead you exactly when it matters. So the model should express its own confidence, and the bed manager should see it. > Predicting the average patient's discharge is easy and nearly useless. The forecast earns its keep on the patients whose stay is uncertain, by being honest about that uncertainty. ## A Forecast You Cannot See Is a Forecast You Cannot Use A number in a report that nobody opens changes no decisions. The occupancy forecast has to arrive where the bed manager already looks, at the time they are already deciding, and in a form they can act on. That is a design problem as much as a modelling one. - Show occupancy by ward and by bed category, not just hospital-wide, because a full ICU and an empty general ward is not the same as a hospital that is half full. - Highlight the crossing points - the projected hour at which a ward exceeds a safe threshold - so the warning arrives before the crisis, not during it. - Make the levers visible. If the forecast says the surgical ward tips over tomorrow afternoon, the manager wants to know that pulling forward two discharges or delaying one elective case resolves it. Kōami presents the 48-hour view as an operational board rather than a static report, so the forecast is a thing people act on during the morning huddle instead of a file they read after the fact. ## The Forecast Has to Earn Trust, Then Keep It Every predictive system in a hospital faces the same adoption problem. The first time the forecast is confidently wrong, the staff who were sceptical feel vindicated, and rebuilding that trust is slow. So you plan for the forecast to be wrong sometimes and you design for it. - Compare predicted occupancy against what actually happened, every day, in the open, because a forecast whose accuracy nobody checks is just a rumour with a chart. - Degrade gracefully. When data is thin - a new ward, an unusual case mix - the forecast should widen its bands and say so, not project false precision. - Treat the model as decision-support that informs the bed manager's judgement, never as an autopilot that books and cancels admissions on its own. The human owns the decision; the forecast sharpens it. Kōami is built to sit alongside the bed manager rather than replace them, surfacing the projection and its track record so the team can calibrate how much weight to give it. A good 48-hour occupancy forecast does not eliminate the afternoon scramble on its own. What it does is move the conversation earlier and ground it in something more durable than one person's memory. Instead of discovering at 8pm that there is no bed, the team sees the pressure building at the morning huddle and has a full day to act - a discharge chased, an elective rescheduled, a transfer arranged. That head start, repeated every day, is the whole point. The forecast is not there to be clever. It is there to buy time.

Read article
Predictive Analytics
Predictive Analytics· 5 min read

Forecasting Hospital Supply Pipelines

A hospital pharmacy running out of a first-line antibiotic is not a spreadsheet problem. It is a clinician switching to a second choice, a patient staying an extra day, and a procurement officer making a panicked call to a distributor who now holds all the pricing power. Supply forecasting in a hospital is the discipline of making sure that call never has to happen. It is unglamorous, it is deeply operational, and it is where a surprising amount of money and clinical quality quietly leaks away when it is done by gut feel. ## Why Hospital Demand Refuses to Behave Retail demand forecasting has a comfortable assumption: sales are roughly stationary and seasonal in predictable ways. Hospital consumption breaks that assumption constantly. A single trauma admission can burn through a month of a particular suture size overnight. A dengue season triples IV fluid demand for six weeks and then vanishes. A new consultant joins and their preference for a specific implant reshapes an entire category. So the first honest step is to segment your items by how they actually behave, because one model will not fit all of them: - Steady movers - routine consumables like gloves and saline - where demand is high-volume and reasonably smooth, and simple statistical forecasting works well. - Lumpy movers - specialised implants, less-common drugs - where demand is intermittent and a naive average badly overstocks you. - Clinically critical items - emergency drugs, blood products - where the cost of a stockout is measured in patient harm, not rupees, and you deliberately hold more than pure math would suggest. Kōami's inventory analytics classify items into these behaviours from consumption history rather than treating the whole formulary as one undifferentiated list. ## The Reorder Point Is the Real Decision Most of the value in supply forecasting collapses into one number per item: the reorder point, the stock level at which you place a new order. Set it too low and you stock out during the lead time. Set it too high and you tie up cash and shelf space in inventory that expires. The reorder point is not a guess; it is a calculation with three honest inputs. - Average demand during the lead time - how much you expect to consume between placing an order and receiving it. - Lead-time variability - because a supplier who quotes seven days but sometimes takes twenty is the real risk. - Safety stock - the buffer sized to the demand variability and to how much you are willing to risk a stockout on that specific item. The mistake labs and pharmacies make is using a single flat lead time for every supplier. In reality lead times have tails, and it is the tail - the delayed shipment, the customs hold, the manufacturer backorder - that causes the stockout. Forecasting has to model the variability, not just the average. > A reorder point built on average lead time protects you on an average day. Stockouts do not happen on average days. ## Expiry Is the Forecast Nobody Runs Stockouts get all the attention because they are visible and embarrassing. Expiry is the quieter loss, and in a hospital pharmacy it can be larger. A batch of a slow-moving drug bought in bulk to get a discount, sitting untouched until it crosses its expiry date, is money that was spent and then thrown away. Good supply analytics forecast expiry risk with the same seriousness as stockout risk. This means watching two things together: - Days of cover - how long current stock will last at the forecast consumption rate - flagged against the batch expiry dates you already hold. - FEFO discipline - first-expiry-first-out - so that when stock does move, the batch nearest expiry leaves first, which no amount of forecasting achieves if the store issues from the front of the shelf. Kōami surfaces items where days-of-cover exceeds shelf life, which is the early warning that you are about to write off stock. Catching it a month out means you can slow ordering or redistribute; catching it on the expiry date means you can only dispose of it. ## Forecasts Are Proposals, Not Commands The failure mode of every automated ordering system is the same: it generates a suggestion, the suggestion is occasionally absurd, a human overrides it, and after a few absurd suggestions the humans stop trusting all of them. The way to keep a forecast useful is to treat its output as a proposal a procurement officer reviews, with the reasoning visible. - Show why the system suggests an order - the forecast, the current stock, the lead time, the safety buffer - so the officer can sanity-check it in seconds. - Let known events be entered as inputs. A planned surgical camp or a seasonal outbreak is information the officer has and the history does not. - Track forecast accuracy over time per item, so the items where the model is unreliable get more human attention and the items where it is dependable get less. Kōami is built around this review-and-approve loop rather than silent automation, because a hospital procurement decision carries consequences that justify a human in the path. Forecasting a supply pipeline well does not require exotic mathematics. It requires taking three ordinary questions seriously for every item that matters: how much will we use, how long and how reliably does resupply take, and what does it cost us to be wrong in each direction. Answer those with real data instead of habit, keep a competent human in the loop, and the panicked call to the distributor stops happening. That quiet absence of crisis is exactly what a good forecast is supposed to buy.

Read article
Interoperability
Interoperability· 5 min read

Wiring Analyzers into the LIS

Walk into any mid-sized diagnostic lab and you will find a technologist retyping results. The haematology analyzer prints a strip, someone reads the strip, and someone keys the numbers into the information system. It works, until it does not: a transposed digit on a potassium result, a sample ID typed one off, a critical value that sat on a printout for twenty minutes because nobody was standing at the machine. Analyzer interfacing exists to close that gap. Done well, the result leaves the instrument and lands in the LIS with no human hand in between. Done badly, it introduces new and stranger failures than the manual process it replaced. ## The Two Dialects Every Lab Speaks Most laboratory instruments talk in one of two dialects, and you will meet both. The older one is ASTM E1381/E1394, a serial protocol that predates the web and still runs the majority of installed analyzers. The newer one is HL7, usually version 2.x, carrying ORU result messages and ORM order messages. Plenty of instruments now speak HL7 over TCP; plenty of older ones only offer a nine-pin serial port and an ASTM frame. The interface engine's job is translation. It has to: - Read the instrument's native frames, whether that means listening on a serial line or accepting an HL7 message on a socket. - Map the instrument's test codes to your LIS test codes, because the analyzer calls it GLU and your LIS calls it Glucose-F. - Normalise units and reference ranges so a result means the same thing regardless of which of your three chemistry analyzers produced it. Kōami's LIS sits on an interface layer that speaks both dialects, so a lab can run a decade-old cell counter and a brand-new immunoassay analyzer side by side without maintaining two mental models. ## Unidirectional Is Simple, Bidirectional Is Worth It There are two levels of ambition. A unidirectional interface pushes results from the analyzer to the LIS. It is straightforward, it eliminates transcription, and for a low-volume bench it may be all you need. A bidirectional interface adds the return path: the LIS sends the worklist and the sample identity to the analyzer, so the instrument knows which tests to run on which tube before the technologist touches anything. Bidirectional is more work to commission, and it is worth it in any lab with real volume: - It removes the second transcription - the one where a technologist programs the analyzer by hand - which is where sample mix-ups are born. - It supports host query, where the analyzer scans a barcode, asks the LIS "what do I run on this tube," and gets an answer in real time. - It lets you add or cancel a test after the tube is loaded without walking back to the machine. > A unidirectional interface saves typing. A bidirectional interface changes who is responsible for getting the right test on the right tube - and hands that responsibility to software that does not get distracted. ## Nothing Auto-Verifies Until the Rules Say So The fear every lab director voices is the same: if results flow straight through, will a wrong number reach a clinician unchecked? The answer is that raw instrument output should never post automatically. Between the analyzer and the verified report sits a layer of rules, and that layer is where a good interface earns its keep. Auto-verification releases a result without human review only when it passes every gate you set: - Delta checks, which flag a result that has moved implausibly far from the patient's previous value for the same test. - Analytical range limits, which hold anything outside the instrument's reportable range for a technologist to look at. - Critical-value rules, which never auto-release. A potassium of 6.8 or a platelet count of 15 gets escalated to a human and, ideally, triggers a documented call to the ward. Everything that fails a rule lands in a review queue. Everything that passes flows through. The point is not to remove the technologist; it is to spend their attention on the ten results that need it instead of the four hundred that do not. Kōami lets a lab tune these rules per test and per analyzer, because a delta check that makes sense for creatinine is nonsense for a one-off tumour marker. ## Commissioning Is Where Interfaces Live or Die An interface that passed a vendor demo can still fail in production, and the reasons are mundane. A firmware update changes the frame format. Someone swaps the serial cable for one with a different pinout. The analyzer's clock drifts and results arrive stamped in the wrong order. The unglamorous work of commissioning and monitoring is what separates an interface that runs for years from one that quietly corrupts data. Treat it as an operational discipline: - Validate the mapping with real samples across the full analytic range before going live, not just the two control levels that happen to be loaded. - Reconcile counts daily at first - results produced by the analyzer versus results landed in the LIS - so a silent drop is caught in hours, not weeks. - Alarm on silence. An interface that stops sending is more dangerous than one that sends errors, because errors get noticed and silence does not. Kōami surfaces interface health as something a lab supervisor can watch, so a stalled connection raises a flag instead of a mystery. Analyzer interfacing is one of those investments whose payoff is measured in things that stop happening: the mistyped result, the delayed critical call, the sample run twice because nobody was sure the first run posted. It is not glamorous engineering. It is careful mapping, honest rules, and monitoring that assumes something will eventually break. Get that right and the lab gets faster and safer at the same time, which is a rare combination worth working for.

Read article
Interoperability
Interoperability· 5 min read

Connecting to ABDM/ABHA the Practical Way

Every hospital that has tried to connect to the Ayushman Bharat Digital Mission learns the same lesson in the first fortnight: the hard part is not the API. The specifications are published, the sandbox is reachable, and a competent developer can generate an ABHA number in an afternoon. The hard part is the plumbing between ABDM and the way your front desk, wards, and records room actually work. A registration clerk who is already juggling a queue of forty patients will not stop to explain consent artefacts. So the practical question is never "can we integrate" but "where do we put each step so nobody has to think about it." ## Start With ABHA Creation Where It Is Painless The ABHA (Ayushman Bharat Health Account) number is the anchor. It is a 14-digit identifier that ties a patient to their longitudinal record across facilities. The temptation is to make ABHA creation a separate counter or a separate screen. Resist it. Fold it into the registration flow you already have. In practice this means two paths, and you should build both: - Aadhaar-based creation, where the patient consents to an OTP and the demographic details flow back automatically. Fast, but depends on a working mobile number linked to Aadhaar. - Mobile-driven creation, for the large number of patients whose linked number is stale or belongs to a relative. This path is slower and needs manual demographic entry, so route it to a clerk who has thirty seconds to spare, not the peak-hour window. Kōami handles both from inside the same registration screen, so the clerk sees one extra field, not one extra system. If the patient already has an ABHA, verification replaces creation, and the flow is shorter still. > The measure of a good ABDM integration is that a busy clerk never has to leave the screen they were already on. ## Consent Is a Workflow, Not a Checkbox The single most misunderstood part of ABDM is consent. Data does not move because a hospital wants it to move. It moves because a patient granted a consent artefact that specifies exactly what, for how long, and to whom. A consent request carries a purpose code, a data range, a set of HI (health information) types, and an expiry. The patient approves it on their own app, and only then does the Health Information Exchange release the records. This has real consequences for how you design the screen. When a physician wants to pull a patient's prior discharge summary from another facility, the request has to be phrased in ABDM's terms and the patient has to act. If your workflow assumes instant access, it will feel broken. Build for the asynchronous reality: - Raise the consent request early, ideally at check-in, so the artefact is often approved by the time the patient reaches the consultation room. - Show the physician a clear state - requested, granted, denied, or expired - rather than a spinning loader that implies the data is on its way when it may never arrive. - Store the artefact reference against the encounter so an audit can reconstruct precisely why a record was accessible. Kōami keeps the consent state visible on the patient's timeline, which turns an invisible protocol into something the clinical team can reason about. ## Care Context Linking Is Where the Value Lives Creating an ABHA does very little on its own. The value appears when you link care contexts. A care context is a single episode of care - an OPD visit, an admission, a lab panel - registered against the patient's ABHA so that it becomes discoverable later. Skip this step and you have handed out identifiers that point to nothing. The discipline is to link a care context at the moment the episode becomes real: when the visit is confirmed, when the admission is booked, when the report is finalised. Do it in the background, triggered by events your system already emits. A discharge that is finalised in the HMIS should fire a care-context link without a human pressing anything. When you get this right, a patient who walks into a different hospital next year can, with their consent, surface the discharge summary your team wrote today. ## Design for the Network You Actually Have ABDM assumes connectivity that Indian hospitals do not always have. Registration desks lose their link mid-morning. Gateway calls time out. The Health Information Provider on the other side is offline for maintenance. If your integration treats every failure as fatal, your clerks will quietly stop using it, and then you have an expensive feature nobody touches. Build for graceful degradation: - Queue outbound linking and consent callbacks so a dropped connection retries automatically rather than losing the event. - Let ABHA creation fail soft: register the patient in the local record first, attach the ABHA when the network returns, and never block clinical care on a gateway response. - Log every gateway interaction with its correlation identifier so that when a call fails, someone can actually trace it instead of guessing. Kōami is designed to run this way, treating ABDM as an eventually-consistent partner rather than a synchronous dependency, which is the only assumption that survives contact with a real hospital network. Connecting to ABDM is less a coding exercise than an operations exercise. The specification tells you how to speak the protocol. It says nothing about where consent belongs in your queue, how a clerk creates an ABHA without slowing down, or what a physician sees when a record has not yet been released. Get those human details right and ABDM becomes quietly useful. Get them wrong and you have a compliant integration that everyone avoids. The practical way is to make the digital health account something your staff barely notice they are using.

Read article
Interoperability
Interoperability· 5 min read

Designing APIs Hospitals Can Actually Build On

Most healthcare software promises an API, and most of those APIs are a disappointment when a hospital's own team finally tries to build on them. The endpoints exist but the documentation lags the behaviour. Authentication is a bespoke scheme nobody else uses. There is no way to be notified when something changes, so integrations resort to polling every few minutes and hoping. The gap between "we have an API" and "you can actually build on our API" is enormous, and hospitals only discover which side of it a vendor sits on after they have signed. Designing APIs that hospitals can genuinely build on is a discipline, and it is worth being explicit about what it takes. ## The difference between an API and a platform Having endpoints is table stakes. Being buildable is a higher bar, and it is defined by whether an integrator who has never met your team can succeed from the documentation alone. That means a few things have to be true at once: - Predictable, resource-oriented REST, so once someone learns one endpoint they can guess the shape of the next. - Consistent authentication using an approach integrators already know, rather than a scheme invented in-house. - Clear versioning, so an upgrade on the vendor side does not silently break a hospital's working integration. - Honest, current documentation that matches what the API actually returns, including the error cases. > An API is only as good as the worst surprise it springs on the developer at 2 a.m. during a go-live. The test is simple and unforgiving: can a hospital's IT team, or a third-party integrator, build something real without a single support call? If the answer is no, it is not a platform. It is a set of endpoints with a marketing label. ## Stop polling, start listening The single biggest quality-of-life difference between a mediocre API and a good one is webhooks. Without them, any integration that needs to react to a change has to poll - ask "has anything happened yet?" over and over, most of the time to be told no. Polling is wasteful, it is slow, and it scales badly as the number of integrations grows. Webhooks invert the model. Instead of the hospital's system asking repeatedly, Kōami's platform calls the hospital's system the moment something relevant happens. The events that matter in a hospital map naturally onto this: - A patient is admitted, discharged or transferred, so the pharmacy or billing system reacts immediately to the ADT event. - A lab result is finalised, so an external portal updates without a five-minute delay. - An inventory item crosses its reorder threshold, so procurement is notified in real time. - A credential is approaching expiry, so an external compliance dashboard picks it up. Real-time delivery is not a luxury feature. In a hospital, the difference between "now" and "in five minutes" is sometimes the difference between a safe workflow and a dangerous one. ## Build webhooks that survive the real world Webhooks are easy to demo and hard to do well, because the real world is unreliable. The receiving system will occasionally be down, slow, or briefly unreachable, and a naive webhook simply loses the event. A serious implementation plans for failure: - Retries with backoff, so a momentary outage on the hospital's side does not drop the event permanently. - Signed payloads, so the receiver can verify the call genuinely came from Kōami and not from an impostor. - Idempotency keys, so a retried delivery does not cause the same admission to be processed twice. - A replay or catch-up mechanism, so a system that was down for an hour can recover the events it missed. Skip these and you have a webhook that works in the demo and fails in production. The unglamorous reliability engineering is exactly where "we support webhooks" becomes "you can depend on our webhooks." ## Design for least privilege An open API in healthcare is also an expanded surface for accessing sensitive data, and that has to be treated with respect rather than bolted-on caution. Buildable does not mean wide open. The right posture is granular scopes, so an integration that only needs to read inventory levels cannot reach patient records, and every credential is scoped to the least it needs to do its job. Access should be auditable, so a hospital can see which integration read what and when. This is a capability question, not a certification claim: the point is to give hospitals the controls to grant narrow, revocable, observable access rather than handing out keys to everything. ## Documentation is part of the product The last mile of a buildable API is the part vendors most often neglect: the documentation, the sandbox, and the examples. An integrator should be able to read the reference, try a call against a test environment that behaves like production, see a worked example for the common flows, and understand the error responses without reverse-engineering them. Kōami treats this material as part of the product rather than an afterthought, because an undocumented capability is, for practical purposes, a capability that does not exist. Hospitals are not asking for a magic integration that reads their minds. They are asking for the plumbing to connect the systems they already run - the LIS, the third-party portal, the analytics stack - without a services contract for every small change. That is what open, well-versioned REST APIs and reliable webhooks provide: the ability to build, to react in real time, and to do it safely with access scoped to exactly what each integration needs. The measure of success is quiet. A hospital's own team ships something useful, on their own, and never needs to call you to do it.

Read article
Interoperability
Interoperability· 5 min read

Breaking Down Data Silos in Healthcare

A patient arrives in the emergency department at midnight, unconscious, with a chronic condition managed at the same hospital's OPD for years. The registration clerk creates a fresh record because the ED system cannot see the OPD one. The lab results from last week sit in a database the ED clinician cannot reach. The old CT is in a PACS that speaks a different language. Somewhere in the building, every piece of information needed to treat this patient well already exists. It just cannot travel. This is the everyday cost of data silos, and it is paid in duplicated tests, delayed decisions and the small, dangerous gaps where important context falls through. ## How silos form without anyone deciding to build them No hospital sets out to fragment its own data. Silos accumulate one reasonable decision at a time: - The lab buys a best-of-breed LIS; the radiology department picks its own RIS and PACS. - The HMIS grows organically, with modules added by different vendors over a decade. - A new insurance-desk tool is bolted on because it was quick to deploy. - Each system has its own patient identifier, so the same person is three different IDs across three databases. Individually, every choice made sense. Collectively they produce a hospital where the UMR in one system does not resolve in another, and where "integration" means a staff member re-keying data from one screen into the next. The clerk becoming a human data bus is not a workflow; it is a symptom. ## What breaks when data cannot move The consequences are not abstract. They show up at the bedside and on the balance sheet: - Tests get repeated because the earlier result is invisible, wasting money and, for imaging, exposing patients to avoidable radiation. - ADT events - admission, discharge, transfer - do not propagate, so the pharmacy, the diet kitchen and the billing desk work from stale information. - Discharge summaries are assembled by hand from systems that will not talk, delaying beds and frustrating families. - Clinical decisions are made with partial information because pulling the full picture takes more time than anyone has at 2 a.m. > Every silo is a place where a clinician has to choose between spending time they do not have or deciding with less than they should. The deepest cost is the one nobody logs: the decision made without a piece of context that existed all along, one system away. ## The standards that let systems talk The good news is that healthcare interoperability is not an unsolved research problem. There are mature standards for exactly this, and the job is to use them properly rather than to invent something bespoke: - HL7 v2 remains the workhorse for ADT, orders and results messaging between hospital systems, and most existing kit already speaks it. - FHIR offers a modern, resource-oriented, REST-friendly model - Patient, Encounter, Observation, DiagnosticReport - that is far easier to build against. - DICOM and DICOMweb move imaging, so a study acquired on one modality can be viewed and shared without exporting a folder of files. The point of a standard is that it decouples systems. When the lab publishes results as FHIR Observations, any authorised system can consume them without a custom, brittle, point-to-point integration that breaks the next time either side upgrades. ## Identity is the hard part The unglamorous truth is that most interoperability failures are really identity failures. If system A calls the patient UMR-4471 and system B calls the same human PT-88213, no amount of HL7 will reliably stitch them together. Before messages can flow meaningfully, a hospital needs a way to resolve one patient to one identity across every system that touches them. The Kōami approach treats the patient identity as the anchor the modules share, so that an OPD encounter, an IPD admission, a lab result and an imaging study all hang off the same person rather than off four disconnected records that happen to describe the same body. Get identity right and the messaging standards do their job. Get it wrong and even perfect FHIR produces confidently linked nonsense. ## Connected by design, not by adapter The distinction that matters when evaluating clinical software is whether interoperability was designed in or bolted on. A suite where the HMIS, the inventory, the imaging and the HRMS were built to share identity and to exchange data through standard interfaces behaves differently from a collection of products stitched together with adapters after the fact. In the Kōami ecosystem the modules are meant to speak to each other natively - an admission is visible where it needs to be, an imaging study is reachable over DICOMweb by the clinician who needs it - while open, standards-based interfaces let the hospital's other systems join the conversation rather than being walled out. None of this requires a hospital to rip everything out and start again, which is rarely realistic. It requires choosing systems that speak the common languages - HL7, FHIR, DICOMweb, plain REST - and that anchor on a shared patient identity. Breaking down silos is less a single project than a standing principle: every new system earns its place partly by how well it lets data move. The patient in the ED at midnight does not care about your architecture. They only benefit from the fact that, this time, everything the hospital already knew about them was actually there when it counted.

Read article
Workforce Operations
Workforce Operations· 5 min read

Reading Attrition Before the Resignation Letter

By the time a resignation letter lands on a manager's desk, the decision is usually weeks or months old. The nurse mentally left a while ago; the letter is just the paperwork catching up. This is the uncomfortable truth about attrition in hospitals: the moment you learn about it is the moment it is already too late to do much. Yet the departure was rarely silent. The signals were there in the roster, the attendance record and the overtime ledger, scattered across systems that were never asked to notice them. Reading attrition early is not about predicting individuals with spooky precision. It is about paying attention to patterns you already have the data to see. ## Why hospital attrition hurts more Losing a nurse is not like losing a generic employee. The cost compounds in ways that are specific to clinical work: - Recruitment and onboarding for a specialised role - ICU, dialysis, OT - takes months, not weeks. - The remaining team absorbs the gap, which raises their workload and their own attrition risk. - Institutional knowledge walks out: the nurse who knew the ward's rhythms, the difficult families, the quirks of the equipment. - Agency and overtime spend rises to plug the hole, so the departure costs money long before the replacement arrives. Because the cost is so high and the replacement so slow, even a few weeks of early warning is worth a great deal. It is the difference between a managed transition and a scramble. ## The signals are already in your systems The data that predicts disengagement is not exotic. It is the operational exhaust a hospital already generates every day, sitting in the HRMS and the roster. The problem is that no single screen puts it together. Some of the more reliable signals: - A sustained rise in unplanned leave or late check-ins from someone previously reliable. - Overtime that has been climbing for months, a sign of a person being quietly overloaded. - A drop in shift-swap participation, or a pattern of always offloading shifts and never picking any up. - Repeatedly being rostered into the unpopular slots that others avoid. - Leave balances hoarded and untaken, then a sudden burst of usage. > Attrition rarely announces itself. It leaks, one changed habit at a time, through data you are already collecting. None of these is proof on its own. A nurse taking more leave might simply have a sick parent. But a cluster of these shifts, moving together over a quarter, is a pattern worth a conversation. ## Patterns, not verdicts It is worth being clear about what this kind of analysis should and should not do. The aim is not to hand a manager a ranked list of "flight risks" and invite them to treat people as suspects. That is both ethically corrosive and operationally counterproductive; staff who sense they are being scored will disengage faster, not slower. The aim is to surface changes in pattern that prompt a human check-in. In the Kōami HRMS, the useful framing is a shift in a person's own baseline rather than a comparison against colleagues. Someone whose overtime has doubled and whose swap participation has fallen is not a data point to be flagged and filed. They are a colleague who may be quietly burning out, and the right response is a manager asking how they are doing - not a spreadsheet deciding their fate. The technology's job is to make sure that conversation happens before the letter, not after. Framing the signal as a change in someone's own pattern also protects against the unfairness of comparing very different people. A nurse who has always worked a lot of overtime is not the story; a nurse whose overtime has suddenly climbed is. Watching each person against their own history keeps the focus on what changed rather than on who happens to look busy, and that distinction is what makes the resulting conversation feel supportive instead of accusatory. ## Fix the causes the data reveals Early signals are only useful if they lead somewhere. Often the same data that flags an individual also reveals a structural problem worth fixing: - If overtime is concentrated on a few names, the roster is leaning on your best people until they break. - If certain units generate most of the unpopular-shift complaints, the differential or the rota design needs attention. - If leave is chronically unusable because cover never exists, the staffing model is the problem, not the person. - If swap participation is collapsing across a team, morale is sliding for reasons no individual conversation will fix. Treating attrition signals purely as an individual matter misses the point. Frequently the data is telling you something about how the ward is run, and the highest-leverage response is to change the system rather than to counsel one nurse. ## Turn the signal into a habit For this to work it cannot be a heroic quarterly analysis that one motivated manager runs and then abandons. It has to become routine: a regular look at the trends, a low-key check-in when a baseline shifts, and a willingness to act on what the aggregate patterns say about the roster itself. The hospitals that retain nurses are not the ones with the cleverest prediction model. They are the ones that notice a good nurse being quietly ground down and do something while there is still time. Retention is won in the weeks before the resignation, not in the counter-offer after it. The data to see it coming is already flowing through your rosters and attendance logs. The only question is whether anyone is reading it in time - and whether, when the pattern shows up, the response is a genuine conversation and a fairer roster rather than a flag in a file.

Read article
Workforce Operations
Workforce Operations· 5 min read

Never Staff an Expired Licence Again

There is a particular kind of quiet risk in a hospital that never shows up until an auditor or a lawyer goes looking for it: the staff member on duty whose licence, registration or mandatory training lapsed weeks ago, and whom the roster kept assigning because nobody was watching the dates. Nothing looks wrong on the day. The nurse is competent, the shift is covered, the ward runs. The problem is entirely on paper - until the paper is what matters, in an accreditation review, an insurance query, or an adverse event investigation. Credential expiry is one of the most preventable risks in healthcare operations, and one of the most commonly ignored. ## The credentials that actually lapse "Credential" is a broad word, and the things that expire are more numerous than most rosters track. In a typical hospital the list runs long: - Nursing council registration and its periodic renewal. - Medical registration for clinicians. - BLS, ACLS and other life-support certifications with fixed validity windows. - Radiation safety badges and training for staff working near imaging. - Fire safety, infection control and other mandatory annual trainings. - Role-specific competencies that a unit requires before it will accept a nurse onto its rota. Each of these has an issue date and an expiry date, and each one is somebody's responsibility to renew. In practice that responsibility is scattered across the individual, the HR file, and a supervisor's memory, which is to say it is nobody's reliable job. ## Why the spreadsheet always loses The default tool for tracking credentials is a spreadsheet with a column of expiry dates, and it fails in the same way every time. Somebody has to remember to open it, sort it, and act on it before a date passes. That person goes on leave, gets busy during an NABH cycle, or simply trusts that the last update is still current. The spreadsheet does not raise its hand. It waits to be asked, and by the time someone asks, the expiry has already happened and staff have already worked shifts they were not, on paper, cleared to work. > A credential register that does not warn you is just a record of when you found out too late. The failure is structural, not personal. Any control that depends on a human remembering to check a static list will eventually fail on the day that human is distracted. The fix is to make the credential data active rather than passive. ## Make the credential block the assignment The decisive move is to connect the credential record to the roster itself, so that expiry is not merely reported but enforced. In the Kōami HRMS, each staff member's credentials are held as structured records with expiry dates, and those dates participate in scheduling decisions. That changes the question from "did anyone notice?" to "can this person even be assigned?" Concretely, the system can: - Warn well ahead of expiry - 60, 30 and 7 days out - to the individual, their supervisor and HR, so renewal happens before the deadline, not after. - Flag a scheduled shift where the credential will lapse before the shift is worked. - Prevent, by policy, the assignment of a nurse to a unit whose required competency she does not currently hold. - Surface a live dashboard of who is expiring when, by department, so managers see the wave coming. The graduated warnings matter. A single alert on the expiry date is useless; a renewal often takes weeks to arrange. Nudging at 60 days gives people time to actually do something, and enforcing the block at the roster level means that even if every reminder is ignored, an expired credential still cannot quietly end up on a duty list. It is worth stressing how different this is from the reporting model most hospitals rely on. A report tells you, after the fact, that something went wrong. An enforced rule stops the wrong thing from happening in the first place. The credential register moves from being an archive you consult during an audit to being an active guardrail that shapes today's roster. ## Design the reminders so people act An alert that everyone ignores is worse than no alert, because it trains people to dismiss the system. Credential reminders earn attention when they are specific, escalating and owned: - Specific: name the credential, the person, the exact expiry date and what renewal requires. - Escalating: if the 60-day nudge is ignored, the 30-day and 7-day reminders widen to include the supervisor and then HR. - Owned: every credential has a clear responsible person, so a reminder lands somewhere accountable rather than in a shared inbox nobody reads. Get this right and renewals stop being fire drills. The unit knows in advance that three nurses need ACLS refreshers next quarter and can schedule the training without pulling the ward apart at the last minute. ## From risk register to routine The payoff is not only avoiding a bad audit finding, though that alone justifies the effort. It is that credential management stops being a periodic panic and becomes a quiet routine. When the roster itself refuses to staff an expired licence, the worst outcome is designed out rather than watched for. Accreditation reviews become a matter of exporting a clean report rather than scrambling to plug gaps in the fortnight before the assessors arrive. No hospital sets out to staff an expired credential. It happens because the information sits in a passive list while the roster carries on regardless. Close that gap - let the expiry date reach into the scheduling decision - and the problem largely solves itself. The nurse gets renewed on time, the ward stays properly covered, and the paper tells the same true story as the practice. That alignment, boring as it sounds, is what good clinical governance actually looks like day to day.

Read article
Workforce Operations
Workforce Operations· 5 min read

Getting PF, ESI, PT and TDS Right, Every Month

Payroll in an Indian hospital is not one calculation. It is a stack of them, each with its own rules, thresholds and filing calendar, sitting on top of attendance data that is often messy to begin with. Provident Fund, Employee State Insurance, Professional Tax and Tax Deducted at Source each answer to a different authority, and each one is unforgiving about deadlines. Get them right and nobody notices, which is the whole point. Get them wrong and you are looking at interest, penalties, and a queue of staff outside the HR office asking why their take-home dropped. Getting statutory payroll right every month is less about cleverness and more about discipline built into the system. ## Four deductions, four different rulebooks The reason payroll feels harder than it should is that these four components do not share a logic. Treating them as one lump is exactly how mistakes creep in. - PF applies on a defined wage base with employer and employee contributions, and the base itself is a source of endless confusion when allowances enter the picture. - ESI applies to employees below a wage threshold, which means a mid-year increment can push someone out of coverage - but only from the correct contribution period, not the day the raise lands. - PT is a state subject, so a hospital with units in more than one state is running different slabs and different due dates in parallel. - TDS on salary depends on the employee's declared regime, investment proofs and projected annual income, and it has to be smoothed across the year rather than lumped into March. > The danger is not the arithmetic. It is the assumption that last month's rules still apply this month. They often do not. Each of these has moving parts that change with a promotion, a threshold revision, a new state of operation, or a mid-year statutory update. ## Where hospitals actually get caught Across the units we have seen, the errors are rarely exotic. They are the same handful, repeated: - Applying an ESI threshold change from the wrong date, so an employee is deducted after they should have exited or vice versa. - Running PT on the head-office state slab for staff who actually work in another state. - Treating LOP inconsistently, so the PF and ESI bases do not match the days actually worked. - Under-deducting TDS early in the year and then shocking staff with a large March cut when the shortfall is recovered. Notice how many of these trace back to attendance. If the LOP is wrong, every downstream deduction inherits the error. Statutory payroll is only as clean as the attendance and roster data feeding it. ## Start upstream, at attendance This is why payroll cannot be an island. In the Kōami ecosystem the payroll engine reads from the same roster and attendance records that the HRMS already maintains, so the days-worked figure that drives PF, ESI and LOP is the one the geofenced check-ins and approved leave actually produced. A swap that was properly recorded, a night differential that was earned, a leave that was sanctioned - these arrive as facts, not as month-end reconstructions. When the input is trustworthy, the statutory calculation stops being a guess. The corollary is blunt: if a hospital is fixing attendance by hand every month, no payroll software will save it. The leverage is in getting the presence data right the first time, so payroll has something honest to compute on. ## Make the month-end run boring A good statutory payroll process is deliberately unexciting. The system should carry the current rules, apply them to clean data, and produce outputs that map directly to what each authority expects: - Contribution registers for PF and ESI aligned to the correct wage bases and periods. - PT computed against the right state slab for each employee's place of work. - TDS projected across the financial year, adjusted as declarations and proofs come in, and reconciled so March holds no nasty surprises. - Payslips that show each deduction as a distinct, explainable line rather than an opaque net figure. That last point earns disproportionate goodwill. When an employee can see exactly why PF, ESI, PT and TDS were deducted, the HR queue at the counter shrinks. Transparency is not a compliance requirement, but it is a trust requirement, and it costs nothing once the line items are already there. ## Keep the audit trail, because someone will ask Compliance is not only about computing correctly this month. It is about being able to show, later, that you did. A payroll run should leave behind a defensible record: which rule version was applied, what the wage base was, how LOP was derived, when the deduction was remitted. When an inspector or an auditor asks about a specific employee in a specific month, the answer should be a lookup, not an investigation. Kōami's approach is to keep these calculations and their inputs traceable so that the story holds together after the fact, without anyone reconstructing it from spreadsheets. None of this is glamorous, and that is precisely the ambition. Statutory payroll done well is invisible: staff are paid correctly, deductions land where they should, filings go out on time, and the phrase "payroll dispute" slowly disappears from the HR vocabulary. It gets there not through a single clever feature but through the unglamorous discipline of clean attendance, current rules, transparent payslips and a trail you can stand behind. Every month, the same way, without drama.

Read article
Workforce Operations
Workforce Operations· 5 min read

Letting Nurses Swap Shifts Without Chaos

Ask any charge nurse what actually happens when someone needs to swap a shift, and you will hear a story about WhatsApp. A message goes out to the ward group. Someone replies "I can take it." A third person, half-reading, assumes it is handled. The supervisor is looped in, or is not. Two weeks later the roster still shows the original name, the payroll run docks the wrong person, and nobody can reconstruct who agreed to what. Swaps are not the problem. Nurses covering for each other is a sign of a healthy team. The chaos comes from swaps happening in a channel the roster never sees. ## The hidden cost of an informal swap A shift swap looks like a private arrangement between two colleagues. In a hospital it is nothing of the sort. A single unmanaged swap can quietly break several things at once: - Skill mix: the nurse taking over may not hold the competency the shift requires, so the unit is short on paper strength even though the headcount looks fine. - Ratios: a swap that stacks one person into back-to-back shifts can breach rest rules and fatigue limits. - Attendance: the person who actually worked is marked absent, and the person who did not is marked present. - Pay: overtime, night differential and LOP all attach to the wrong name. None of this shows up on the day. It shows up at month end, in a payroll dispute, and by then the evidence is a scroll of chat messages nobody wants to arbitrate. ## What a governed swap looks like The fix is not to ban swaps. It is to give them a path that the roster and payroll can see. In the Kōami HRMS a swap is a small, structured transaction rather than a verbal agreement. A nurse offers a shift; eligible colleagues see it; one accepts; a supervisor approves or the rules approve automatically; the roster updates. The important word is eligible. The system only offers the shift to people who can legitimately take it: - They hold the skill and competency the unit and shift require. - They are not already rostered into a conflicting or adjacent shift. - Taking it will not breach hours or minimum-rest rules. - They are not on approved leave for that period. > A swap should be as easy as a WhatsApp message and as accountable as a signed form. Those two things are not in tension if the roster is doing the work. By the time a swap is confirmed, it is already valid. Nobody discovers the skill-mix problem when the patient deteriorates. ## Approvals that match how wards really run There is a temptation to route every swap through a supervisor and call it governance. On a busy ward that just moves the bottleneck. The better model is tiered approval, where the level of scrutiny matches the risk of the swap: - A like-for-like swap between two equally qualified nurses on the same unit can auto-approve within policy. - A swap that changes the skill mix, crosses units, or triggers overtime routes to the supervisor. - Anything that would breach a hard rule - rest, ratio, credential - is simply not offered in the first place. This keeps humans in the loop where judgement is needed and out of the loop where it is just friction. Supervisors stop rubber-stamping the obvious and start spending their attention on the swaps that actually deserve a second look. ## The payroll payoff The strongest argument for governed swaps is the one you feel on the last day of the month. When a swap flows through the roster, the downstream arithmetic is automatic and correct. The nurse who worked the night gets the night differential. The one who gave up the shift is not marked absent and does not take an unearned LOP. Overtime, if the swap created it, is attributed to the person who actually earned it. There is no reconstruction, no arbitration, no digging through chat history. Consider the alternative that most hospitals live with today. A swap made by phone means someone, somewhere, has to remember it and key it in. If they forget, the system confidently pays the wrong result. Every informal swap is a small debt that comes due at payroll, and the interest is paid in disputes and eroded trust. ## Fairness people can see Swaps also carry a quiet fairness dimension. In an informal system, the nurses with the best social connections get their shifts covered and the newer or quieter staff get stuck. A transparent swap board changes the dynamic: open shifts are visible to everyone eligible, not just to whoever is in the right WhatsApp group. Over time you can even see the pattern - who is always giving up shifts, who is always picking up extra, whether the load is shared or quietly dumped on the willing few. That visibility is worth as much to morale as it is to compliance. Nurses will always need to trade shifts. Life does not fit neatly into a roster drawn up a fortnight ago. The question is whether those trades happen in the daylight, where the roster records them and the pay follows correctly, or in the shadows of a chat thread where they turn into next month's argument. Give people an easy, accountable way to swap, and they will use it - not because policy forces them, but because it is genuinely less hassle than the WhatsApp scramble it replaces.

Read article
Workforce Operations
Workforce Operations· 5 min read

Geofenced Check-In Without the Friction

Attendance sounds like the most solved problem in a hospital. People arrive, people leave, a machine records it. Then you look closely and find the exceptions eating everyone alive: the biometric reader that rejects wet or gloved hands, the queue at shift change when three hundred people badge in within ten minutes, the home-visit nurse who was never near a fixed device, and the ward sister covering for a colleague across the building. Geofenced check-in is meant to remove that friction. Done badly, it adds a new kind. Done well, it becomes invisible, which is exactly what good attendance should be. ## Why fixed devices quietly fail The classic hospital attendance setup is a biometric terminal at a staff entrance. It works until it does not, and the failure modes are boringly predictable: - Clinical staff scrub, glove and sanitise constantly, so fingerprint reads degrade through the shift. - Shift-change crowding turns a five-second punch into a five-minute queue. - Community and field roles - home care, sample collection, camp duty - are nowhere near the device. - One broken reader at one door creates a day of manual corrections in the HRMS. Every one of those exceptions becomes a manual regularisation, and manual regularisations are where payroll disputes are born. The person keying the correction is guessing, and the nurse who lost forty minutes to a dead reader is the one who pays for the guess. ## How a geofence changes the model A geofence is simply a defined boundary around a place - a hospital campus, a specific block, a patient's home for a scheduled visit - expressed as coordinates and a radius. Check-in then becomes a question the phone can answer: is this person inside the boundary they are meant to be in, at the time they are meant to be there? The staff member opens the Kōami app, confirms, and the location plus timestamp is captured. No queue, no shared surface, no hunt for a working terminal. > The point of a geofence is not to watch people. It is to let the honest, present majority prove they were where they said, without waiting in a line to do it. For a home-visit nurse this is transformational. The check-in happens at the patient's doorstep, tied to the scheduled visit, and the record reflects the actual care delivered rather than a punch at a building she visited hours earlier. ## Getting the friction out without inviting fraud The reasonable worry is that a phone-based check-in is easy to game. A serious implementation closes the obvious holes rather than pretending they do not exist: - Location integrity checks that look for mock-location and spoofing signals, not just a raw coordinate. - Device binding, so an account checks in from its registered phone rather than any handset. - Optional selfie or supervisor confirmation for high-trust roles or first check-in of a shift. - Sensible radius tuning, so a large campus is covered without a boundary so loose it becomes meaningless. The goal is proportionate assurance. A ward nurse checking in inside a bound device, inside the campus geofence, at her rostered time is low risk and should sail through. The exceptions are where you spend your scrutiny. ## Where geofence meets roster and payroll Attendance that lives in its own silo is just data. The value appears when the check-in event flows straight into the roster and the payroll run. In the Kōami HRMS, a geofenced check-in is matched against the shift the person was rostered for, and the arithmetic follows automatically: - On-time arrival closes the shift expectation with no human touch. - A late or missed check-in surfaces as an exception for a supervisor, not a silent LOP. - Overtime and shift differential accrue from the same event that recorded presence. - Month-end LOP is computed from real attendance rather than reconstructed from memory. This is the difference between attendance as a tracking exercise and attendance as the spine of accurate pay. When the same event that proves presence also drives the differential and the loss-of-pay calculation, the arguments at month end mostly disappear, because everyone is looking at the same record. ## Respecting the humans holding the phone Location capture is sensitive, and pretending otherwise erodes the trust you need. A geofence used for attendance should capture location at the moment of check-in and check-out, not track people continuously through their shift. Staff should know exactly what is recorded and when. The boundary is a gate you pass through, not a leash. Hospitals that communicate this plainly get adoption; those that stay vague get quiet resistance and a workforce that assumes the worst. There is also a fairness argument. A well-tuned geofence protects staff as much as it protects the employer. The nurse who was present has proof. The field worker who completed her visits has a record nobody can dispute. Friction removed on the honest side of the ledger is worth more than the small fraction of gaming it prevents. Attendance should be the least dramatic part of anyone's day. When check-in is a two-second confirmation from the place you already are, when the record flows cleanly into roster and pay, and when staff understand and trust what is captured, the whole apparatus fades into the background. That invisibility is the goal. The best attendance system is the one nobody has to think about, and nobody has to argue with at the end of the month.

Read article
Workforce Operations
Workforce Operations· 5 min read

Overcoming Nursing Shortages with Dynamic Shift Allocation

Every nursing superintendent knows the feeling of a Monday morning that has already gone wrong by 7 a.m. Two staff nurses have called in sick, one is on unplanned leave after a family emergency, and the medical ICU is running at census with a skill mix that no longer adds up. The shortage is real and structural, but a lot of the daily pain is not about how many nurses exist. It is about how the ones you have are matched to the shifts that need them. Dynamic shift allocation will not manufacture nurses out of nowhere. It will stop you from bleeding the ones you have. ## The shortage is real, but the roster makes it worse India runs well below the nurse-to-population ratios that professional bodies recommend, and the units that feel it most - critical care, emergency, dialysis, oncology day care - are exactly the ones where a wrong skill mix is dangerous, not merely inconvenient. Yet a surprising amount of avoidable strain traces back to how rosters are built. When a roster is drawn up a fortnight in advance on a spreadsheet and then patched by phone, three things happen: - Senior nurses get loaded onto the shifts nobody else will take, and burn out faster. - Gaps are filled by whoever answers the call, not by who is best suited or best rested. - Overtime and agency spend balloon, because last-minute cover always costs more. A static roster assumes a static hospital. Hospitals are not static. Census swings, acuity changes, and people are human. ## What "dynamic" really means Dynamic allocation does not mean an algorithm barks orders at your nurses. It means the roster is a living object that reflects current reality and known constraints, and that filling a gap becomes a matter of matching rather than pleading. A good system holds a few things in its head at once: - Skill and competency, so a paediatric-trained nurse is not auto-assigned to adult ICU by accident. - Ratios and acuity, so the allocation respects the nurse-to-patient targets each unit is meant to hold. - Fatigue and fairness, so nobody is silently rostered into a third night in a row. - Statutory and contractual limits on hours and rest between shifts. > A roster is not a grid of names. It is a promise about who will be competent, present and rested when a patient deteriorates at 3 a.m. When those constraints are encoded rather than carried in one supervisor's memory, the system can propose a valid fill in seconds and flag the ones that break a rule. ## From gap to cover, in minutes The workflow that matters is the one that plays out when a shift falls short. In the manual world it is a flurry of phone calls in an order that reflects who the supervisor remembers, not who is eligible. In Kōami's HRMS the same gap becomes a targeted broadcast: the open shift, with its unit, timing and any shift differential, goes to the nurses who are qualified, not on leave, not already at their hour limit, and not about to breach rest rules. The first suitable nurse to accept is confirmed, the roster updates, and the ripple effects - attendance expectation, overtime accrual, differential pay - are captured without a second data entry. That last part matters more than it sounds. When cover is arranged by phone, the payroll consequences are reconstructed at month end from memory and half-remembered WhatsApp messages. When it flows through the roster, the LOP that should not have happened does not happen, and the extra-hours pay that was earned actually shows up. ## Design the incentives, not just the grid Technology can match a nurse to a shift. It cannot, by itself, make an unpopular shift attractive. The hospitals that get the most from dynamic allocation pair it with honest incentive design: - A transparent shift differential for nights, weekends and short-notice cover, applied consistently rather than negotiated case by case. - Visible fairness, so nurses can see that the hard shifts are shared rather than dumped. - A predictable core roster with a smaller flexible layer on top, so people can plan their lives. Nurses tolerate a hard schedule far better when it is visibly fair and honestly paid. The fastest way to worsen a shortage is to make your most capable people feel like the system quietly punishes competence with more work. ## What to measure once it is running If you cannot see it, you cannot manage it. A dynamic allocation approach earns its keep when it produces numbers a superintendent can act on: - Time to fill an open shift, tracked as a trend rather than a war story. - Overtime and agency spend as a share of total nursing hours. - Distribution of unpopular shifts across the team, to catch quiet unfairness. - Vacancy hours by unit and skill, so recruitment targets the real gaps. These are the signals that turn "we are short-staffed" from a permanent complaint into a set of problems you can chip away at. Recruitment pipelines take months, and the nursing shortage will not resolve on a hospital's timetable. What a hospital can control is whether its existing nurses are matched intelligently, paid correctly for the shifts they take, and treated fairly enough to stay. Dynamic shift allocation is not a slogan about doing more with less. It is a practical way to stop wasting the scarce, skilled, tired people already walking your wards - and, more often than not, to keep them from becoming next quarter's resignation.

Read article
Data Security
Data Security· 5 min read

Where Your Patient Data Lives, and Why It Matters

When a patient hands over their name, their UMR, a scan of an old discharge summary and a photo of a rash, they are not thinking about which server rack that data lands on. That is your job. Where patient data physically lives, who can reach it, and under whose laws it sits are not abstract concerns for a compliance binder. They shape what happens when a regulator asks a question, when a cloud region has an outage, or when a hospital in Pune wants to be certain its records are not sitting in a data centre three continents away. ## What "residency" actually means Data residency is the answer to a deceptively simple question: in which country do the bytes rest when nobody is looking at them? It is easy to confuse with two neighbours. Data sovereignty is the legal reality that whichever jurisdiction hosts the data can, in principle, compel access to it. Data localisation is a rule that says certain records must not leave a defined boundary at all. A hospital can be perfectly happy with residency in Mumbai while still being exposed if the management console, the backups, or the support team quietly sit elsewhere. The honest version of the story includes the parts that are easy to forget: - Primary storage: the OPD note, the IPD chart, the lab result. - Backups and snapshots, which often replicate to a second region for durability. - Search indexes and caches, which hold copies of the same clinical text. - Logs and telemetry, which can leak identifiers into a monitoring system abroad. - The imaging tier, where a single CT study is hundreds of DICOM instances that have to live somewhere too. If you only reason about the first line, you have described a fraction of where the data really is. ## Why Indian hospitals feel this sharply For a hospital operating in India, residency is not a philosophical preference. The Digital Personal Data Protection framework treats health information as sensitive and sets expectations about how it is handled and where it can be processed. Empanelling bodies, insurers and large corporate clients increasingly ask pointed questions in their onboarding forms. "Where is our data stored?" is now a line item, not a courtesy. > The safest answer to a residency question is one you can prove with an architecture diagram, not one you assert in a sales call. There is also the practical matter of latency and continuity. A radiologist scrubbing through a study over DICOMweb does not want frames arriving from a far region. A registration desk booking an OPD slot at 9 a.m. rush does not want a round trip across an ocean for every keystroke. Keeping the hot path close to the users is both a compliance posture and a performance one. ## How Kōami thinks about it Across the Kōami ecosystem - the HMIS, the HRMS, the inventory and imaging modules - the design principle is that a hospital should be able to name its region and trust that the whole footprint honours it. That means the transactional database, the object storage holding scanned documents, the PACS tier holding DICOM, and the daily backups all resolve to the same declared boundary rather than drifting to wherever a default happened to point. A few capabilities make that real rather than aspirational: - Region pinning at the tenant level, so a hospital's records are provisioned into a chosen geography from day one. - Encryption of data at rest and in transit, so that residency is paired with confidentiality rather than standing alone. - Segregation of tenants, so one hospital's data is never commingled with another's in a way that makes residency claims meaningless. - Access logging that records who read what, which turns "we keep it safe" into something you can actually audit. None of this is a certification claim. Kōami is young, and it would be dishonest to wave a badge we have not earned. What we can do is describe the controls plainly and let a hospital's own security team verify them. ## The questions to ask any vendor If you take one thing from this piece, let it be a short interrogation to run on every clinical software vendor, including us: - Where does primary storage sit, by region and provider? - Do backups and disaster-recovery copies stay in that same region, or cross a border for durability? - Who, on the vendor side, can technically access production data, and is that access logged? - When you delete a record, how long do copies persist in snapshots and logs? - If you had to exit the contract, in what format and from which region do you get your data back? The answers separate vendors who have thought about this from vendors who will improvise when the regulator calls. A vague or shifting answer to the backup question in particular is a reliable tell. ## Residency is a promise, not a setting It is tempting to treat residency as a checkbox flipped once during setup. In practice it is a promise that has to survive every future decision: the new analytics feature that ships logs somewhere convenient, the support engineer who pulls a copy to debug, the cost optimisation that moves cold storage to a cheaper region. A residency guarantee is only as strong as the discipline behind the least glamorous parts of the system. For a hospital, the goal is not to become an infrastructure expert. It is to ask the right five questions and to work with software that answers them the same way twice. Patient trust is built quietly, in places patients never see. Knowing where their data lives, and being able to say so with confidence, is one of those quiet foundations worth getting right.

Read article
Data Security
Data Security· 5 min read

Making MFA Painless for Busy Wards

Security teams love multi-factor authentication and wards quietly hate it, and both are right. MFA genuinely stops the most common way accounts get compromised, a stolen or guessed password, from being enough on its own. It is also, in its clumsier forms, exactly the kind of friction that makes a nurse with a deteriorating patient reach for a shared login instead. The whole challenge is not whether to use MFA on clinical systems. It is how to make it fast enough that nobody has a reason to route around it. ## Why a password alone stopped being enough Passwords fail in predictable ways. They get reused across systems, so a leak somewhere else becomes a way into the EMR. They get written on notes stuck to monitors. They get phished. On a busy ward they get shared, which means they are not really secret at all. A single factor, something you know, is a thin defence for data this sensitive, because knowing is easy to steal. MFA adds a second, different kind of factor, something you have or something you are, so that a stolen password is not a stolen account. The attacker who phished the credential still cannot log in without the second factor. That is the entire value, and it is substantial: it neutralises the most common attack against the most sensitive data in the hospital. - Something you know: the password, which alone is too easy to compromise - Something you have: a device, a token, a passkey on a phone - Something you are: a fingerprint or face, fast and hard to lend to a colleague ## The friction is the whole problem Here is the uncomfortable truth. If MFA takes too long or interrupts too often, clinicians will defeat it, not out of malice but out of clinical necessity. A prompt that fires every few minutes, or demands a code typed from a separate device while the clinician's hands are gloved and busy, does not make the ward more secure. It makes the ward invent a workaround, and the workaround, usually a shared always-on session, is far less secure than the password MFA was meant to strengthen. So the design goal is specific: authentication strong enough to stop stolen credentials, light enough that the safe path is also the fast path. That means paying attention to the moments where friction actually bites. - The first login of a shift, which should be quick even if it is the most secure step - Returning to a workstation after stepping away, where a full re-login is overkill - Shared ward devices, where the challenge is switching users fast, not proving identity slowly - Gloved or sterile contexts, where typing a code from a phone is simply not going to happen > An MFA scheme that clinicians route around has negative value; it created friction and bought no security. ## What painless actually looks like Painless MFA is not weaker MFA. It is MFA that fits the shape of clinical work. Several design choices make the difference between adoption and revolt. Fast factors first. A tap on a registered device or a fingerprint is far more ward-friendly than reading a six-digit code off one screen and typing it into another. Push approvals and passkeys give strong security with a single gesture. The less the clinician has to type, the more likely the control survives contact with a real shift. Risk-based prompting. Not every action needs the same challenge. A first login of the day on a new device deserves full verification. Continuing an active session on the same trusted workstation does not need to be interrupted every few minutes. Prompting harder when the context is unusual, and staying quiet when it is routine, concentrates the friction where it earns its keep. Sensible sessions. On shared ward devices the real need is fast user switching: one clinician steps away, the next authenticates in seconds and the session is unambiguously theirs. Sessions that stay open during active use but time out when a device is abandoned protect the record without forcing constant re-entry. This is also what finally kills the shared login, because individual access is now quick enough that the shortcut offers nothing. Kōami supports multi-factor authentication designed for this reality, favouring fast factors and session handling that suits a ward, so that strong authentication does not come at the price of a workaround. ## Rolling it out without a revolt Even good MFA fails if it is dropped on a ward as a mandate with no groundwork. The rollouts that stick share a pattern. They enrol staff in advance, so nobody is registering a device for the first time while a patient waits. They pilot on one ward, learn where the friction actually lands, and fix it before scaling. They provide a fallback for the genuine edge case, the lost phone, without making the fallback so easy that it becomes the default. And they explain the why in terms clinicians care about, which is not compliance but the fact that this is what stops someone else logging in as you and touching your patients' records. The measure of success is quiet. If MFA is working, clinicians stop noticing it, shared logins fade because individual access is no longer slower, and the security team stops seeing the account compromises that a single password used to allow. Nobody thanks a login screen, and they should not have to. The best outcome is that strong authentication simply becomes the unremarkable way the day starts, fast enough to disappear into the routine, strong enough that the one attack it was built to stop no longer works.

Read article
Data Security
Data Security· 5 min read

What a Good Audit Log Actually Records

An audit log is one of those features everyone assumes they have until the moment they need it. Then someone asks a specific question, who opened this patient's record last Tuesday, and the honest answer turns out to be we are not sure. A good audit trail is not a box ticked for a policy document. It is a truthful, detailed, tamper-resistant account of what happened in the system, built so that months later it can answer a question nobody thought to ask at the time. ## The question an audit log has to answer Every audit log exists to answer one shape of question: who did what, to which record, when, and from where. That sounds obvious, yet plenty of systems log something far weaker, a vague note that a record was viewed, with no reliable link to a person or a time you can trust. When the question is real, for instance a patient asking who has seen their data or an investigation into a suspected inappropriate access, the vague log is worthless. A useful entry pins down the specifics. For a single access to a patient record it should capture, at minimum: - The individual who performed the action, tied to their own account - The exact action: viewed, created, edited, printed, exported, deleted - The specific record or field affected, identified by UMR or equivalent - The timestamp, precise and from a trusted clock - The context: the device or location, and the session it belonged to Notice the dependence on individual identity. This is where shared logins quietly poison the whole thing. If several people use one account, every line in the log names that account and none of them names a person. The audit trail is only ever as good as the identities underneath it, which is why individual accounts are a precondition for meaningful auditing, not a separate concern. ## Reads matter as much as writes Many systems dutifully log changes, a record was edited, a result was entered, and ignore reads. That is a serious gap in healthcare, because inappropriate access is usually about looking, not changing. The curious member of staff opening a colleague's record, or a public figure's, does not alter anything. They read. If the log only records writes, that access is invisible. So a healthcare audit log has to treat viewing as an auditable event. Opening a record is an action worth recording, because the ability to say who has looked at this patient's data is exactly what patients and regulators expect. This is the kind of access tracking that workflows such as NABH lean on, and it is meaningless if reads go unlogged. > If your audit log only shows what changed, it is blind to the most common form of misuse, which is simply looking. ## A log you cannot trust is not a log An audit trail is only evidence if it cannot be quietly altered by the people it might implicate. If a user with enough access can edit or delete log entries, then the log proves nothing, because any incriminating line could have been removed. The integrity of the log is as important as its content. That leads to a few design properties that separate a real audit trail from a decorative one. - Append-only: entries are added, never edited or overwritten in place - Separated from user control: no ordinary clinical or admin role can alter the log - Retained for a defined period, long enough to be useful when a question arrives late - Time-trustworthy: timestamps come from a reliable source, not an editable local clock - Complete: security-relevant events are captured consistently, not selectively Kōami records access and changes to patient data in an audit log built on these principles, so that the record of what happened is itself protected from casual tampering. The aim is simple to state: when someone finally asks the awkward question, the answer should come from a log that no one had the chance to tidy up first. ## Logs are only useful if someone can read them A perfect log that nobody can search is a filing cabinet nailed shut. The value of the trail is realised only when a person with the right authority can actually interrogate it: show me every access to this UMR in the last month, show me everything this user did on this date, show me who exported data last week. If answering those takes a database engineer and three days, the log will not be used, and unused controls decay. So the trail needs to be queryable by the people responsible for oversight, with access to the log itself controlled and, ideally, itself audited. There is a neat recursion here: looking at the audit log is an action, and a mature system logs that too, because the people who can see everything are exactly the people whose access most deserves a record. Reviewing the log should be routine, not a thing that only happens after a crisis, because regular review is what turns a passive record into an actual deterrent. ## What good looks like in practice Put it together and a good audit log has a recognisable character. It names people, not shared accounts. It records reads as well as writes. It cannot be quietly edited by those it might expose. It keeps entries long enough to matter and stamps them with a time you can trust. And it can be searched by the right people quickly enough that it actually gets used. None of these on their own is exotic. The failures come from missing one, a log that captures changes but not views, or names accounts but not individuals, or holds rich detail that any admin can rewrite. The test of an audit trail is never how it looks in a demo. It is the moment, maybe a year later, when a specific and uncomfortable question arrives and the log has to answer it plainly and completely. Build it for that moment, and it will serve every quieter purpose along the way. Build it for the policy checkbox, and it will fail you at exactly the moment it was supposed to help.

Read article
Data Security
Data Security· 5 min read

Why Role-Based Access Beats Shared Logins

Walk into a busy ward and you will often find a workstation logged in under a generic account, left open so whoever needs it can chart quickly. It is understandable. It is also the single habit that undoes almost every other security control a hospital has. The moment several people share one login, the record can no longer tell you who did anything. Role-based access exists to make the fast, safe path and the traceable path the same path, so nobody has a reason to reach for the shared account again. ## What a shared login actually costs A shared account feels efficient. In reality it quietly disables the things that protect both patients and staff. When five nurses use one login, the audit log records five people's work under one name, which means it records nothing useful. If a record is accessed inappropriately, there is no way to know who did it. If a medication is charted in error, the trail leads to an account, not a person. The clinician who did everything correctly is now indistinguishable from the one who did not. The costs stack up quickly. - Accountability disappears, because every action traces to a shared name - Access cannot be scoped, so the shared account tends to accumulate broad permissions - Offboarding breaks, because you cannot remove one person from a shared credential without disrupting everyone - Passwords get written down and rarely changed, because rotating them means retraining a whole ward - Investigations stall, because the log cannot answer the one question that matters: who None of this means the staff are careless. It means the system offered them a shortcut that was faster than doing it right, and people under pressure take the faster path. The fix is not a lecture about compliance. It is making individual access fast enough that the shortcut loses its appeal. ## Roles map to how a hospital actually works Role-based access control, RBAC, starts from a simple observation: a hospital is already organised by role. A ward nurse, a consultant, an OPD receptionist, a pharmacist, a lab technician, a billing clerk. Each needs a different slice of the system, and those slices are stable. A nurse needs the observation charts and medication administration for their ward. A billing clerk needs the financial and demographic data but has no business reading clinical notes in depth. RBAC formalises this. Instead of granting permissions to individuals one by one, you define roles with the access that role requires, and assign people to roles. When someone joins, they get a role and the correct access follows automatically. When they move from the ward to theatre, you change their role and their access changes with it. The permissions live with the role, and the person simply inherits them. > Access should follow the job, not the person, and certainly not a password stuck to a monitor. ## Least privilege is the discipline that keeps it honest Defining roles is the easy part. The discipline that gives RBAC its value is least privilege: each role gets the minimum access it needs to do the work, and no more. It is tempting to grant generously, because broad access means fewer requests and fewer complaints. That generosity is exactly how a compromised account or a curious insider ends up with reach across the whole hospital. Least privilege applied properly looks like this. - Each role is scoped to the data and actions its work genuinely requires - Access is reviewed periodically, not granted once and left forever - Elevated access is deliberate and time-limited rather than permanent by default - Access is removed promptly when someone changes role or leaves - Sensitive categories get tighter scoping, so not every clinical user can open every record The point is not to make clinicians' lives harder. A nurse should never notice least privilege on a normal day, because their role already contains everything their job needs. They notice it only at the edges, when the system declines to show them something outside their remit, which is precisely the moment you want a boundary. ## Individual identity makes everything else work Here is the part that ties it together. Almost every other security control depends on knowing who is acting. Audit logs are meaningful only if each action maps to a person. Multi-factor authentication protects an account only if that account belongs to one individual. Least privilege can only be scoped if the system knows which person, in which role, is logged in. Shared logins knock the foundation out from under all of it. That is why Kōami is built around individual accounts with role-based permissions rather than shared credentials. Each person authenticates as themselves, carries the access their role defines, and leaves a trail under their own name. The convenience that once drove people to shared logins, fast access on a busy ward, comes instead from quick individual sign-in and sensible session handling, so the safe path is also the fast one. ## Making the transition realistic Moving a ward off shared logins fails when it is imposed as a rule without removing the friction that created the workaround. The transition works when individual login is genuinely quick: fast authentication, sessions that do not force constant re-entry during active use but time out when a device is abandoned, and roles pre-built so nobody waits days for access. Get that right and staff stop resenting the change, because the new way is not slower, it is simply attributable. Role-based access with least privilege is not a security feature you bolt on. It is the model that lets every other protection mean something. It gives each action an owner, keeps each person's reach matched to their job, and turns the record from a shared blur into an honest account of who did what. The shared login was never really about convenience. It was about the system not making individual access easy enough. Fix that, and the shared login has nothing left to offer.

Read article
Data Security
Data Security· 5 min read

Securing Patient Data in Cloud-Based EMR Systems

Moving an EMR to the cloud does not make patient data more or less secure by itself. It changes where the risks live and who is responsible for which layer of the defence. A hospital that treats the cloud as someone else's problem is exposed; a hospital that understands the split, and builds on top of a platform designed for it, ends up with protections that an on-premise server room rarely matched. The security of patient data in a cloud EMR is not a product you buy. It is a set of controls you configure, operate, and check. ## The shared responsibility line The first thing to get straight is who does what. A cloud platform secures the physical infrastructure, the data centres, the hypervisor, the base network. That is real and valuable, but it is not the whole job. The application layer, the access controls, the way data is handled inside the system, the discipline of who can see which record: those sit with the software and the hospital that runs it. Confusing the two is how breaches happen. The infrastructure was never the weak point; the misconfigured access was. So the useful question is not is the cloud secure but is the whole stack secure, from the data centre up through the application to the clinician logging in on a ward tablet. Each layer needs its own controls, and they have to fit together. - Infrastructure: the physical and network security of the hosting platform - Platform: encryption, key management, network isolation, backups - Application: authentication, role-based access, audit logging, session handling - Operational: the hospital's own policies on who gets access and how it is reviewed ## Encryption in transit and at rest Encryption is the baseline, and it has to cover data both while it moves and while it sits still. In transit means every connection between a clinician's device and the system is encrypted, so a UMR travelling across the network cannot be read by anything sitting in the middle. At rest means the stored data, including the database and any backups, is encrypted so that a stolen disk or a copied backup file is useless without the keys. The keys are the part people forget. Encryption is only as good as the management of the keys that unlock it. That means keys held separately from the data they protect, rotated on a schedule, and never sitting in plain text in a config file or a code repository. Kōami encrypts patient data both in transit and at rest, and treats key handling as a distinct discipline rather than an afterthought, because encryption with careless keys is theatre. > The database being encrypted means nothing if the key is in the same place, readable by the same account. ## Access is where most breaches actually happen Ask where health data actually leaks and the answer is rarely broken cryptography. It is access. An account with more reach than it needed, a shared login nobody can trace, a leaver whose credentials still worked, an internal user browsing records they had no business opening. The strongest encryption in the world does not help when the person reading the record is authenticated and simply should not be. So the controls that matter most day to day are the boring ones. - Role-based access, so a clinician sees what their role requires and not the whole hospital - The principle of least privilege applied and reviewed, not granted once and forgotten - Multi-factor authentication, so a stolen password is not enough on its own - Prompt de-provisioning when someone changes role or leaves - Session controls that time out abandoned logins on shared ward devices These are capabilities Kōami provides and the hospital operates. The platform can enforce role-based access and MFA; it is the organisation that decides who gets which role and reviews those decisions. That division is not a gap; it is how it should work. The software makes the right thing possible and the wrong thing hard, and the hospital's governance does the rest. ## Proving it after the fact Prevention is only half of data protection. The other half is being able to reconstruct what happened, because sooner or later someone will ask who accessed a particular record and when. A cloud EMR should log access to patient data comprehensively: who opened which record, from where, and when, retained long enough to be useful for review. This audit capability does double duty. It deters casual snooping, because staff know that access to a record leaves a trace. And it is the mechanism by which a hospital investigates a concern, whether that is a suspected inappropriate access or simply a routine check that access patterns look reasonable. Aligned with the kind of access-tracking that workflows such as NABH expect, comprehensive logging turns security from a promise into something you can actually examine. ## A word on certification, honestly It is worth being plain here. A new platform can build strong technical controls, encryption, role-based access, MFA, comprehensive audit logging, from day one. What it cannot honestly claim on day one is a shelf of external certifications, and any vendor waving certification badges before they are earned should make you cautious. The right questions to ask a cloud EMR are about capabilities you can inspect: how is data encrypted, how are keys managed, how is access controlled and reviewed, what exactly is logged, and who on our side holds which responsibility. Security in a cloud EMR is not a status you reach and stop thinking about. It is the ongoing operation of a set of controls that span the platform and the hospital, checked and adjusted as roles change and threats evolve. The encryption keeps the data unreadable to outsiders. The access controls keep it readable only to the right insiders. The audit log lets you prove both. Get those three working together, and the cloud becomes not a risk to patient data but one of the better places to protect it.

Read article
Clinical AI
Clinical AI· 5 min read

Catching Sepsis Earlier with Trend Signals

Sepsis rarely announces itself. By the time it is obvious, with a crashing blood pressure and a patient who looks unwell to anyone walking past, the easy window has already closed. The difficult truth of sepsis is that the early hours, when treatment does the most good, are also the hours when the signs are subtle and scattered across a chart nobody is reading as a whole. Early warning is not about spotting the dramatic moment. It is about noticing the drift before it becomes a fall. ## The signal is in the trend, not the snapshot A single set of observations can look reassuring while a patient is quietly heading in the wrong direction. A heart rate of 96 is unremarkable. A heart rate that has climbed from 72 to 96 over six hours, alongside a respiratory rate creeping up and a temperature that will not settle, is a different story entirely. The individual numbers stay inside their normal ranges right up until they do not, and a clinician glancing at the latest vitals sees nothing wrong. This is why trend beats snapshot. The information that matters is the direction and the rate of change, read across several parameters at once. Humans are not built to do this well across a busy ward. We anchor on the most recent reading, we compare it loosely to some remembered baseline, and we move on to the next of twenty patients. A model does not tire of watching the slope. - Rising heart rate over hours, even within the normal band - Respiratory rate climbing, often the earliest and most ignored sign - Temperature instability, high or unexpectedly low - Blood pressure trending down from the patient's own baseline - Falling urine output and rising lactate where available ## From MEWS to a moving picture Most wards already run an early-warning score such as MEWS, and it is genuinely useful. It turns scattered vitals into a single number that triggers an escalation. But a periodic score is a series of snapshots. It fires when the patient has already crossed a threshold, and it does not see the six hours of drift that led there. It is a smoke alarm, not a thermostat. A trend-based warning layer sits underneath the score and watches the movement between calculations. It combines the observation stream with what else the record knows: recent surgery, an existing infection, immunosuppression, the results that came back from the lab an hour ago. The result is not a replacement for MEWS but a sharpening of it. Where the score says this patient is now unwell, the trend layer can say this patient is becoming unwell, and here is why. > Sepsis care is a race against a clock that started before anyone noticed. ## Why the alert has to be quiet and specific Every clinician has been trained by bad alarms to ignore alarms. A sepsis warning that fires too often, or fires on patients who are obviously fine, will be muted within a week and rightly so. Alert fatigue is not a minor usability issue; it is the single most common reason these systems fail in the real world. The design constraint is brutal: the warning must be right often enough that people keep listening. That means a few things in practice. - The alert names the reason: which parameters are trending and over what period - It fires early enough to matter but not so early that it cries wolf - It routes to someone who can act, not to a screen nobody watches - It supports escalation rather than replacing clinical judgement about it - It can be acknowledged and its outcome recorded, so the system can be tuned Because Kōami's early-warning layer reads the same observation and result streams that the rest of the record already captures, the clinician does not enter anything twice. The vitals charted at the bedside feed the trend analysis directly, and the warning appears where the ward already looks rather than in a separate application. ## The clinician still owns the decision A trend warning is a prompt, not a diagnosis. It says: look at this patient now, and consider whether the sepsis pathway applies. It does not order antibiotics, it does not diagnose the source, and it does not override the judgement of the person at the bedside who can see things no model can, such as how the patient actually looks and what the family is reporting. This matters for adoption as much as for safety. Clinicians accept a tool that hands them a well-reasoned prompt and leaves the decision with them. They reject a tool that presumes to make the call. The correct division of labour is the one that already works in good clinical practice: the system watches tirelessly and flags the drift; the human assesses, decides, and acts. Every alert and its outcome are logged, so the ward can review its false alarms, tighten its thresholds, and see whether the tool is actually shortening the time to treatment. The reward for getting this right is measured in hours saved at the front of a sepsis course, and those hours are the ones that change outcomes. Catching the drift at hour three instead of the fall at hour eight means antibiotics sooner, fluids sooner, and a senior review while the patient is still recoverable with less. No model catches every case, and none should be trusted to. But a tireless watcher on the slope of the numbers, handing a specific and timely prompt to a clinician who can act, turns some of those late falls back into early catches. In sepsis, that is the whole game.

Read article
Clinical AI
Clinical AI· 5 min read

Cutting Clinician Typing with Ambient Notes

Ask any clinician what they like least about their day and the answer is rarely a patient. It is the notes. The consultation that took twelve minutes generates twenty minutes of typing, and the typing does not happen between patients; it piles up and gets finished late in the evening, from home, long after the details have started to blur. Ambient documentation aims at this directly. It listens to the encounter, drafts the note, and hands the clinician back the minutes that used to disappear into the keyboard. ## The documentation burden is a clinical problem, not an admin one It is tempting to file paperwork under administration and move on. But documentation debt has clinical consequences. A note written six hours after the consultation is less accurate than one written during it. Details soften, exact figures get approximated, the specific phrasing a patient used gets lost. Worse, the sheer volume drives clinicians to shortcuts: cloned notes, copy-forward errors, templates padded with text nobody read. The record fills up while actually containing less. There is a human cost layered on top. Time spent typing is time not spent looking at the patient, and it is time stolen from rest at the end of a shift. The burnout literature keeps returning to documentation load as a driver, and any OPD clinician running a full clinic recognises why. - Notes written long after the encounter drift from what actually happened - Copy-forward and cloned text bloat the record and hide real change - Screen-facing data entry pulls attention away from the patient in the room - After-hours charting eats into recovery and fuels burnout ## What ambient capture actually does Ambient documentation uses the audio of a normal consultation, with the patient's knowledge and consent, and drafts a structured note from it. The clinician talks to the patient the way they always would. In the background the system distinguishes the clinical conversation from small talk, pulls out the history, examination findings, and plan, and lays them into the note structure the department already uses. The important word is draft. What lands in the EMR is a starting point, not a finished record. The clinician reads it, corrects it, adds the reasoning that was in their head but never spoken aloud, and signs it. That review step is not a weakness of the approach; it is the whole safety model. The human who saw the patient is the one who commits the note. > The goal is not a note written by a machine. It is a note the clinician can finish in two minutes instead of twenty. ## Fitting the note into a real record A drafted paragraph of prose is only half the job. A clinical note has to slot into the actual record: the right patient under the right UMR, the correct OPD or IPD encounter, coded where coding is needed, with medications and follow-up landing in the fields the rest of the system reads. Ambient text that sits in a free-text blob helps the writer and nobody else. This is where being part of the wider clinical system matters more than the transcription quality. Because Kōami's ambient layer writes into the same EMR that holds the patient's history, the draft can be checked against what is already known: the allergy the patient forgot to mention, the medication they are already on, the result that came back this morning. The note is not composed in isolation; it is composed against the record. A follow-up mentioned out loud can become an actual OPD appointment. A drug named in conversation can be reconciled against the current list rather than retyped blind. ## Keeping the record trustworthy Handing note-writing to a model raises fair questions, and they deserve concrete answers rather than reassurance. - The clinician reviews and signs every note; nothing enters the record unread - The draft is clearly marked as draft until a named clinician commits it - The audio is handled as sensitive patient data, encrypted and access-controlled like the rest of the record - What was captured, what was drafted, and who signed it are all logged, so the note has a clear provenance - The clinician can always write or dictate manually; ambient capture is an option, not a mandate The failure to avoid is a plausible-sounding note that quietly invents detail. Language models can produce fluent text that was never said. The defence is the review step and the discipline of checking the draft against the structured record, not trusting the prose on its own. A clinician who treats the draft as a colleague's rough notes, to be verified before signing, gets the benefit without the risk. ## Measuring whether it actually helps The promise is easy to state and worth checking honestly. Does documentation time per encounter fall? Do clinicians finish their notes before they leave rather than at home? Does the record get more specific, or just longer? A tool that produces beautiful prose but still needs heavy rewriting has not solved the problem; it has moved it. The encounters where ambient capture helps most are the conversational ones: a complex history in OPD, a discharge discussion, a consultation where the clinician would otherwise be typing while the patient talks. It helps least where the work is procedural and the data structured, and that is fine. The aim is not to automate every note. It is to take the heaviest, most narrative documentation and make it fast enough that it gets done in the room, while the details are still fresh and the patient is still there to correct them. Ambient notes will not, and should not, remove the clinician from the record. What they remove is the tax that turned a twelve-minute consultation into a thirty-minute one. Give a clinician back those minutes across a full clinic and you have not just saved time; you have moved their attention back to where it belongs, which is the person sitting across the desk.

Read article
Clinical AI
Clinical AI· 5 min read

AI Findings as a Second Reader, Not a Replacement

There is a version of clinical AI that promises to read the scan for you. It is the version that makes radiologists nervous, and they are right to be. A more honest and more useful framing has been sitting in radiology practice for decades: the second reader. A second pair of eyes on the same study, catching the thing the first reader's attention slid past at the end of a long list. AI is very good at being that second reader, and it is a poor and dangerous substitute for the first. ## What a second reader actually does Double reading is not a new idea. Screening programmes have long used two independent readers precisely because a single human, however skilled, misses things. Fatigue, satisfaction of search, the subtle nodule at the edge of the lung field on the two hundredth chest study of the day. A second reader does not have to be smarter than the first. It only has to be tired at a different time and biased in a different direction. That is the role AI fits naturally. It never gets bored on the night shift. It looks at every part of every image with the same consistency. It has no memory of the last case colouring its read of this one. Those are exactly the failure modes that catch human readers, which is why pairing the two covers more ground than either alone. - The human brings context, clinical history, and judgement about what matters for this patient - The model brings consistency, tirelessness, and pixel-level attention across the whole image - Together they catch both the subtle finding and the finding that only makes sense in context ## Second reader, not replacement, and the difference is not semantic The distinction sounds like marketing caution, but it reflects how the workflow is actually built. In a replacement model, the AI reads and the human rubber-stamps, and the human's attention quietly decays because they assume the machine has already done the work. That is the worst of both worlds: automation bias on top of a model that will, sometimes, be confidently wrong. In a second-reader model, the human reads first and forms their own impression before seeing the AI's findings. The order matters. The clinician commits to a read, then the model's marks appear as prompts to reconsider, not as answers to accept. A flagged region asks a question: did you look here, and are you sure? The radiologist can dismiss it, and dismissing it is a normal part of the workflow, not an override that fights the system. > The AI is allowed to be wrong, because a named clinician still owns the report. ## Where the extra pair of eyes pays off The findings AI second reading helps with most are the ones humans miss for predictable reasons. - Small pulmonary nodules that hide against vessels or at the lung apices - Subtle fractures on trauma films read quickly under pressure - Findings incidental to the clinical question, which attention naturally skips over - The second abnormality, once the eye has locked onto the obvious first one - Interval change on follow-up imaging, where side-by-side comparison is tedious and easy to shortcut Notice what is not on that list. The model is not there to make the primary diagnosis on a complex case, weigh competing possibilities, or decide what a finding means for this particular patient. It is there to make sure nothing was skipped. The radiologist still reads through DICOM on PACS the way they always have; the second-reader marks simply overlay on the same study, sourced through WADO, so there is no separate tool to open and no images to shuffle between systems. ## Designing so it helps instead of nagging A second reader that flags everything trains people to ignore it. The failure mode is alert fatigue, and it kills these tools. So the design has to respect the radiologist's time and attention as the scarce resource it is. Flags should be specific, few, and confident enough to be worth a second look. The interface should let a reader accept or dismiss a mark in one motion, and it should never block sign-off waiting for the human to acknowledge every suggestion. Just as important, every interaction leaves a trail. When a radiologist dismisses a flag, that decision is recorded, not to police the clinician but to let the department study the model's behaviour over time. Which flags get dismissed constantly? Those thresholds need tuning. Which dismissed flags later turned out to matter? That is the review that makes the system safer. In Kōami's imaging workflow the marks, the confidence, and the reader's response all sit in the audit log, so accountability and quality review draw on the same record. ## Keeping the line of accountability clean The single most important property of a second-reader system is that it never blurs who is responsible. The report carries a radiologist's name. The AI's marks are inputs to that person's judgement, exactly like a prior study or a clinical note, and they carry no authority of their own. If the model misses something, the human is still reading. If the model flags something wrong, the human dismisses it. At no point does the machine get to be the reason a mistake reached the patient unchallenged. That clarity is what makes the second-reader model both safe and adoptable. Radiologists do not have to trust the AI to be right, because they are not relying on it to be right. They only have to accept that a tireless, consistent extra look, offered after they have formed their own view, catches things worth catching. Framed that way, AI stops being a threat to the profession and becomes what a good colleague has always been: someone who says, before you sign off, did you see this?

Read article
Clinical AI
Clinical AI· 5 min read

Triage That Reads the Worklist Before You Do

A radiology worklist at 8am is a wall of studies stacked in the order they arrived. The chest CT that will change someone's afternoon sits three rows below a routine follow-up that can safely wait until lunch. First-in-first-out is fair, but fairness and urgency are not the same thing. AI triage does something quietly powerful: it reads the worklist before the radiologist does, and reorders it so the study that matters most is the one waiting at the top. ## The worklist is not a queue, it is a risk pile Most PACS worklists are sorted by time, modality, or referring location. That is easy to build and easy to defend, but it assumes every study carries the same clinical weight. It does not. A non-contrast head CT flagged from the emergency department may hold a bleed that needs a call to the on-call team within minutes. The same list holds surveillance scans where a day's delay changes nothing. When these are interleaved by arrival time alone, the urgent study depends on luck: whoever happens to open it first. Triage models change the sorting key from when to how urgent. They pre-read incoming studies as they land on PACS and attach a priority signal, so the worklist reflects clinical risk rather than clock order. The radiologist still reads everything. They just read the frightening things first. ## Reading pixels and context together A useful triage layer does not look at the image alone. It combines the DICOM pixel data with the metadata and the request context that already travel with the study. - The image findings themselves, for example a suspected large-vessel occlusion or a pneumothorax - DICOM tags: modality, body part, contrast, and the referring source - The clinical question on the request, which separates a trauma scan from routine imaging - Where the order came from, since an ED or ICU origin carries different urgency than an OPD follow-up - Patient flags already in the EMR, such as a recent stroke pathway activation Pulling these together matters because pixels without context mislead. A small effusion is unremarkable in one patient and a red flag in another. When the triage layer in Kōami's imaging stack reads the study through WADO alongside the order details, the priority it assigns reflects the whole picture, not just the greyscale. > Triage does not tell the radiologist what to think. It tells them what to look at next. ## Sensitivity is the whole game For a triage tool, the costly error is the miss. If the model quietly downgrades a genuine emergency, it has actively caused harm by burying the study deeper in the list. So these systems are tuned to favour sensitivity: when unsure, escalate. That means accepting more false alarms in exchange for catching the true ones. The trade is only acceptable if false positives stay cheap. Escalating a study that turns out to be normal costs a few minutes of a radiologist's attention. Because the radiologist reads every study regardless, an over-cautious flag does not remove anyone from care; it only nudges the reading order. The design principle is simple to state and hard to violate: triage may reorder the worklist, but it must never remove a study from it or mark anything as safe to skip. ## Where it changes turnaround time The metric that improves most visibly is TAT, and specifically the tail of the distribution. Average turnaround can look fine while a handful of critical studies wait far too long because they landed behind a batch of routine imaging. Triage attacks that tail directly. Concretely, the workflow shifts in a few ways: - Critical studies surface at the top of the worklist within moments of hitting PACS - The on-call radiologist covering several sites sees the most urgent study across all of them, not just the newest at each - Overnight, when one person may cover a large volume, the ordering protects the cases that cannot wait for morning - Referring teams get faster answers on the studies where speed changes management The routine work still gets read, and gets read properly. It simply stops competing for pole position with the emergencies. Over a week, that is the difference between a stroke call going out in minutes and going out after a reader has ploughed through an unlucky backlog. ## Trust comes from being legible and auditable A radiologist will not hand their reading order to a system they cannot question. So the triage flag has to explain itself and has to leave a record. Each prioritised study should carry the reason it was escalated and the confidence behind it, and every reordering should be logged so a department can review, weeks later, whether the tool helped or hindered on a given case. That audit trail is not bureaucracy. It is how a department learns the model's blind spots, tunes its thresholds, and defends its workflow if a case is ever reviewed. It also keeps accountability where it belongs. The AI arranged the list; the radiologist made the diagnosis. Nothing about triage dilutes that line. Triage is one of the least glamorous applications of clinical AI and one of the most defensible. It does not diagnose, it does not replace anyone, and it does not ask the radiologist to trust a machine with a patient. It just makes sure that when a busy reader sits down to a full worklist, the study that could not wait is already the one in front of them.

Read article
Clinical AI
Clinical AI· 5 min read

AI-Driven Ward Scheduling & Optimal Care

Any charge nurse can tell you that a ward schedule looks tidy on paper and falls apart by 10am. A patient in bed 12 deteriorates, two admissions arrive from OPD at once, a senior resident gets pulled into theatre, and the careful staffing plan built the night before is suddenly wrong. Ward scheduling is not really a rostering problem. It is a live matching problem between the acuity of the patients in front of you and the skills, hands, and beds available right now. AI helps most when it treats it exactly that way. ## Scheduling is an acuity problem, not a headcount problem The old way of planning a shift counts people. Six nurses for thirty beds, tick, move on. It ignores the fact that three of those beds hold stable post-operative patients waiting for discharge while two hold unstable IPD cases who need hourly observations. A model that reads live signals from the EMR can weight the ward by workload rather than by bed count. The inputs that actually matter are already flowing through the system: - ADT events that tell you who was admitted, transferred, or discharged in the last hour - MEWS or early-warning scores trending up on specific patients - Nursing task load: due medications, dressing changes, drain checks, vitals frequency - Skill mix on the floor, including who is credentialed for high-dependency care - Pending OPD-to-IPD conversions and expected theatre returns When Kōami's scheduling layer combines these, the output is not a fixed roster. It is a ranked picture of where the pressure is building, so the nurse in charge can move one person from a settling bay to the bay that is about to get busy. ## Predicting the next four hours, not the next month Long-range rosters still matter for fairness and for leave planning. But the value of AI shows up in the short horizon. If admission patterns from the last several weeks show that Monday mornings bring a surge of post-weekend OPD referrals into IPD, the model can flag that surge before it lands, not after the beds are full. > The best schedule is the one that is already adjusting while the shift is still calm. A short-horizon forecast lets the ward do three practical things. It can hold a float nurse instead of releasing one early. It can sequence discharges so beds open before the predicted admissions arrive. And it can warn the bed manager that the ward will breach its safe ratio in about two hours unless something changes, which is a very different conversation from discovering the breach once it has happened. ## Keeping the human in charge of the roster Clinicians are right to be wary of a black box that reshuffles their day. A scheduling model earns trust by being legible. Every suggestion should carry its reason: this bay is flagged because two patients crossed a MEWS threshold and three medications are due within the hour. The charge nurse can accept, ignore, or override, and the override is data, not defiance. Over time those overrides teach the system where its assumptions are wrong. Good practice here mirrors safe clinical workflow. The AI proposes; a named human disposes. Assignments still respect the constraints that no algorithm should quietly break: statutory rest between shifts, credentialing rules, and continuity of care so a patient is not handed between four different nurses in one afternoon. When the tool respects those guardrails, staff stop treating it as an adversary and start treating it as an extra set of eyes on the whole floor. ## What optimal care actually looks like on the floor Optimal is a loaded word, so it helps to be concrete about the outcomes a scheduling model should move. - Fewer moments where a deteriorating patient waits because the nurse who noticed is tied up three beds away - Shorter gaps between a discharge decision and the bed being ready for the next admission - More even task loads, so one nurse is not carrying eight heavy patients while a colleague carries four light ones - Cleaner handovers, because the system already knows who held which patients and for how long None of this replaces judgement. A patient who looks stable on every number can still be the one the experienced nurse wants to sit closest to, and the schedule has to bend to that. The point is to remove the avoidable friction: the reshuffles that happen too late, the surges nobody saw coming, the quiet inequities in who carries the heaviest bay. ## Making it usable during a bad shift A scheduling tool that demands attention during a crisis is worse than useless. The interface has to survive the reality of a busy ward, where nobody has a spare hand to click through five screens. That means suggestions surface where staff already look, whether that is the ward board or the handover view, and it means the number of alerts stays low enough that people still read them. Integration is what makes this practical. Because the scheduling layer sits alongside the same records that drive admissions, orders, and observations, it does not ask anyone to enter data twice. The ADT feed updates the workload picture automatically. When a patient is discharged in the EMR, the bed frees in the schedule in the same moment. This tight coupling is the difference between a planning tool people use and a planning tool that gathers dust. Ward scheduling will never be fully solved, because the ward will never stop surprising you. What AI can do is shrink the window between a change on the floor and the response to it, so that the plan bends early instead of breaking late. Done well, it gives the charge nurse back the thing the job keeps stealing: a few minutes of warning.

Read article