Healthcare becomes data-driven and personal.

Clinical AI touches the patient case itself: it reads medical material or shapes a treatment decision. Administrative AI organizes the work around the case, including rostering, capacity, coding and correspondence. The split decides which oversight applies. Software that processes patient data for a medical purpose is normally assessed as a medical device, even when it only flags a concern. Only pure reference lookup that does nothing with the patient record sits outside that regime. Settle the classification before you build, not after.

Start with a bottleneck that is already measured and where a wrong output is caught before it reaches a patient. Waiting list planning, no-show follow-up and drafting documentation are common first steps, because staff see the result and can correct it on the spot. Before deployment, agree who reviews the output, what happens when the system is wrong, and how you fall back to the previous process. Also agree who owns the model after go-live, because unowned systems degrade quietly.

You need a defined dataset with known provenance: who recorded it, under which definition, over which period, and on what legal basis it may be used for this purpose. You also need recorded outcomes, meaning what actually happened to the patient, because without them a model can be neither trained nor validated. On the governance side, expect a documented purpose, a risk assessment, arranged human oversight and a register of the model versions in use. How much data you need varies widely, because imaging models remain data-hungry. In our own projects, coding differences between departments cause more trouble than volume.

The accuracy figure at the top of this page describes model performance on a curated dataset, not value in daily practice. Read any such number with its context: which condition, which population, and whether it was measured prospectively. Then evaluate against the outcome you set out to improve, such as time to treatment, unnecessary referrals or documentation time per clinician. Compare with a similar period or unit without the system and repeat the measurement, because populations and recording habits drift. Track override behavior too: when clinicians routinely ignore the output, the system does not fit the workflow.

The most common mistake is validating a model only on data from the site and period where it was built, then being surprised when performance drops elsewhere. Populations, devices and recording conventions differ. Two further pitfalls are alert fatigue, where so many notifications are generated that staff dismiss them by reflex, and treating go-live as the end of the project, leaving nobody responsible for monitoring drift, retraining or withdrawal. Plan for maintenance, and for the ability to switch the system off.