Archive for category: EVMPD


Underwhelmed by the draft ISO IDMP implementation guides

I’ve been re-reading the ISO IDMP implementation guides. These were distributed for comments towards the end of last year, and we expect revised documents for the main two (covering ISO 11615 – medicinal products and ISO 11616 – pharmaceutical products) soon.

Although I’m used to reading long technical documents – the XEVMPD and UDI ones for example – I hadn’t read an ISO implementation guide before, so I didn’t really know what to expect. I found the ISO IDMP standards themselves to be very good and I think I assumed that these would be of similar quality and usefulness. Unfortunately, in their draft state at least, I must admit I was disappointed.

Why? Well basically they are a repeat of the associated standard interspersed with “this is how the HL7 for this might look”. There’s some coverage of how the unique IDs should be constructed; for medicinal products, for example, they propose a different one per marketing authorisation, legal status, product name, form, ingredients and strength, devices included in the packages and indications. (That’s quite a bit more granularity than XEVMPD.) There’s also quite a discussion about how the packaging aspects defined in the ISO standard should be shoe-horned into HL7 format. But there is much that I hoped to find in the document that just isn’t there.

So what is included in the documents?

  • The introduction says the guides are for software implementers – this is certainly true, as they very technical documents. I wonder what the EMA Implementation Guides will look like.
  • Message exchange is to be done using HL7 Structured Product Labelling (SPL) format.
  • There are useful definitions of general terms such as ‘medicinal product’ and ‘pharmaceutical product’.
  • Most of the text from the associated standard is repeated in the implementation guide. It’s not marked as such; to see what’s been added you have to read the two documents side by side; but at least this means the document stands alone pretty well.
  • The unique identifiers (MPID, PCID, BAID_1, BAID_2 and PhPID) are defined, along with details of the pieces of data that will be used to construct them. It seems that these can change fairly frequently; for example, if an ingredient of a product or its strength changes, a new MPID should be generated. This is different to how the XEVMPD works, where such changes are submitted as updates to the existing EVCode rather than as a new record.
  • There is some clarification of the coding systems to be used. For example the ISO list of countries and ISO address formats should be used.

What was I hoping to find that wasn’t there?

  • A full complement of business rules and details of ‘allowed values’. Although there are places for these in the table for each data element, they are almost all blank. There needs to be something in the guides to say which fields are mandatory, which depend on other fields, what type of data is expected/required and so on.
  • The scope, i.e. which medicinal products are to be included and at what point(s) during their lifecycles. The 11615 implementation guide, for example, allows for medicinal products that can be distributed without a marketing authorisation to be included. As it stands all medicinal products “for human use” could be covered.
  • Clarity on where the rest of the numerous controlled vocabularies and referenced coding systems are going to come from. I believe EDQM will be used where possible, but there are dozens of others that are as yet undefined. Even some suggestions or guidance on how to approach defining these would have been helpful.
  • If the unique identifiers for what is essentially the same product change frequently, how will the relationship between them be maintained? Or is it not required? From a product lifecycle point of view, MA holders will need this information, even if the IDMP database doesn’t.
  • Some meaningful examples. There are lots of HL7 XML snippets but these are often inconsistent and contradictory and do not give a real explanation of their construction. For example, in the example at the bottom of page 33 of the 11615 guide the medicinal product name contains “dihydrocodeine tartrate 30mg” but the XML representation says “<suffix qualifier=”SCI”> dihydrocodeine tartrate</suffix><suffix qualifier=”STR”> 300mg</suffix>” (the 300mg should be 30mg).
  • Some indication of which text was copied directly from the ISO standard and which originates in this document. Visibility of which is ‘standard’ and which is ‘implementation’ would be really useful.

Having written the above, I wonder if my expectations were incorrect. Despite being billed as ‘for software implementers’ these documents don’t help me much. Perhaps what I was hoping to find could only be included in a regional implementation guide that follows on from the ISO one. However if that’s the case, organisations like the EMA has a huge amount to do to implement ISO IDMP …


EMA’s QC process, the 3rd ACK and other XEVMPD frustrations

I have been following the progress of the EMA’s XEVMPD QC process and the developments around the dreaded ‘3rd Ack’ for months now, and I’ve had discussions with many people about the challenges this causes for MA Holders. The key issue is that as part of the QC process, the EMA contractors are actually changing any data that they decide is incorrect, without telling the owners of the data exactly what they have changed.

There are a number of problems with this:

  • You might disagree with the changes that EMA are making. The most common area of disagreement seems to be indications, and there are several examples of the organisation’s PV department persuading EMA that their original entry was in fact correct, and getting it changed back.
  • If your EVMPD submissions were generated by an internal database system – either a full-blown RIM system or an EVMPD tool – once they have made a change, your internal data is out of sync with theirs. You need to identify the change and make the associated update to your database, otherwise you will not be able to update anything else. However you do need to know what they changed in order to do this! This is the information that is proposed to be contained in the 3rd Acknowledgement, albeit in free text, not in any structured format.
  • Even if you agree with the change, you and your colleagues need to know what it was so that you can learn from your mistakes. Otherwise the same errors will be made in future submissions.

EMA send reports of the changes that are being made to QPPVs, however these apparently contain general guidance only, not full details of exactly what has been changed. MA Holders are left with the prospect of having to manually check every piece of data in their internal systems against that in the EMA’s system, which one organisation has estimated to be a task of at around 82 days for just over 1,000 of their products.

The industry associations are currently gathering information and views from their members in preparation for the next Article 57 Implementation Group meeting – I’ve had input into this myself – and I am well aware of the frustrations and additional work this is causing.

Also, as software developers now focused firmly on IDMP, my colleagues and I have little interest in making further complex changes to our EVMPD module – it just seems a waste of time for everyone. However, we have a saying in the UK that ‘necessity is the mother of invention’ and that’s certainly been the case here; we’ve come up with something to help with this challenge.

Samarind is developing an ‘XEVPRM Comparison’ tool to assist MA Holders with exactly this problem Andrew describes below. It takes two sets of files as inputs; your in-house generated submission files and an extract of the EVMPD data as produced by the EMA’s EVMPD export tool. It reads in both sets of files, then compares the data, field-by-field, and writes it to a user-friendly spreadsheet report. This can then be reviewed, filtered, sorted and further analysed to establish the changes that have been made by EMA so that you can decide what to do about them.

Where changes are required to the source data these would still of course need to be made manually in your in-house system, but the tool will cut out the huge amount of manual checking that you would otherwise need to do to establish where the differences lie.

The tool is scheduled for release next Friday, 27th February 2015 – and we are making it available to all EEA MA Holders completely free of charge.

It will of course be interesting to see what happens about the 3rd Ack, but in the meantime if you’re concerned that EMA is changing your data without telling you and you want an easy way to see what they changed, please email or use our enquiry form.


XEVMPD – how do we do it – part 3

Following the publication of the latest EMA guidance – which was updated again on 5th March – my previous blogs examined the five new fields that are required by the EMA and the XEVMPD data quality and controlled vocabularies. Here in the final blog of this set I’m covering local language SmPCs and timelines, and offering my opinion on the situation and how best to achieve compliance.

Read More

Get a free 30 day 'RMS On Demand' trial now!