Healthcare AI that prepares admin work for your staff to check and approve

No, the systems we build do not make clinical decisions. They prepare material for the people who do, such as a draft letter, structured referral fields or a sorted inbox. AI output appears as a draft beside its source, approval is a deliberate step taken by a named, authorised user, and the model is not asked to assign triage priority, suggest a diagnosis or recommend treatment. If a requested feature would cross that line, we flag it in discovery for your clinical and regulatory advisers.

It can be, depending on its intended purpose. Software that informs diagnosis, triage or treatment may count as a medical device in the markets you serve, for example under rules overseen by the MHRA in the UK, while purely administrative tools usually fall outside them. Classification is a decision for you and your regulatory adviser, and we ask for it before design begins. We then scope features to match and supply the technical documentation, design records and change history your adviser requests.

The clinician's notes or an existing dictation transcript are passed to a drafting service that writes the letter in your approved template and tone. Medication names, doses, dates and follow-up actions are highlighted so the clinician checks them against the notes before signing. The clinician edits and approves the letter in the provider portal, and only then is it sent or filed to the record. Edits are logged, which shows us where instructions or examples need improving.

Yes, a referral service can read letters arriving by email, portal or scan and extract patient identifiers, referrer, reason for referral, requested service and attachments into structured fields. Each field links to the sentence it came from, so booking staff can check it quickly. Urgency wording in the letter can be flagged for clinical staff, but the model does not assign a priority. Referrals that cannot be matched confidently to a patient record go to a manual queue.

Yes, if it is scoped to administrative topics and tested against clinical questions before launch. The assistant answers only from approved content such as opening hours, parking, preparation instructions and booking changes. Questions about symptoms, results or medication are recognised and met with signposting wording your clinical lead has approved, then handed to staff where appropriate. We test it with clinical and borderline questions before go-live and review transcripts regularly afterwards.

We test each feature against an evaluation set built from de-identified historical documents agreed with your information governance team and reviewed by your clinicians or senior administrators. Scores are tracked for the fields that matter most, such as patient identifiers, medication details and dates. Before go-live the feature runs in shadow mode, producing drafts that staff compare with their own work while nothing is sent. The same tests are re-run after every change to prompts, models or templates.

Patient data is processed in the cloud account and region you choose, and each AI step receives only the fields its task needs. Identifiers can be masked before a model call when the task does not require them. Hosted model calls can be routed through Azure OpenAI in a selected region under enterprise terms that exclude training on your data, and self-hosted open models are an option where data must stay inside your environment. Inputs, outputs and approvals are logged under retention rules you set.

Yes, where the record system offers an API, an HL7 FHIR interface or a vendor-approved integration route. We usually start read-only, pulling demographics, appointments or referral details for the AI service to use. Writing back, such as filing an approved letter to the patient record, is added once the read path is stable and only for output a person has approved. Vendor access approvals can take time, so we confirm integration routes during discovery.

Most clinics should start with a responsive web portal, because patients can use it without installing anything and it is quicker to launch and update. A native app becomes worthwhile when patients interact frequently, for example in ongoing care programmes, medication reminders or regular remote monitoring, where push notifications and offline access matter. Both can share one back end, so starting with the portal does not waste effort.

We provide the technical evidence your information governance team needs to complete its own data protection impact assessment. That includes data flow diagrams showing which systems and models see which fields, the hosting region, encryption and access controls, retention settings, the human review steps and how AI inputs and outputs are logged. We also complete security questionnaires and join review meetings. The assessment, its conclusions and any regulatory sign-off remain your organisation's responsibility.

Timelines depend mainly on information governance approval, record system access and how much historical material is available for testing, more than on the build itself. A focused first workflow, such as letter drafting for one clinic or referral structuring for one service, is a sensible starting point. It runs in shadow mode before staff rely on it, and further workflows follow in stages, with working software to review every one to two weeks and a named lead throughout.

The cost depends on the workflows, integrations and governance requirements in scope, and we give a fixed build quote after a discovery phase that maps them. The main drivers are the number of systems to integrate, whether patient apps or portals are part of the release, the review screens needed and hosting and security requirements. Running costs come from hosting and from model usage per document or message, which we estimate from your volumes before you commit.