Optometry is unusually instrument-dense for a practice of its size.

The RealityReadings belong in the record, not on a printout

⚠️

The Problem

Numbers read off one screen, typed into another.

Minutes per patient, every patient, plus a transcription error rate that nobody measures because nobody can see it.

🔧

The Solution

Let the instrument send the result.

A supported connection files the reading against the right patient and encounter, with the technician confirming rather than retyping.

✅

The Resolution

A lane that moves and a record you can query.

Values arrive as fields rather than images, prior exams are comparable, and the technician spends the time on the patient instead of the keyboard.

What the autorefractor actually sends

Start by finding out what you already own. An autorefractor from the last decade almost certainly has an output port, and the question is what comes out of it and in what form.

Three generations, often in one lane

Older units output a print stream, sometimes over a serial port, intended for a paper printer. Middle-generation units emit a delimited text record over serial or network. Current units generally speak a network protocol the manufacturer documents, and some publish an application programming interface. Practices frequently have all three generations in the same lane, bought at different times, which is why a single integration approach rarely covers everything.

The FDA has a name for the software and hardware sitting in the middle of this. the FDA describes these as medical device data systems, products intended to transfer, store, convert formats and display medical device data without modifying it or controlling the device that produced it. That definition is a useful boundary to hold in a vendor conversation: a system that starts interpreting or altering values is doing something different from moving them.

DICOM, imaging and the part the standards cover

Practices often assume a single standard governs all of this. It does not. Ophthalmic imaging devices, retinal cameras and tomographers commonly support DICOM, the imaging standard that also carries radiology, and that is genuinely helpful because it brings a defined way of storing and retrieving studies with patient context attached.

Refraction and tonometry readings sit outside that world. They are numbers, not studies, and the certified exchange baseline says comparatively little about them. the diagnostic imaging data class introduced diagnostic imaging test and report elements in version 2 of the national data standard, with LOINC as the vocabulary. Note what that covers: the test and the report. Not the instrument’s raw measurement values.

The practical consequence is a split approach. Imaging devices generally connect through an image archive using DICOM. Measurement devices connect through a device interface into discrete fields. Expecting one mechanism to handle both is the most common planning error we see, and it usually surfaces halfway through a project.

Device interface options and what they cost to keep

There are three broad routes, and the difference between them is mostly about who you call when it breaks.

Your EHR vendor may publish a device interface module with drivers for named instruments. This is the cleanest option when your devices are on the list, and worth checking before anything else, because practices routinely pay for capability they already own. A third-party device connectivity product sits between many instruments and the EHR, translating centrally, which is often the pragmatic answer for a mixed-vintage lane. Or a manufacturer may offer a direct connection to specific platforms, which works well for one device and does nothing for the other five.

Whichever route, the recurring cost is support rather than licence. A driver that works today can stop working after an EHR update, an instrument firmware update or a Windows change on the lane computer. Ask who owns that problem before you buy, and get the answer in writing. For a practice running several manufacturers, a dedicated interface layer usually costs less over three years than separate connections that each break independently and each need a different phone call.

Structured data versus a picture of a number

Some integrations deliver a PDF or an image of the instrument printout into the document section. That is better than paper and it is not integration.

Structured data means the sphere, cylinder, axis and pressure values land in named fields. It is what lets the record answer a question across visits: how has this patient’s intraocular pressure moved over four years, which patients have a refraction shift beyond a threshold, what did the autorefractor read before the subjective refinement. A document cannot answer any of that without somebody opening it.

The wider direction of travel supports this. the national interoperability programme has pushed toward a common baseline of data classes certified systems are expected to exchange, and standards and measurement research for health IT continues underneath it. Ophthalmic measurement data is not fully addressed by that baseline yet, but building a record on images of numbers is building against the current.

Exam workflow: the pretesting lane

The technical connection is rarely the hard part. The exam workflow around it is.

• Patient selected on the instrument, not in the chart. If the technician picks a name on the device rather than starting from the encounter, results will eventually file against the wrong person.
• No order to match against. A reading with nothing to attach to lands in an unmatched queue, and unmatched queues are only checked in practices that assigned somebody to check them.
• Repeat readings with no rule. When three measurements are taken, which one goes in the field? Decide it once rather than leaving it to whoever is in the lane.
• The technician still retypes out of habit. The most common post-go-live failure, and the reason training matters more than configuration here.

Each is a process gap rather than a technology gap, which is why a better interface does not fix them. They are worth addressing while the project is already open, because rebuilding the workflow around it later means reopening the lane a second time. Practices that also run medical eye care alongside routine vision should scope this with their ophthalmology EHR and IT work in mind, since the imaging side is shared.

What to ask before you commit

Four questions separate a working integration from a demonstration. Ask your EHR vendor for the supported device list by model, not by brand. Ask each instrument manufacturer what the unit outputs and over which port, and ask for a sample record rather than a brochure. Ask who supports the connection after an update on either side. And ask internally who owns the unmatched queue, by name, before go-live rather than after the first missing reading.

Qventive provides optometry instrument integration support in New Jersey as part of our optometry EHR and IT support and a broader optometry practice management engagement. Because every one of these connections moves identifiable clinical data across a network in the building, the design belongs in your HIPAA risk analysis alongside the clinical plan, not after it.

Instrument integration: common questions