Yes, but only if "attach" means the photo lives inside the same scoped, signed-URL system as the rest of the patient record, not a separate cloud bucket anyone can stumble into. The two cases look similar from the doctor's side; the difference shows up the day a leaked scope image ends up in someone's Telegram group.
The pattern that works: the photo and the patient record share one access control layer. Whoever can read the consultation can read the photo, for as long as the signed URL lasts. The URL expires in minutes, not days. The photo never sits in a public S3 or Google Photos bucket with a guessable URL.
Why this is awkward with off-the-shelf tools
The default workflow for a scope-using specialist is grim. Capture frame to the SD card on the scope tower. Copy to laptop via USB or card reader. Open the photo, "save as" lesion_xyz.jpg, drop into a folder named after the patient. Email the photo to a colleague for a second opinion (so it is now in Gmail). Stick the SD card back in the tower.
That workflow puts lesion imagery in five places by lunchtime. Three of them are personal cloud accounts. One of them is a sent email. None of them are inside the patient record you started.
The shortcut tools aimed at doctors don't always fix this. Many cloud-based "endoscopy archives" are built as standalone repositories with their own login. The image lives in the archive; the patient record lives in your EMR. The two are linked by a name, which means anyone with archive access sees the image, regardless of whether they'd have access to the EMR.
The personal-cloud route (Google Photos, iCloud, OneDrive shared albums) is the worst version of this problem. The photo ends up in a bucket that Google's own services sometimes index, that sync to your phone, that get backed up by family-shared plans. The patient label on the file is your only protection.
The phone-on-the-tower route is what most specialists end up doing for speed. It is also the worst privacy-wise: phones get lost, get handed to kids, get sold with photos intact.
What good looks like, concretely
The bar is concrete enough to score against any tool you evaluate. Six criteria.
Storage is the patient record, not a parallel cloud. The image and the consultation note share one database row, or the image references the consultation in a way the same access control layer governs.
URLs are signed and short-lived. Not a permanent "https://bucket.example.com/lesion123.jpg" URL that anyone with the link can fetch for years. A signed URL that expires in five or ten minutes, and only works for the requesting user.
Per-user scoping on every read. The database query for the media row returns the image only if the requesting user is the same doctor who captured it. Per-clinic scoping (any doctor in the clinic can read any image) is also acceptable, as long as it is enforced in code, not just by UI.
No PII in the URL itself. The share link contains the patient ID, not the patient's name or phone number. A leaked link reveals a row, not a person.
Encryption at rest and in transit. Storage bucket is encrypted. The browser fetches the image over TLS. These are not exciting properties, they are table stakes, but many consumer-grade tools skip them.
Retention follows the patient record. If the consultation is deleted, the associated media is deleted in the same transaction. Orphan media files in a bucket are a privacy leak waiting to happen.
If a tool passes all six, the photo is private by construction. If it skips any of them, the photo is private by policy, which is how most leaks happen.
How to actually set it up
The setup is mostly "pick a tool that meets the six criteria, then audit the six." Two of the criteria (signed URLs and per-user scoping) are not optional; they're the load-bearing ones.
When you evaluate a tool, ask the vendor for the URL format of a stored image. If the answer is "it is a private bucket" without showing the URL structure, that is a yellow flag. Ask to see a sample URL with the bucket and key visible. The URL should contain a signature parameter and an expiry timestamp; both should be short.
Ask how access is scoped. If the answer is "your login is required to view the image," that is not enough. The question is whether the storage layer enforces the scoping or whether the UI just hides the URL. A storage layer that enforces it gives you a signed URL only after checking the database row's owner field.
Ask about retention. What happens to media when a consultation is deleted, when a patient is merged, when an account is closed? The answer should be "the media row is deleted in the same transaction." Anything weaker is orphan media waiting to leak.
The browser-side path is one way to meet all six: the consultation database row owns a media row that references the same patient ID, the storage layer issues signed short-lived URLs scoped to the signed-in doctor, and deletion of the consultation removes the media row in the same transaction. The share link contains only the patient ID, never the patient's name or phone. DrPenDown's Investigation Media flow implements this end-to-end. Capture, crop, attach, share. The privacy is built into the storage layer, not bolted on after.
Common follow-up questions
Can scope or derm photos leak even when I follow every rule above? Yes, in three ways. First, if you share the signed URL with someone outside the system (paste it into a chat), the link works for the URL's lifetime regardless of who clicks it. Second, if you export the photo with the patient's name in the filename, the export is the leak, not the storage. Third, if you back up your laptop to a personal cloud account that doesn't enforce the same scoping, the backup is the leak. The system is only as private as the weakest copy you keep.
Can I share a scope image with a colleague at another hospital? The cleanest way is a private view-only link scoped to the consultation. The colleague sees the image; they don't see the patient record unless you also share that. Avoid email attachments for the reasons in the second section. If your tool doesn't have a share-link feature, the workaround is to export the image with the patient ID in the filename (not the name), and send over an encrypted channel.
What about videos? Videos are the same shape, with a worse file size. Most scopes record short clips. A 30-second clip at scope resolution is 30 to 100 MB. Per-user scoped signed URLs work for video too, but the upload step is slower and the retention policy matters more because the file is bigger.
Does the photo sync to my phone? It shouldn't by default. Scope imagery is patient data, not personal data. Tools that "helpfully" sync everything to a phone gallery risk the phone-lost scenario. If you want a phone view, it should be a read-only app scoped to the patient record, not the device photo gallery.
What happens to the image if I cancel my subscription? The image should be deleted in the same transaction as the rest of your data, within the cancellation grace period (30 days for our service). Before cancelling, export any consultation that has attached media; the export should include the image files, not just the consultation text.
How long should I keep scope imagery? Match it to how long you keep the consultation. In India, the practical floor is the duration of treatment plus the limitation period for medical negligence claims (typically two to three years from the date of incident). Longer retention is fine if your storage is cheap and your retention policy is documented.
Related reading
- Can I crop an endoscopy image to just the lesion without Photoshop?: the capture step, same flow, before privacy is the question.
- How do I back up my clinic records so they survive a hard-drive crash?: the storage side of the same problem.
- How do I safely share a prescription or report with a patient online?: the sharing decision tree, WhatsApp vs email vs in-app.
- Glossary: Patient ID, the named term for the auto-generated short identifier that the share link contains.
- FAQ: all questions about patient privacy at an Indian OPD, every follow-up question across the privacy cluster in one place.