Home / Insights / NHS and community

Virtual wards point of care testing: what works in the home

NHS and communityPublished 2026-09-0810 min readUnited Kingdom

What point-of-care testing looks like when the ward is a patient's living room: the tests that are realistic, the things that break outside a clinic, the governance that still applies, and how a managed phone can replace the docking station.

Written and reviewed by the Catenix team. How these guides are written and checked.

In brief

  • A virtual ward, which NHS England also calls hospital at home, gives a patient hospital-level care at home for a short acute stay, with daily review by a multidisciplinary team and a mix of remote monitoring and home visits.
  • The point-of-care tests realistically run on virtual wards are INR, glucose and ketones, CRP, haemoglobin and urinalysis, alongside connected vital-signs devices; blood gases and HbA1c are uncommon at home.
  • What breaks at home is not the test but the setting: no fixed network, no wristband, results stranded on a handheld until it is docked, controls travelling in a car, and rotating community staff whose competency the laboratory cannot see.
  • ISO 15189:2022 Annex A and the MHRA guidance apply in the home exactly as they do on a ward, so a virtual ward should be set up as a POCT site with its own device register, operator list, QC and EQA records.
  • A phone-as-gateway approach lets a managed staff phone receive the result from the analyser at the bedside, attach patient and operator identity, store it encrypted and forward it to the laboratory system and the patient record when a connection is available.

Take it with you: POCT readiness checklist · POCT connectivity buyer's guide (PDF, no form).

What virtual wards are

A virtual ward, which NHS England also calls hospital at home, lets a patient receive hospital-level care at home instead of in a bed on a ward. NHS England's virtual wards page describes the model: a multidisciplinary team reviews the patient daily, some of the monitoring is done remotely using connected devices and an app or a phone call, and some of it is done face to face by a nurse, paramedic or doctor who visits the home. The stay is short and acute, typically a matter of days, with the patient either recovering and being discharged or being stepped up to hospital if they deteriorate.

The common pathways are frailty, acute respiratory infection and heart failure, with some services covering post-surgical recovery and children. Virtual wards are commissioned by integrated care boards (ICBs) and run by acute trusts, community providers or both together. NHS England's supporting information for integrated care system leads on virtual wards, including hospital at home, sets out the enablers: workforce, technology, governance and clinical leadership.

What matters for this article is a simple point. A patient on a virtual ward is unwell enough to have needed a hospital bed. The clinicians looking after them make the same decisions they would make on a ward, and they need the same information to make them, including blood results.

Why near-patient testing in the home matters

On a hospital ward a blood sample goes to the laboratory and the result is back in an hour or two. At home, a sample taken on a morning visit goes into a cool bag, back to base, then by courier to the laboratory, and the result is available that evening or the next morning. The daily review happens on yesterday's numbers, or the visit is repeated, or the decision is made without the result. Near-patient testing, also called point-of-care testing (POCT), closes that gap for a small number of tests that change what the team does today.

The realistic list is shorter than the list of tests that exist in a portable format. Blood gas and electrolyte cartridge analysers are used by a few services, but the sample handling and calibration requirements make them uncommon in the home. HbA1c is a planned-care test and rarely needed in an acute stay. What is actually run on virtual wards falls into a few categories.

  • INR. International normalised ratio for patients on warfarin, which frail and heart failure patients often are, so that dosing can be adjusted at the visit.
  • Glucose and ketones. Handheld meters, already familiar to community staff, with the extra requirement that the result reaches the ward record rather than staying on the meter.
  • CRP. C-reactive protein on a small analyser or a cartridge, used by respiratory infection pathways to support the review of a patient's progress over the stay. This article says nothing about what a value means; that is a clinical matter covered by the service's own protocols.
  • Haemoglobin. A single-cuvette haemoglobin meter where anaemia is part of the picture.
  • Urinalysis. Dipstick testing, read visually or on a small reader, in the frailty pathway.
  • Connected vital signs. Pulse oximetry, blood pressure, temperature and weight from devices left with the patient, feeding a remote monitoring platform. These are not in vitro diagnostic (IVD) tests but they share the same identity and connectivity problems.

Each of these is straightforward on a clinic bench. The difficulty is the setting.

What breaks at home versus in a clinic

The problems below are the ones POCT coordinators report when a hospital extends its testing into patients' homes. Each has a clinic answer that stops working once the analyser goes into a bag.

ItemIn a clinicOn a virtual ward
NetworkWired or trust Wi-Fi; the analyser docks and uploadsNo fixed network. Mobile data varies by postcode and the patient's home Wi-Fi is not normally acceptable for clinical data
Patient identityWristband barcode scanned at the deviceNo wristband. Identity is confirmed verbally against the ward list, and two people in the same household may both be patients
Operator identityOperator badge scanned, list managed by the laboratoryRotating community and bank staff, often employed by a different organisation from the laboratory
Result captureResult sent to the laboratory information management system (LIMS) automatically on dockingResult stays on the handheld until it is docked hours later, or is written down and phoned in
Quality controlControls stored in a monitored fridge, quality control (QC) run each morning on the benchControls travel in a car. Temperature excursions go unrecorded and QC is skipped when the visit runs late
Reagent storageStock room with lot and expiry trackedStrips and cartridges in individual staff bags, lots mixed, expiry unchecked
Device custodyDevice lives on a bench with a service scheduleDevice is one of several in a pool, moves between staff, and may be lost
DowntimeSend the sample to the laboratoryRepeat the visit, or decide without the result
SupervisionPOCT coordinator walks the wardCoordinator cannot visit the homes and relies entirely on what the system records

The last row explains most of the others. In a clinic, a coordinator can see problems by being present. On a virtual ward, if the software does not record it, it did not happen as far as governance is concerned.

Governance does not stop at the front door

The governance framework does not change because the test is done in a living room. ISO 15189:2022 Annex A makes the host laboratory responsible for point-of-care testing it supports, wherever it takes place, and the Medicines and Healthcare products Regulatory Agency (MHRA) guidance Management and use of IVD point of care test devices applies to any organisation using IVD devices outside the laboratory. A virtual ward should be treated as a POCT site in its own right, with its own entry in the device register, its own operator list and its own QC and external quality assessment (EQA) records, all visible to the laboratory and reported to the POCT committee.

Some points need particular attention.

  • Which laboratory. A virtual ward run jointly by an acute trust and a community provider must name one accountable laboratory. The community provider's staff become operators under that laboratory's policy, however they are employed.
  • Competency. Community staff rotate, use bank and agency cover, and may use three or four device types. Competency needs to be held against the person and the device, with an expiry date, and checked by the device or the software before a patient test is allowed. Our operator competency page describes how that lockout works.
  • QC on mobile analysers. The policy should say where controls are stored, how often QC is run, what happens to a device that has been in a hot car, and how a failed QC locks the device until it is resolved.
  • Lot traceability. Every result should carry the strip or cartridge lot, so that a field safety notice can be matched to the patients affected.
  • Information governance. Results are patient data crossing between the home, a phone, the provider and the laboratory. The data flow needs a data protection impact assessment, encryption in transit and at rest, and a clear rule that results are never sent through consumer messaging apps or personal email.
  • Lost devices. A handheld with results in its memory is a data breach if lost. The procedure should cover remote wipe where the device supports it and a register of what was on it.

How a phone-as-gateway approach works

In a hospital, the analyser docks into a base station on the network and the base station forwards results to the middleware. That model assumes a fixed network and a fixed location. A phone-as-gateway approach replaces the base station with an application on a managed smartphone that the visiting clinician already carries. The sequence is as follows.

  1. The clinician signs in to the application on the phone. That sign-in is the operator identity for the record, and the application checks that the person is competent on the device about to be used; the service should also validate that the authenticated user is the person who ran the test, for example by using the analyser's own operator ID where the device supports one.
  2. The clinician selects the patient from the virtual ward list, which carries the verified NHS number, and confirms identity with the patient in the usual way.
  3. The analyser is paired to the phone over Bluetooth, or connected by cable where the device has a serial or USB port. The phone receives the result in the device's own protocol, whether that is POCT1-A2, ASTM or a manufacturer format.
  4. The application attaches the operator, the patient, the device serial number, the lot and the time stamp, encrypts the result and stores it on the phone.
  5. When mobile data is available, which may be immediately or may be in the car afterwards, the stored results are forwarded to the platform and removed from the phone once receipt is confirmed.
  6. The platform validates the result, checks the device's QC status, and delivers it to the LIMS, the electronic patient record (EPR) and, where agreed, the patient's GP record. The reviewing clinician sees it on the ward board within minutes rather than at the next docking.

The same route carries QC results, so the laboratory sees whether QC was run before the patient test and on which device. The gateway can also read connected vital-signs devices, which puts blood pressure and oximetry readings alongside the blood results with the same identity attached.

For this to be safe, the phone must be managed by the organisation with mobile device management, the application must require authentication and hold no unencrypted patient data, and the store-and-forward behaviour must be tested for the case where a phone is offline for a whole shift. What is POCT connectivity? explains the underlying messaging in more detail.

What to specify when buying

Whether the service is buying analysers, connectivity or both, these are the points to put in the specification. Each one maps to a row in the table above.

  1. Every result must be captured from the analyser electronically, with no manual entry of the value, and must carry the operator, the patient's NHS number, the device serial, the lot and the time.
  2. Results must be transmitted from the home, or stored encrypted and forwarded automatically when a connection is available, with confirmation of receipt and no duplicates.
  3. The system must prevent a patient test by an operator whose competency on that device has expired, and record the attempt.
  4. The system must prevent a patient test on a device whose QC has failed or is overdue, and record the reason for any override.
  5. QC results must be captured automatically, plotted, and reviewed against Westgard rules, with all devices in the pool visible to the laboratory.
  6. Each device must be registered with an EQA scheme, and the schedule of EQA samples must cover devices that are out in the community, not only those at base.
  7. Lot and expiry must be tracked at the level of the individual device or staff kit, with a recall report that lists affected patients.
  8. Phones must be organisation-managed, with remote wipe, and the application must hold no patient data in clear text.
  9. Results must be delivered into the LIMS and the EPR as structured results, and the vendor must show which messaging standards are supported and what the local integration team needs to do.
  10. The audit trail must show every result, QC event, override and operator change, and must not be editable.
  11. The downtime procedure must be documented and tested before go-live, including what the clinician does when the phone, the analyser and the network all fail on the same visit.

Where software helps

POCT middleware exists to solve exactly the problems in the table: it takes results off the analyser, attaches identity, applies QC and competency rules, and puts the result into the record. For virtual wards the extra requirement is that it works without a fixed network and without a base station. Catenix does this with its Pocket Gateway, which turns a managed staff phone into the analyser and Bluetooth gateway described above, with an encrypted offline spool that forwards results when a connection returns. Results are delivered into the LIMS and EPR over HL7 v2 or FHIR, and the platform is designed and ready to connect to EMIS Web and SystmOne over the same open standards. The QC module captures control results from the same route, so the laboratory sees the QC status of every device in the pool without collecting them in.

The rest of the governance, operator competency with lockout, lot traceability with recall reports, EQA scheduling and a tamper-evident audit trail, is the same as for any other POCT site. The community and distributed diagnostics page covers how a laboratory supports sites it cannot walk to. Whatever product a service chooses, the specification in the previous section is the test to apply.

Questions people ask

What point-of-care tests are used on virtual wards?

The tests that change a decision on the day of the visit. In practice that means INR for patients on warfarin, glucose and ketones, CRP on respiratory infection pathways, haemoglobin and urinalysis, plus connected vital-signs devices such as pulse oximeters and blood pressure monitors. Blood gas and HbA1c testing are uncommon at home. The service's own clinical protocols decide which tests are used and how results are acted on.

Does a virtual ward need a POCT coordinator?

It needs to be covered by one. The host laboratory's POCT coordinator should treat the virtual ward as a testing site, with its own device register, operator list, QC and EQA records. Because the coordinator cannot visit the homes, they depend on software to show them what has been run, by whom, on which device, and whether QC was done first.

How do results from a handheld analyser used at home get into the hospital record?

Either the device is docked when the clinician returns to base and the results upload then, which can be hours later, or a gateway application on a managed phone receives the result from the analyser at the bedside, attaches the patient and operator, and forwards it over mobile data. The second route delivers the result to the LIMS and electronic patient record within minutes and works offline by storing results encrypted until a connection returns.

Can staff use personal phones as a gateway for point-of-care analysers?

It is not advisable. The phone handles patient data, so it should be owned or managed by the organisation, enrolled in mobile device management, protected by authentication and capable of remote wipe. The application should hold no patient data in clear text and should remove results once the platform confirms receipt. A data protection impact assessment should cover the whole flow from home to record.

How is quality control done on analysers used in patients' homes?

The same way as in a clinic, with more attention to storage and capture. Controls need to be kept within their temperature range, QC needs to be run on the schedule the policy sets, and the results need to be captured electronically and charted so the laboratory can see them. A failed or overdue QC should lock the device until it is resolved. Software that records QC through the same gateway as patient results makes this visible.

Sources and further reading

Take it with you

The buyer's guide, in your inbox.

Nine pages on what POCT connectivity is, the standards in plain English, the cost of doing it by hand and eight questions to ask any supplier.

Get the POCT connectivity buyer's guide

Nine pages, vendor-neutral: what connectivity is, the standards in plain English, the cost of doing it by hand and eight questions to ask any supplier. The PDF also opens directly from the downloads page; leave an email only if you want it in your inbox.

We use your email only to send the guide and, if you ask, to follow up once. No newsletter unless you tick the box. See our privacy notice.

Thank you. The guide is on its way. You can also open it now.
That did not send. Open the guide directly or email contact@catenix.com.

See it done in software.

A 30-minute walkthrough on a live tenant, with your analysers and your allowable-error limits.