This is really helpful, Marcus.
A few practical tips from painful experience
- Negotiating this territory by working directly with GP suppliers can be tortuous
-
commercial barriers which you alluded to
-
differences in the way that GP suppliers handle some SNOMED terms
-
IM1 itself.
-
Forming relationships with GP tech people
-
Technical restrictions e.g need for a desktop integration
-
Negotiations with NHS E governance folks
-
No out of the box FHIR wrapper
For that reason there is a good case for using one of the specialist GP integration services from e.g 6B, BlackPear etc. Tey can help with all of the above. Clearly not an option for some but if you have the budget, definitely worth exploring, as this is definitely an area where experience and ‘dark arts’ is really helpful.
-
GP-Connect is very attractive but remember that it is couched in some very restrictive governance requirements e.g you cannot AFAIK officially re-publish GP-Connect data as a downstream API. And the AOPI itself is officially provided by the NHS, not the GP supplier. We had a situation where a newbie third-party tech company had long supportive discussions with a GP supplier won using GP Connect, but when it came to actually doing something they were told they had to start talking to NHS-E (6 months wasted)
-
Do not trust SNOMED hierarchies or consistent use across practices/ orgs. Proceed with care.
One big gap is write back to a managed queue, as we have for lab results but nothing else .. nothing akin to pull requests where a change can be suggested/primed but not fully actioned. You can write back via IM1 but only one term/value at a time without context or control. Really difficult to do this safely without detailed discussion, not just with the supplier but with the local GP community as it is very easy to screw the data quality on the GP system by sending over the ‘wrong code’
-