Everything you need to know about qDialogue (IQVIA Remote e-Detailing)

So, what is qDialogue?

qDialogue is IQVIA’s cloud-based platform enabling the remote presentation of Digital Sales Aids (DSA) to customers. If you’re wondering who IQVIA are, in November 2017 QuintilesIMS rebranded following a previous merger between IMS Health and Quintiles.

Why use it?

qDialogue has all the benefits of traditional e-detailing, such as:

  • More engaging content than static PowerPoint presentations
  • Capturing of analytics and usage metrics
  • Greater control over approval process and release of content

However a remote DSA-based presentation can be delivered to multiple HCPs, in different locations, simultaneously by a single representative. Remote detailing can reduce travel time for representatives as well as providing greater reach to field based HCPs and an alternative communication channel to any HCP with limited availability.

Who is it optimised for?

Local brand teams are the primary users of the remote detailing application in conjunction with the HCP, who has somewhat more engagement than in a passive face-to-face meeting. The data generated will be manipulated by the business intelligence team and used by salesforce management, marketing and strategy teams.

Is it integrated with IQVIA’s CRM/CLM solution MI Touch?

As with Veeva’s equivalent system, Engage for Portals, the slides used are built using HTML, so to some extent, existing MI Touch e-detail presentations can be recreated in qDialogue. Unlike Veeva CLM and Veeva Engage for Portals, however, there are fundamental architectural differences between MI Touch and qDialogue meaning content cannot be simply ported between them. Significant cost savings can be made if developers know in advance that the presentation will be dual-targeted, so it is always worth planning ahead if you can.

MI Touch does not support the sharing of reusable elements in a single source file meaning changes to a standard element need to be repeated individually in every file throughout the entire DSA. Conversely, qDialogue shares everything in one place.

If developers know at the beginning of a project, then they can develop an automated build process to take a single common set of source materials and convert them into either MI Touch (no shared content, fixed sizes) or qDialogue (shared content, resizing), meaning a relatively small additional initial outlay will greatly reduce the overall cost of the wider development project.

How is it delivered?

As with MI Touch, IQVIA recommend using separate slides for each element of a presentation. However, in this case, it is to allow their remote detailing wrapper to list out an index of all the slides to allow the presenter to quickly navigate around the presentation.

It is still possible to include navigation within pages using regular anchor tags. However, this highlights some limitations: each file is still discrete, transitions between slides are not seamless and there are restrictions as to how fluid the presentation can be.

Furthermore, as there is no way to break content down into sub-presentations, i.e. every slide appears in the index, it might be better to build multiple smaller presentations rather than trying to put everything into a single oversized, cumbersome presentation.

an index of slides in qDialogue

What is the output?

The result of the developer’s efforts will be a series of zip files containing each slide of the presentation, linked together if required, which are then sent to IQVIA for installation.

Are there any limitations?

Unfortunately, yes. As with all DSAs, there is an element of compromise required in some areas.

  • MI Touch and qDialogue being separate systems means having to maintain two different build pipelines or even two totally discrete DSAs. This can result in higher maintenance overhead, as for example, simply updating a logo (e.g to remove the black triangle) would entail running two separate build and QA processes.
  • The size of a presentation is limited by what can be reasonably listed in the wrapper index structure, or what can be coded in manually as a navigation mechanism.
  • The names of the packages displayed in the wrapper index are very short and as such, care needs to be taken for them to be understandable to the user.
  • The numbering of slide packages is a requirement from qDialogue, further reducing the characters available.
  • The qDialogue wrapper itself does not resize. It is necessary to break out code in order to achieve a responsive design suitable for display on different size screens as found on the desks of various HCPs. This break out code could be broken at any point by IQVIA performing a change to the qDialogue architecture.
  • Use of videos is discouraged as there are some concerns that the wrapper may not always handle them effectively and streaming to tablet devices can be a concern. Where videos are used, it is strongly recommended to use only one video element per page and not to use separate sound and video elements.
  • In general, frameworks such as Edge should not be used as they add further complexity inside the qDialogue iFrame based wrapper.
  • The chances of screen readers and other accessibility aids working nicely with the qDialogue wrapper are slim and should be tested thoroughly if a requirement of the project.

What are the benefits?

The benefits derived from using e-detailing are intrinsically linked to the ability to increase the reach to new HCPs and structure presentations in a manner amenable to the qDialogue wrapper.

Need to know more about qDialogue?

twentyeightb are certified IQVIA partners on the MI Touch platform and can advise on any aspect of delivering content. Our experience of working with both agencies and brand teams to deliver e-detailing projects is substantial, so if you are looking for more information on qDialogue or any other CLM platform, we would be happy to help so why not get in touch?

Starting out with MI Touch (Nexxus)

Whether you’re inheriting a pre-determined platform to deliver your digital sales aids, or you’ve made a pro-active choice to utilise new software, you may be surprised to find the number of CLM solutions on the market. Here we introduce MI Touch.

What is MI Touch?

QuintilesIMS have an offering in the commercial space for brand teams looking to effectively enable e-detailing within their field force. MI Touch (previously Nexxus) is a similar platform to Veeva, allowing for delivery via an iPad of HTML based slides from a cloud-based technology solution. The backend system is based on a Microsoft stack while the front end is written using Apple developer tools.

Why use it?

If asked to deliver a brand digital sales aid (DSA) to the MI Touch system, the first questions are as ever; what content is required and why has an e-detailing aid been determined to be the best fit solution? For example:

  • More engaging content than static Powerpoint presentations required
  • Capturing of analytics and usage metrics
  • Greater control over approval process and release of content

MI Touch supports all of the above objectives but it is important to identify up front the direction in which to take the deliverable to avoid unnecessary cost and delay.

Who is it for?

Local brand teams are the primary users of the MI Touch application. The data generated will be manipulated by the business intelligence team and used by salesforce management, marketing and strategy teams.

How to deliver within the platform

In general a MI Touch project will require the developers to first build a framework and then create separate individual HTML5 pages for each slide within the presentation deck.

As each slide is essentially standalone but users need a way to move through the presentation, it is important to identify the overall structure of the site. Determining the common elements up front is also a valuable exercise. MI Touch does not support the sharing of reusable elements in a single source file and therefore if a standard element is changed this can lead to a ripple effect where multiple files have to be changed even if it is the same change to every file.

IMS recommend using separate slides for each element of a presentation as this allows their native tracking function to record the progress through a meeting without requiring any bespoke code to be developed. However this does lead to the issue mentioned whereby common content becomes time consuming to change.

The MI touch platform broadly parallels Veeva, however, it does have limitations with respect to memory management which need to be respected. In addition transitions between slides when controlled by MI touch are not seamless, which needs to be taken into account if there was the intention to create a particularly good interactive or flowing presentation. In these instances it might be better to build the presentation into a single file and manage the content directly.

Leave behinds can be handled by adding a PDF to each slide, this can then be sent to the healthcare provider (HCP).

Outputs

The result of the developer’s efforts will be a series of zip files containing each slide of the presentation, linked together in such a way as to allow the field force to present in either a one-dimensional linear progression or, potentially, in a more two-dimensional approach with both “deep” and “wide” elements.

The benefits of MI Touch

The benefits derived from using MI Touch are intrinsically linked to the original project goals but you can realistically expect greater visibility of detailing and an ability to use segmentation and prioritisation to target HCP visits.

Limitations

Shared content/assets have to be duplicated into every single slide (i.e. they aren’t actually shared) and therefore there can be:

  • A higher maintenance overhead (changing a logo would entail manually updating every slide package)
  • A bigger initial development overhead (developing a build process which is able to integrate shared content into every package automatically)
  • Layout is limited by the touch areas in MI. It is recommended not to have any interactive content in Zones 1, 2, 3 or 5 as these zones conflict with the built in MI Touch functions

nexxus content areas

mi touch zones

utilising mi touch gestures

  • Use of videos is discouraged as the MI Touch developers advise that memory management can be a concern. Where videos are used IMS strongly recommend only one video element per page and no use of separate sound and video elements.
  • In general, frameworks such as Edge should not be used as they are too heavy to run within the MI Touch application. In fact, IMS recommend minimal use of Javascript and only having a single index.html page for each slide with no navigation away from it.

We can help

twentyeightb are certified IMS partners on the MI Touch platform and can advise on any aspect of delivering content. If you’re interested in finding out more about how we can work in partnership with agencies and brand teams alike, why not take a look at our case study video? If you want to chat MI Touch, just drop us a line today by phone or our contact form.