The NHS (NPfIT) Messaging Implementation Manual (MIM)

open forum
, ,
1

I recently started off on a slightly daft odyssey to understand a bit more about the technical underpinnings of GP2GP. In the process I found that the current state of the Messaging Implementation Manual (MIM), which contains the GP2GP spec, is absolutely insane.

Older versions of the MIM are online only in the National Archives (although the standards represented there are still VERY MUCH live and in use across the NHS - for example GP2GP is how GP records are transferred between system suppliers in England). The most recent version of the MIM is available via the TRUD (I have previously made my opinion about the TRUD quite clear)

[EDIT: My error, it’s not on the TRUD, it’s here: https://digital.nhs.uk/developer/guides-and-documentation/message-implementation-manuals]

This has led the NHS’s technical standards community to the somewhat perverse position that the only version of the MIM that isn’t viewable freely on the Internet is the latest one!

So. On a bit of a side-quest, and ably assisted by my personal ‘Sancho’, I have published a web-based version of the latest MIM.

The whole lot of it is a total mess of HTML frameset garbage, but thanks to browser backwards-compatibility it does mostly just work as raw HTML in GitHub Pages.

I’m not sure who this might help, but in a way it does at least make it easier for LLMs to access, in case anyone wanted to (ahem) do something dumb like try to write an open-source GP clinical system.

Sancho provided this beautiful passive-aggressive licensing comment, which I couldn’t have done better myself.

No open licence (Open Government Licence, Creative Commons, etc.) has been applied to this material. This repository is published on the presumption that making a 20-year-old, publicly-available technical specification accessible in a usable format does not constitute meaningful harm, and that the public interest in NHS interoperability standards being readable outweighs any theoretical copyright concern. If you are the rights holder and disagree, please open an issue.

2

Hey Marcus,

For GP2GP Kainos wrote an adaptor to translate the old hl7v3 messages to and from the GP Connect fhir standard. This is in use by Medicus in production.

I worked on GP2GP and GPC for a number of years and would be very happy to have a chat about it if it would be helpful.

Pete

3

You might be able to get AI to create a transform to fhir.

most gp systems are still at core a hl7v2 model and only a part of it. So it means transform to fhir should be easy.

hard part is removing the waffle in v3

4

Yes, the research I did around this earlier today did pick up those projects, the links are below for anyone searching for answers on GP2GP.

Thanks Pete, I worked with you about 8 years ago at NHSD on GP Connect, hope all well!

I think from a community POV it’s not so much about having chats as putting accessible Internet facing documentation out there. The whole problem is that a new market entrant has to deal with this archaic documentation, just to get started.

5

I remember working with you well and have been following and enjoying your YouTube channel!

The main point I was trying to make was that when we created the GP Connect structured spec the scope was to cover what was needed for GP2GP with the aim that new suppliers would not have to implement the GP2GP HL7v3 spec that is in the MiM.

So now if a new supplier came along they need to be able to export all of their clinical data in line with the GPC structured spec which is now in simplifier here,

and be able to import all the GP C structured test patients which are available from the demonstrator either via the orange test lab web page or in the INT environment. The test patients are listed here (patients 22-35):

1 Like
6

and can be retrieved here or in INT,

Once that is possible then in theory you can use the GP2GP adaptor which is available on the GP IT confluence page. I’m not as up on the adaptor as the work was still ongoing when I left but the confluence link is here:

Hope that helps : )

1 Like
7

Thanks @Pete - so good to have people on this forum who have your level of knowledge of the deep internals!

1 Like
8

np, really glad to help where I can : )

9

Hi Marcus
This looks really laborious. MIM version 7.2.02 is the latest that I know of but I have it in a form that seems to have similar content but which will open via index.html. This takes me back some 15+ years! You said:

Where on TRUD are you finding this? So far as I can tell it is not accessible via a current TRUD subscription. Accessing this mass of files via index.html - and knowing how to navigate - leads to the display of the R-MIM for the EHRextract message - which is the vital ‘moving part’ of GP2GP. That is quite instructive because it essentially visualises the underlying information model and contains a lot of detailed information about the various structures. It would be great to release this from its present shackles because I think it could be useful today - away from its original HL7v3 context. But this all sits in the midst of of the HL7 v3 NPfIT Message Implementation Model that contains a shedload of MIMs which include the GP2GP EHR request and EHR extract. So if you are trying to wrangle just the bits that are relevant to GP2GP out of that - the majority will be irrelevant junk. Also - my advice would be to steer very clear of any earlier versions because they are likely to mislead. Quite a lot changed over time.

Do you have the original zip file by any chance?

10

Yes, confusingly the downloaded zip is called nhs_mim_12.0.0_20080418000001.zip but when extracted it is a folder called MIM 7.2.02 (Publish). It is exactly this sort of opaque versioning and naming chaos that is intensely infuriating and proves the catastrophic failure of NHS internal technical teams to properly communicate standards with the developer community.

Here is a link to the document via my GDrive: https://drive.google.com/file/d/1PbXOmnqXsThJ3SjW0LwEalvFqudbzJrC/view

It’s not actually on the TRUD, my mistake if I said that, I found it here https://digital.nhs.uk/developer/guides-and-documentation/message-implementation-manuals

The web-facing versions are the out of date ones, it’s only the latest one that is downloadable as a zip. It’s almost like the last 25 years of the web didn’t happen to NHS Digital.

11

Well done for actually finding where this has been hidden. I have been trying to locate this for some time and others involved with the original project likewise could not locate it.
The opacity does not end there as you will see if you try the following - always assuming that you have not already found it out for yourself.
Open folder: MIM 7.2.02 (Publish)
Click on: index.html
Click on: Domains Administrative
Click on: GP2GP
Click on: 7.2 EHR Extract – RCMR_MT030101UK06

From this page find a choice of options to access including ‘additional detailed guidance’
Recommend clicking on the Left-most icon in third line down to view the R-MIM for this message (hovering pointer over each icon describes what it displays). Don’t waste time on the last ‘View Example’ icon.

Hardly intuitive!

That said, I think that the R-MIM is interesting because essentially it demonstrates the hierarchical model that can capture the structure of numerous proprietary GP system EPRs to an impressive level of detail - and render them interoperable between heterogeneous systems pretty much up to the limit of what any receiving system can ingest from the message. Clearly a simple system cannot populate the message with all of the detailed structure supported by a more advanced system - and a simple system has to ‘degrade’ the detailed structure that it cannot support originating from a more advanced system. There are very likely useful lessons to be learned that will apply to EHRs other than those in GP systems

12

I used to work in this area for a gp supplier.

I’d be surprised if actual data transferred was at this level of detail.

other systems don’t normally transfer records this way (patient records ownership is a primary care concept) and many can share via APIs. We haven’t got the infrastructure to exploit this yet (in most regions), hopefully that will come with single patient record (but another answer might be chosen instead - ie a version of CDA)