Hi 
I’ve seen a few mentions about needing to improve the GP2GP system for transferring clinical files between different GPs/PMS systems and I note there is a Te Whatu Ora webpage dedicated to this at https://www.tewhatuora.govt.nz/health-services-and-programmes/digital-health/gp2gp
I’m wondering if anyone would like to educate me on how GP2GP works. I’m assuming there is some kind of database interaction, likely SQL involved?
Thanks
@GPs - can any of you shed light on this?
I do wonder if this would be best asked more widely than CiLN (i.e. in General or Public) as us clinicians might not have a full grasp of the technical aspects.
(I’ve moved it to General to this end)
The best person to ask around the replacement is Grant Ardern who was the lead for the replacement investigation.
Gp2Gp was initially a summary export tool to transfer (via messaging file format) a patient and key records (as capitation requirements) between one enrolled practice to a new one where the new patient may have wanted to enrol, and supported ease of managing who is the lead clinician. It’s been expanded significantly out and no longer fit for purpose when it was incrementally added on an unstable and ‘messaging’ based system.
A modern system of sharing records, and not selectively administrative flags and key enrolment details is required to make patient record portability a reality.
@mca - Some of the details that you’re seeking can be found in this
2012 HiNZ Conference Presentation and this
2014 HiNZ Conference Presentation - GP2GP In Action.
Although the patient records are sourced from, and subsequently persisted to, a database (all PMS suppliers use an RDBMS) - GP2GP is a record transfer service and, of itself, doesn’t directly engage with the persistence layer of the participating systems.
The basic technologies are a common integration component (.NET C# Library) that exposes an agreed data model to the participating systems; HL7 CDA (Clinical Document Architecture) Documents for the clinical payload; and HL7 v2.4 messages (sent via Healthlink) for transportation. No longer the most modern standards, but IMO GP2GP would still work fine if implemented correctly - and the most knowledgeable users that I’ve spoken to recently agree with that.
The current issues with the GP2GP service can all be traced back to poor quality data (particularly non-standard clinical coding) in GP systems and will be a barrier to any system built to replace GP2GP. These issues were clearly identified and communicated to the software vendors by Patients First back in April 2021. Since then…go figure?
@SamuelWong - as someone who has been involved with GP2GP since its inception, I can state that it has definitely NOT been expanded beyond its original purpose - despite some attempts to do so (e.g. for bulk transfers). Nor has it ever been linked to capitation payments or (despite plans) directly to the National Enrolment Service which it predates by several years. In fact it is also used by facilities that do not belong to PHOs or receive capitation payments. I also don’t know what you mean by ‘lead clinician’ - the transfers are implemented at a practice level and patients enroll/enlist with a practice not a particular clinician.
Thanks for the clarification @pkjordan . My comments were based on observations and actions by practice managers, commercial entities and PHOs trying to do more than what’s the capabilities of the GP2GP functions. I completely forgot you were the original architect, and that for what it was principally designed for, it worked according to the specifications (other than the fact you pointed out, each PMS coded things differently even on the same field class).
My comment reflects the issue whereby a lot of business/policy changes have occurred around the vision of interoperable patient portal record, and GP2GP was an early implementation to achieve a different aim = when a patient needed to move between practices and the recipient GP organisation needs to be able to view qualified clinical records.
The implementation between NES and GP2GP functions probably merged from what I have seen in GP PMSs, so makes things quite blurred.
Hi @SamuelWong - you’ve touched on one of the key issues going forward which is whether the original key GP2GP requirement - “transfer the entire patient record” - still remains - or if it should be replaced by some form of summary record (e.g., IPS derivation - such as those produced by the Medtech ALEX Platform). There is certainly a case for receiving systems to request some data from national CDRs - such as MDR and AIR - although it’s a pity that we still don’t have a national API for pathology and radiology results. Either way, I believe that “give us everything” is unrealistic and has created poor outcomes. Case in point is my own GP2GP record which contains over 200 document attachments - many of which are copies of all emails from my Patient Portal - including simple acknowledgements and generic messages about practice opening hours during Xmas/New Year. Surely it wouldn’t be too difficult for individual record entries and documents to have a simple “clinically relevant” flag - or something similar - with a default of true that could be used to filter out information irrelevant to a patient’s current and on-going health and wellness?
@pkjordan thanks heaps for this explanation
if i’m correct sounds like GP2GP uses pre-FHIR but nevertheless HL7-based interoperability - which makes sense
as for the quality of clinical record-keeping - a plug on behalf of the GPs: not all pms UIs make this particularly easy! though from my limited experience MyPractice is a little better designed for this (at least basic diagnosis coding). the ongoing use of READ codes in Medtech Evolution is problematic. i can only assume that changing over is a bit of a vendor nightmare.
primary-care snomed-ct ux
Yes, GP2GP was designed and implemented before HL7 International developed FHIR.
Many factors are responsible for the poor (or certainly non-interoperable) quality of data in NZ GP systems. One, as you say, is sub-optimal UIs and another is the continued use of Read Codes with user-defined synonyms which makes mapping to SNOMED CT extremely difficult. However, there are issues with many other coding systems - notably local lab codes (an absolute curse); immunisation coding that fails to differentiate between the administered product; and target disease(s), failure to use the international scientific standard for units of measurement (UCUM). Systems that allow users to enter their own descriptions for carefully curated code systems like SNOMED CT and NZULM/NZMT are another roadblock. Interoperability is a team game and everyone has to play by the rules. Data is forever and therefore has a life beyond the point of capture.
@martin.wilson - does this line up with your experience?