MY USG and DICOM Workflow

MY USG and DICOM workflow: how images move from a handheld probe to a phone, tablet and patient record.

Three parts of the system

A handheld ultrasound system has three parts: the probe, the display device and the app. The probe sends and receives ultrasound signals and carries its own battery. The display device, usually a phone or tablet, shows the image and runs the app. The app controls the probe, adjusts the image, and stores the result. In the range described on this site, the app is the free MY USG app, described as compatible with iOS, Android and Windows, and images can be saved in JPG, PNG, MP4 and DICOM formats. Understanding those three parts helps a buyer see where a problem lies when something does not work: it may be the probe, the display, the app version or the connection between them.

That division also matters for purchasing. A probe bought without checking the app version, the display devices it will be used with, and the file formats the clinic system accepts, may not fit the clinic's workflow, however good its image quality. Confirm all three parts before ordering, for the exact model, because app features and file formats can differ between series.

Connection: WiFi and USB

The probes described on this site connect by WiFi, and some models also offer USB. WiFi gives freedom of movement, which suits bedside and field use, but it depends on pairing and on the wireless environment. USB gives a stable connection and a charging route, where it is offered, but it tethers the probe to the display device. A clinic should test pairing with the devices it actually uses, in the rooms where the probe will be used, before committing to a purchase, because a pairing problem found after purchase is harder to fix than one found during evaluation.

Battery management is part of the connection story. A wireless probe must be charged, and a probe that runs out of charge mid-clinic is not available, whatever its specifications. Confirm the battery specification and the charging route for the exact model, and plan charging as part of the clinic routine, not as an afterthought.

File formats and what they are for

The four file formats published for this range serve different purposes. JPG and PNG are still images, useful for a single view that can be attached to a note or sent to a colleague. MP4 is a video clip, useful where movement matters, such as cardiac motion or a dynamic examination. DICOM is the medical imaging standard, which carries the image together with patient and study information, and which can be imported into a picture archiving system or an electronic record. A clinic that needs DICOM should confirm that the model and the app version it buys actually produce DICOM files that its record system accepts, because a format listed in general terms may not be configured for a particular system.

Storage and labelling follow from the format choice. Still images on a phone are easy to lose and hard to retrieve, while DICOM files in a record system are indexed by patient and study. A clinic should decide before buying how images will be named, stored and retrieved, and who is responsible for that workflow, because a workflow decided after purchase is harder to change.

DICOM in practice

Using DICOM in practice means more than producing a DICOM file. The file must contain the right patient and study information, it must be sent to the right destination, and it must be retrievable when the patient returns. That requires the app to be configured with the clinic's DICOM destination, the network to allow that transfer, and the staff to be trained in the workflow. A buyer should ask for the DICOM configuration guide for the exact model and app version, and should test the transfer with their own record system before committing to a fleet of devices.

Where DICOM is not needed, JPG, PNG and MP4 may be sufficient, and a simpler workflow may be faster. The right choice depends on the clinic's record system and on whether images need to be shared with other clinicians or stored long-term. Do not buy a DICOM workflow that the clinic will not use, and do not buy a still-image workflow that the clinic will outgrow.

Security and updates

A phone or tablet used for medical imaging carries patient data, so it should be secured like any clinical system: with access control, with encryption where available, and with a policy for what happens if the device is lost. The app should also be kept updated, because updates can change features, fix faults and affect compatibility with the record system. A clinic should plan who updates the app, how updates are tested, and what happens if an update changes a workflow the clinic relies on. Those are governance questions, and they should be answered before the first device is bought, not after the tenth.

Troubleshooting the DICOM link

When a DICOM transfer fails, the fault can lie in any part of the chain: the probe, the app, the display device, the network or the receiving system. A systematic check saves time: first confirm that the probe pairs and produces an image, then that the app is set to the correct DICOM destination, then that the network allows the transfer, and finally that the receiving system accepts the file. Checking in that order, from probe to destination, finds the fault faster than changing settings at random, and it prevents a working part of the chain from being changed in a way that breaks it.

Common faults have common causes. A file that never arrives is often a wrong destination address, a network rule that blocks the transfer, or a receiving system that is full or offline. A file that arrives but cannot be opened is often a format or encoding mismatch, or a file that lacks the patient and study information the receiving system requires. A file that arrives for the wrong patient is a labelling fault, which is more serious than a technical fault, because it affects patient safety. Each of those faults has a different fix, and the fix should be recorded so that the next person who meets the same fault does not start from scratch.

Testing should be part of commissioning, not an afterthought. Before a fleet of devices is deployed, send test studies from each model and app version to the clinic's receiving system, and confirm that they arrive, open correctly, and are filed under the right patient and study. Repeat that test after any app update, any network change and any receiving-system change, because any of those can break a link that previously worked. A test that is done once and never repeated gives false confidence, while a test that is repeated after every change gives real confidence.

Finally, keep a fallback. If the DICOM link fails during a clinic, the examination should still be recordable, whether as a still image, a clip or a written note, so that patient care is not held up by a technical fault. The fallback should be agreed in advance, and the staff should know it, because a fallback invented during a busy clinic will be inconsistent and may lose information. A DICOM workflow with a fallback is resilient, while a workflow without one is fragile.