Are All Medical Information (MI) Systems Really the Same?

Why do people often think they are, and what are the differences?
What questions need to be asked, and why do they matter?

Key areas of difference:

• Scalability for the future
• Links between MI and other departments
• Adverse Events, compliance and especially validation
• Configurability
• Underlying technology and required software
• Industry reputation
• Pricing structure
• Overall cost of ownership
• Hosted vs. installed

“All medical information (MI) systems pretty much do the same things – they may do them slightly differently, but they’re basically the same”.

In the nearly 20 years that NIP has been working in the pharma industry, this is one of the most common things we hear (often followed by “so, what does your system cost…?”).

On one level, of course, this statement is absolutely correct: MI systems do all aim to help companies fulfil their basic regulatory obligation to provide an MI service, and they should therefore all share some basic common capabilities, e.g.:

• Support for users logging and answering enquiries
• Co-ordination of reference materials
• Ability to provide metrics
• Security, data integrity and auditing (i.e. elements common to any decent computer system)

In this sense, at least, all MI systems are, indeed, “the same”… But, in a similar way, all houses meet basic requirements to provide protection from the elements, allow for sleeping, eating and washing, and include roofs, walls, doors, rooms, windows and amenities… and yet nobody would ever say that all houses are “the same” (or expect them to cost the same).

…we will see that MI systems are very much not all the same, and also that… the assumption that they are could have profound implications for your end-users, your customers, and for your wider organisation.

Why? Because we all know that once you look beyond the very basic shared characteristics, there are huge differences in houses’ size, age, how they’re built, who built them, the materials used, etc, etc. There are then also wider considerations – whether a house has a garden or garage, the surrounding neighbourhood and community, the convenience of its location, its tax bracket, and so on.

Perhaps most of all, though, we know that it all depends on who’s looking – a brand new one-bedroom flat may be built to perfection in a highly desirable area, but it simply won’t work for a growing family.

And so it is with MI systems, where we need to look at them in the same three main ways to understand the differences that make a difference, i.e.:

• We’ll consider how requirements and expectations of potential users vary
• We’ll look at the systems themselves: what they do, and how
• We’ll look at wider issues – or the “whole product” – and especially compliance and validation

Through the questions that come up at each stage, we will see that MI systems are very much not all the same, and also that – unless challenged – the assumption that they are could have profound implications for your end-users, your customers, and for your wider organisation.

Do Users Really Expect the Same of MI Systems?

As we’ll shortly see, there are some imperatives – such as validation and compliance – that we think must be considered, regardless of anything else. Ultimately, though, the yardstick against which MI systems will be measured is your company’s requirements, and these vary significantly.

…there are some imperatives – such as validation and compliance – that we think must be considered, regardless of anything else.

If the role of MI in your company is little more than fulfilling a basic regulatory obligation, these requirements will be very basic, too, and if all systems tick those boxes, the comparison more readily becomes one of price only. Otherwise, though, the key things to bear in mind include:

• What are you really trying to achieve? Are you simply looking to “automate” what you’re already doing? Or should a system also:
  • Deliver dramatic time savings?
  • Focus attention on enquiries most requiring expertise?
  • Make it far easier to respond to ever more informed and more demanding enquirers?
• Is your situation likely to change? How well will a given system fit in a year’s time? Or in five? Will it scale to accommodate new products, therapeutic areas, indications, and affiliates?
• What links might you need to have with other departments? What communication do you need to have with PV and Quality? Where appropriate, what communication do you need to have with the sales-force (both specific answers to questions and information about general trends)?
• Do you want to be one of the first end-users for a system, or would you be more comfortable with a more established solution?
• What experience do you have with compliance, and with validation in particular?

With that context set, we can now look at the areas and ways in which MI systems vary and you can assess their relative importance.

Do All MI Systems Do the Same Things?

Having established that all MI systems must meet several basic requirements and perform similar basic functions, how might they then vary? We believe there are two main areas of questioning here, with the first being what else the system does, beyond the basics, e.g.:

• How are “special” types of enquiry handled, such as Adverse Events and Product Complaints?
• How does the system integrate with other departments and their processes?
• Can it handle supporting multiple countries and regions – both in terms of:
  • Balancing security and sharing of data?
  • Supporting varying local workflows, languages and data (product lists, reference materials, etc)?
• Given many enquirers are increasingly working with e-mail, does the system integrate with e-mail for receiving enquiries and sending responses?
• How does it work alongside and respect existing repositories of reference materials (or not)?
• What options are there for getting key data out of the system for metrics and analysis? How does it help in presenting metrics to those assessing the effectiveness and value-for-money that the MI department is delivering to the company?
• How does it assist with reconciliation of Adverse Events and in other compliance-sensitive areas?

In our experience, answers to questions like this will already begin to show key differences, and these gaps will then widen further when looking at how a system has been built, e.g.:

• Most basically, is it intuitive? Are core tasks clearly organised and uncluttered by peripheral ones?
• Can it be configured it to use organisation-specific terminology, workflows and functionality preferences?
• Behind the scenes, what underlying technology does it use? Is that technology future proofed? Or is it a more legacy-style client-server or terminal services approach?
• Does it require additional software for either end-users, or on a server, or both?
• Does it limit or expand opportunities for where, when and how users work? e.g. Do they have to be in the office? Do they need a Virtual Private Network (VPN) connection if they’re working from home?
• Does it integrate easily with existing infrastructure (e.g. standard desktop software? e-mail?)?

…some [hidden costs] will be tangible… and some… are harder to put a figure on. [So,] bear in mind that the vendor’s ticket price is never the whole story.

Note that many of these areas can come with additional or “hidden” costs: some of these will be tangible, such as additional software costs, and some of them are harder to put a figure on. In all cases, bear in mind that the vendor’s ticket price is never the whole story.

Also note that some of these considerations aren’t primarily MI ones, but potentially involve other departments, and focus on wider issues of system ownership and usage… which leads us neatly on to looking at the areas surrounding the MI systems themselves.

What About the “Whole Product”?

The “whole product” is the solution in its widest sense – i.e. not just the system itself, but all the surrounding issues and deliverables: quality, pricing structure, reputation, consultancy, support, etc.

We’ve seen that there’s already significant differentiation between MI systems themselves; in our experience, there’s then even more differentiation in the “whole product”, and the key area is probably that of compliance and validation.

This is a large and potentially confusing topic in its own right – and will be covered in a future article – but, in addition to what the system does in these respects (how AEs are handled, audit trailing, etc), important questions here include:

• What experience does the vendor have in this area? Are they able to advise and assist with the production of validation deliverables? At what cost?
• How was the system designed and tested? Is there documentation available?
• If it is to be installed onto your network, what qualification will be performed (i.e. formal validation tests to verify the installation and operation of the system), and by whom?
• Would this system and how it’s delivered satisfy internal PV and IT colleagues’ compliance and validation requirements?

Unfortunately, in our experience, this is an area that most MI personnel have had limited exposure to – especially on the validation side – and this has several potential consequences:

• Even if MI personnel do fully appreciate the importance of compliance and validation (which isn’t always the case), they will typically be out of their depth
• As a result, they will start looking for what seems to be the cheapest solution, based on the ticket price, and either the solution doesn’t adequately address this area, or there will be hidden costs (especially if the system is to be installed onto your company’s own network, which typically introduces more validation requirements)
• PV and IT are either not consulted at all, or get involved later in the project, at which point their requirements can even be show-stoppers

Compliance and validation can be complicated areas; the key thing is to find a vendor that covers them appropriately and effectively as part of the “whole product”. Any upfront cost will pay dividends in the future, being a lot cheaper than a compliance failure downstream.

Some other “whole product” things to consider include:

• What industry reputation does the solution have? How has it performed when other companies using it have been audited?
• The pricing structure of the system, which often reflects how it is delivered. (There is a lot of difference between an installed system, purchased outright, and a rented system, hosted externally.)
• What other costs would be introduced beyond what might come out of MI’s budget? e.g. does it increase or decrease IT admin and overhead? Who maintains the system?
• What experience and consultancy is available surrounding the implementation of a new system?
• What are the ongoing costs over time, and what control do you have over them?
• Will you be locked-in to the system – because it represents a large investment, because the contracts have a minimum term, because the data can’t be readily extracted, etc – or does it leave options for the future?

When people say that all MI systems are the same… either they… have low aspirations for their department…or they’ve yet to truly analyse their requirements…

In Conclusion…

When people say that all MI systems are the same, and focus only on price comparisons at the outset, one of two things tends to be true:

• Either they are talking at the most general of levels and have low aspirations for their department…
• …or they’ve yet to truly analyse their requirements – both within MI and more widely – and grasp the differences between solutions that make a difference

Of these differences, the area of compliance and validation should be considered in all cases, due to its regulatory implications, and examining overall costs of ownership should be part of due diligence.

Beyond this, if you still find yourself tempted to think that all MI systems are basically the same, take a step back, really look beyond the functionality of the systems you’re looking at, and their apparent capabilities, and ask yourself what you and your company really care about, what you’re looking to achieve and which approach will meet those needs.

Not only will you find that the overall solutions really aren’t the same, but you’ll give yourself the best possible opportunity of making the most effective and appropriate change for your users, for your customers and for your wider organisation.

If you have a need to better understand your requirements, and/or to put together a sound business case, then get in touch, as we have a growing set of resources aimed at navigating these challenges.

 Download this page as a PDF (140KB)