Sharing Cone-Beam CT Images Online

By Dr. Dan Grauer

When diagnosing and treatment planning interdisciplinary patients, have you ever sent your three-dimensional images to a colleague? Have any of your patients requested a copy of their records for a second opinion? Or maybe, a patient declines a radiograph because another orthodontist has recently taken a CBCT image of the patient? In all of these instances, you will need to communicate with the other office to initiate the transfer of CBCT images. The purpose of this blog is to describe different methods used to share patients’ CBCT records via online means.

Images acquired in your office are requested by a second orthodontist/dentist:

The first question that will need to be answered is whether the other office has the possibility of viewing and analyzing the images in three-dimensions. In a few instances, I have found myself trying to transfer a full three-dimensional file, when the second orthodontist just wanted a cephalogram and a panoramic radiograph. If this is the case, your software will probably allow you to create a synthetic cephalogram and panoramic radiograph that can be emailed through a HIPAA-compliant email account. If the second orthodontist requires a three-dimensional image, two case scenarios are possible:

Case scenario 1: Second orthodontist owns software to read and visualize CBCT images.

In this case, your software is able to export the CBCT Images in DICOM format (Digital Imaging and Communication in Medicine). DICOM files are large, and a file transfer application is needed. Once transferred, these can be imported into the software of the second orthodontist for visualization and analysis.

Case scenario 2: Second orthodontist does not own three-dimensional imaging software.

Under this case scenario, the second orthodontist would need both the CBCT images and a three-dimensional viewer. Three main options are available.

Option 1: If you own a CBCT machine, your software is generally able to create a file that includes both the image data and a basic viewer. The files created are large and can be transferred with a file transfer application.

Option 2: Anatomage offers the possibility of uploading your CBCT images to the cloud, and these can be accessed online through Anatomage’s application, which acts as a visualization tool. At this point the software is in Beta-version and can be accessed at You, as the generating office, will need to upload the images to the AnatomageCloud database and use this application to allow the second office to access the specific patient images. The access is granted with a link embedded in an email. After receiving authorization to access the images, the second office will be able to access the images online without the need of downloading them or installing any software.

Option 3: Dolphin Imaging software offers a complimentary viewer, The receiving doctor can view 3D images by downloading and installing the Dolphin Imaging Viewer software. Files are transferred in DAZ file format. This file format is proprietary to Dolphin Imaging, and the files are created by the originating doctor through Dolphin Imaging 3D Software. This option 3 would work also in Case Scenario 1, when both doctors use Dolphin Imaging 3D software, but it is important to note that only the unprocessed images need to be transferred, such as the DICOM file; the viewer is part of the software downloaded by the receiving office.

Images acquired by other offices:

Images that you receive from other offices should be requested in DICOM format. This will permit you to be able to import these into your 3D software. If you obtain the file in a different format than DICOM (that often includes the viewer), the analysis and measurement possibilities are limited; this is because your 3D software most likely includes all the features that you may need while visualizing and measuring 3D Images. If both offices use Dolphin Imaging 3D Software, a proprietary format DAZ can be used to transfer and share images. The advantage of this approach is that all patient images, including both 3D and 2D images, are shared simultaneously.

In summary, with Cone Beam CT becoming more popular in practices, sharing 3D images with other treating doctors or practices requires some additional steps. The first step is to initiate the conversation with the second office to establish the best system to use to share images. The advantages of 3D images over traditional 2D images are beyond the scope of this blog, but once you become accustomed to a transfer and visualization system, the collaboration between doctors and patient care may improve.

HIPAA: Encryption is NOT Required…What?!?

By Charles E. Frayer[1], JD, MS, HCISPP, CIPP, CIPM

No, that headline is not a misprint. Contrary to common assumptions—and what many email encryption providers may tell you, Congress, in its infinite wisdom (stop laughing, please) decided that the Health Insurance Portability and Accountability Act (HIPAA) should not—and, therefore, it does not—require the use of encryption to secure your patients’ private medical data (aka, electronic Protected Health Information or ePHI).


Required vs. Addressable: What’s the Difference?
In HIPAA, Congress adopted two types of implementation specifications—“required” and “addressable.” Those labeled “required” must be implemented or it will be deemed an automatic failure to comply with the HIPAA Security Rule. On the other hand, those labeled “addressable” must be implemented only if, after a risk assessment, the covered entity (that’s you, if you’re a Health Care Provider, a Health Plan, or a Health Care Clearinghouse) has determined that encryption is a reasonable and appropriate safeguard for managing risks to the confidentiality, integrity and availability (CIA) of ePHI. A brief sidebar about the CIA triad: confidentiality protects against unauthorized disclosure; integrity protects against unauthorized modification or destruction; and availability protects against disruptions to access and use of ePHI. Okay? Now, back to our story…

However, if you determine that encryption is not reasonable and appropriate (think about this carefully), then you must document your rationale for that decision and do one of the following: (a) implement an equivalent alternative to encryption that is reasonable and appropriate; or (b) if safeguarding ePHI can otherwise be achieved, then HIPAA even allows you to choose not to use encryption or any equivalent alternative measure, provided that you also document the rationale for this decision.[1] Shocking, isn’t it? Yes, Congress effectively (is that an oxymoron?) allows you to do nothing, provided you can and do back it up.

Now, if you’ve thought about that carefully, you’re probably wondering something like, “What if HHS audits me and they don’t agree with my carefully documented rationale for deciding that encryption is not reasonable and appropriate to protect my patients’ private medical data?” Perfect question! And therein lies the problem. It is difficult (impossible?) to even imagine a situation for which it would be “reasonable and appropriate” to decide not to use encryption to protect ePHI (remember, that lowercase “e” stands for “electronic”). So, even though HIPAA does not literally require encryption, it effectively requires encryption because there is no reasonable and appropriate alternative for protecting ePHI.

In other words, when it comes to using encryption to protect ePHI, there is little (if any) difference in Congress labeling it as “addressable” rather than “required” because not using encryption is simply too risky for your patients’ ePHI and, therefore, even riskier for your business.

Encryption: HIPAA’s Data Breach Safe Harbor
Under the HIPAA Breach Notification Rule, there are essentially two types of ePHI—unsecured (i.e., unencrypted) and secured (i.e., encrypted). Under HIPAA, every breach of unencrypted ePHI requires you to provide time-bound notifications to: (1) affected patients; (2) the Secretary of HHS (i.e., the federal government); and/or (3) prominent local/state media outlets. This, of course, will put you at risk of federal and/or state investigations, fines, possible lawsuits, and the worst kind of public relations disaster imaginable, which will almost certainly result in lost business.

But there is good news…no…GREAT NEWS!!! Under the Breach Notification Rule, encrypted ePHI that is “breached” (e.g., lost, stolen, or accidentally/intentionally sent to the wrong recipient) is not considered a breach at all because ePHI that is encrypted cannot be read or otherwise used without the key(s) required to decrypt it. Consider some of the risks of emailing your patients’ ePHI unencrypted versus sending it via encrypted email, as follows:

Screen Shot 2016-02-18 at 4.27.19 PM

So, if you use it, encryption is your lawful HIPAA-endorsed safe harbor against everything you want to avoid in the event of a breach of ePHI. Going back to our previous segment, even if you somehow came up with that rarest of all situations—where using encryption to protect ePHI was not reasonable and appropriate, you still need to use it because doing so gives you a complete “out” when the worst of all possible ePHI scenarios—a data breach—occurs (i.e., you get to simply walk away).

In summary, although HIPAA does not literally require encryption, Congress nonetheless has effectively mandated its use because (i) it is all but impossible to think of a real-world situation where encrypting ePHI is not reasonable and appropriate; and (ii) if you choose not to use it, you are exposing your business to a plethora of regulatory, legal, public relations, and/or financial risks that are easily avoidable—by simply using encryption.

[1] Charlie Frayer is a Michigan licensed attorney and Florida Authorized House Counsel serving as General Counsel and Chief Privacy Officer at Protected Trust, LLC, the leading provider of Simple Email Encryption with 24×7 free and unlimited support via phone, email, and chat.

[1] See: 45 CFR § 164.306(d)(3) detailing the difference between “Addressable” and “Required” implementation specifications at;

45 CFR § 164.312(a)(2)(iv) labeling encryption and decryption as “Addressable” at; and
the HHS HIPAA Encryption FAQ at