The use of this website to make presentations is free, within reasonable limits. Any presentation you publish (either free or for purchase) will be hosted for free. We ask that if you are not publishing your presentations, you limit your total storage usage to under 1 GB. For your reference, the White Matter Diseases presentation, published by edneurorad.com, is approximately 200 MB, including all the narrations. Usage limits are not currently enforced but we reserve the right to enforce them at any time (we will give you fair warning if you are over the usage limit). In the future, we might offer paid options for unlimited private presentations.

When you import a DICOM file for use in a presentation, it gets processed on your computer only (i.e. DICOM data does not get sent to our servers). The images and localization data are extracted and are converted to a custom format we have developed. Should you actually end up using the DICOM images in your presentation and save that presentations, this custom file (containing only the images and localization data) will be sent to our servers for storage.

We do use some DICOM header information for the automatically generated display names of the studies and series. The DICOM headers we use are exclusively limited to the study name (e.g. “MRI BRAIN W WO CONTRAST”), series number and name (e.g. “1 – FLAIR Ax”), and an anonymized study date (the study date plus or minus a random amount of time between 0 and 10 years, which changes with each session). You can change the displayed study names and series names at any time manually. We believe this level of usage would result in no usage of protected health information (provided that your DICOM file does not contain such information in the study name or series names).

Note that this does not protect against cases where protected health information is actually imprinted on the images (as happens frequently in Ultrasound images, X-rays and saved key images of cross-sectional images). It is your responsibility to ensure the images you use are free from any PHI imprinted on them (or to not use/save the individual series where this might be the case).

We think it best to use face masking if the images you use cover the entire head. This ensures protection of patient privacy, although whether 3D reconstructions of the face from CT or MRI images truly allow for patient identification is a matter of debate. We have made it easy to perform face masking using our Crop and Mask tools. You can see how to can use them to easily and quickly mask faces in this tutorial.

In general, there is no need to anonymize DICOMs first because we only process your DICOM files locally and do not store your DICOM files but rather the DICOM images converted to our custom format. We use a few DICOM headers to generate default study names and series names (specifically, the DICOM study name, anonymized study date, series number, and series name) which in our experience, do not contain protected health information (PHI). You can even change the default study or series names to any other name using our editor. Because of these, you do not gain anything as far as protecting PHI by anonymizing first.

That being said, it is always prudent to anonymize DICOM files first before you import them to a website. We recommend RSNA’s excellent DicomAnonymizerTool. If you do not like having to install Java and using the command line, you can also try the MicroDicom viewer which has an anonymization feature, although MicroDicom’s anonymization is very strict, eliminating all series names and numbers for instance.

Your in-progress presentations are private until you choose to publish them. None of the other users of our website may access them.

On our end, the title of your in-progress presentation is going to be visible to us. We do not otherwise view or monitor the contents of your in-progress presentations unless you specifically give us permission to do so (for instance, by contacting us for help with regards to that particular presentation). We reserve the right to monitor the amount of storage used by your presentations but this does not involve viewing any of the data.

When you submit a presentation for publication on our website, either as a free or purchasable presentation, we will then review all of its content in order to ensure compliance with our Terms.

At this time, you cannot do this automatically. Please contact us directly and we will be able to assist you.

Please contact us ASAP and we will be able to assist you. Amazon Cloud keeps track of all modifications you make to your presentations for the past 7 days so we can revert any inadvertent changes (whether through an error on our part or yours). Do not delay contacting us since after 7 days, we will be very limited in fixing any errors or mistakes

Basic conferencing at our website uses WebRTC (Web Real-Time Communication) to allow peer-to-peer communication between the conference participants. WebRTC is a powerful technology that enables seamless audio, video, and data sharing between web browsers and mobile applications. By leveraging peer-to-peer connections, WebRTC eliminates the need for intermediary servers, ensuring low-latency and high-quality communication. WebRTC is natively supported by most modern browsers.

We use PeerJS, a JavaScript framework that simplifies WebRTC peer-to-peer communication, making it easy to implement real-time audio, video, and data sharing. By wrapping the browser’s WebRTC implementation, PeerJS provides a complete, configurable, and easy-to-use API for establishing peer-to-peer connections.

PeerJS requires a specially designed server, known as a PeerServer, to establish peer-to-peer connections. This server facilitates the connection between peers by handling signaling and providing a unique ID for each peer. You can run your own PeerServer or use a hosted service. For more details, you can visit the PeerServer GitHub page. For basic conferencing, which is provided free of charge, we do not provide a dedicated PeerServer and you are responsible to either deploy your own or use a publicly available one at your own discretion.

WebRTC might require the use a STUN (Session Traversal Utilities for NAT) server and a TURN (Traversal Using Relays around NAT) server.

STUN is a protocol used to help devices behind Network Address Translators (NATs) discover their public IP addresses and ports. This is crucial for establishing peer-to-peer (P2P) connections in WebRTC. During a WebRTC session, STUN servers receive requests from devices to find their public IP addresses and ports. Personal data transmitted includes IP addresses and port numbers. The data transmitted to STUN servers is not encrypted.

TURN is used when direct P2P communication is not possible due to NAT or firewall restrictions. TURN servers act as intermediaries, relaying traffic between peers. During a WebRTC session, TURN servers receive data from one device and forward it to another. Personal data transmitted includes IP addresses, port numbers, and the actual data being relayed (e.g., audio, video, or text). The WebRTC protocol encrypts audio, video, and custom real-time data (e.g. mouse cursor location, state of the panels, etc) prior to relay via the TURN server. Other data, such as IP addresses, is however not necessarily encrypted.

For basic conferencing, we do not provide either STUN or TURN servers and you are responsible to either deploy your own or use publicly available ones at your own discretion.

Public and free presentations you make can be very simply embedded. We ask that you give us attribution, which can be as simple as “Presentation made with RadPPTX“. You can embed a public and free presentation by adding the following HTML to the appropriate place in your website:

<iframe allow="fullscreen" src="https://radpptx.com/presentation/head-ct-search-pattern/view"></iframe>

Just replace the src attribute with the appropriate link to your own presentation and apply your own desired styles. Private presentations can also be embedded but require the use of our advanced embedding endpoint which is described in the next FAQ topic.

Note: this answer assumes you are a web developer and familiar with basic encryption and authentication schemes.

You may use the advanced embedding features of RadPPTX to embed your private content in your own website and have complete control on who may or may not view them. You can see a fully working example here.

To use the advanced embedding features, you need to generate an RSA key-pair, make the public key available to us (via My Account > Advanced Settings) and use the private key to generate an appropriate JWT token as described below.

Embed a presentation by having an iframe point to:

https://radpptx.com/mss-embed?content_id=YOUR_CONTENT_ID&token=YOUR_JWT_TOKEN

where you replace YOUR_CONTENT_ID with the ID of the presentation you are trying to embed (available in My Account > My Teaching) and YOUR_JWT_TOKEN with a signed JWT token using your private key.

Your JWT needs to have the following payload claims:

• iat: Time at which the token was signed. This is a standard registered claim.
• exp: Time until the token is valid, which should be no more than 1 hour after “iat”. This is a standard registered claim.
• mss: A custom object with the following subclaims:
  • content_id: the ID of the presentation you are trying to embed as a string (i.e. “123”). MUST match YOUR_CONTENT_ID from the URL, otherwise your token will be rejected
  • ui_options: one of “full”, “top-right”, or “none” describing the desired amount of presentation user interface to show. “full” is the default and is how a presentation would normally appear in a RadPPTX viewer. “top-right” will only show the top-right menu (i.e. the bottom row navigation buttons will not be displayed). “none” will show no user interface. In case of “none” or “top-right”, you may perform slide navigation programmatically by sending messages to the iframe as described below.
  • slide_index: a number with the desired slide number to start the presentation on (defaults to 1)
  • accept_messages: a string. Set to “true” if the iframe should accept messages, which can be used to programmatically control navigation (see below, defaults to “false”)
  • variant: a string set to either “draft” or “published” describing which variant of the presentation or page to embed. “draft” corresponds to the unpublished private version you edit while “published” corresponds to the published version (if the presentation or page is published). Defaults to “draft”.

If you set the “accept_messages” subclaim to “true”, you may perform slide navigation (in the case of a presentation) by sending a message with following data to the iframe:

{
  command: "gotoSlide",
  slideIndex: DESIRED_SLIDE_INDEX
}

Where you replace DESIRED_SLIDE_INDEX with a number that is the slide number you want to navigate to.