We commit to work towards adopting a standardised minimum health dataset for patients’ health information, including through the International Patient Summary (IPS) standard, with the shared objectives of facilitating health interoperability within and between countries, developing internationally shared principles for enabling patient access to health data, based on the principle of informed explicit consent or patient permission and in keeping with countries’ and regional existing legislative frameworks; and facilitating and promoting the use of open standards for international health data to encourage the widest possible adoption of standards and greater interoperability. To achieve this goal, we will work with the Global Digital Health Partnership (GDHP) as they are already advancing IPS efforts.
The Global Digital Health Partnership last week held a mini connectathon on the International Patient Summary and heard a presentation from @pkjordan on New Zealand’s GP2GP-related work. SNOMED International presented on the SNOMED CT Global Patient Set and its place as IPS freeset content
My particular interest is in how the ‘required’ components of IPS can be assured to be bi-directional, interoperable, structured data for reconciliation (e.g., medication, allergies/intolerances, problem list). Then, this would form the standard for unstructured components contained within the concept of ‘Plan of Care’ such as ‘patient goals’.
Including patient/whānau voice in the IPS, as part of the standard, would be transformative. Hira is building an ecosystem of truth sources, but to drive quality of care, this ecosystem must enable reconciliation of that truth, over time, with the patient/whānau having direct input.
I agree there must be a place to record the patient/client’s own experience, in free text or other direct means. It was a disappointment to discover that the IPS does not contain a representation of the ’Subjective’ ‘Objective’ ‘Assessment’ ‘Plan’ sequence knows as ‘SOAP’ to generations of doctors since 1968 when Lawerence Weed first introduced it with an article in the New England Medical Journal-discussion here: https://www.amjmed.com/article/S0002-9343(18)30094-9/fulltext . It is important to remember that this has nothing to do with the SOAP’ simple object access protocol’ which shares the synonym is from a different domain altogether, as in the SOAP - REST protocol battle, which REST is winning with FHIR and most of the business world.
With the Lawerence Weed’s ‘SOAP’ formula enacted at each encounter, a layered record builds up which is also its own navigation tool. ‘SOAP’ is the core notion as well in the ‘OpenNotes’ concept https://www.opennotes.org/ournotes-professionals/ where the patient/whanau does indeed have direct input, and is in fact the curator of the record, using the recurrent SOAP structure to navigate and keep track of the unfolding story off their own care. Who needs an EHR? Well, maybe a few bits and pieces….
It would be a vital enhancement to the IPS to have ‘SOAP’ on board, either as a new feature or just by convention, for local use.
Mike Mair
Agree, I suppose it’s understandable that the first step is to get all the structured data into the standard, but the unstructured is where the meaningful information is. Without the unstructured, which is where an individual’s story is recorded by both clinician (most of SOAP) and patient (e.g., specific field for ‘goals/needs’), the structured data is wide open for interpretation/bias that can be exacerbated by AI/machine learning.
The analogy in research is the growing importance of ‘mixed-methods’ to understand complex problems. Health is about human stories, and we are far from simple
Hi Gill,
‘Meaning’ is a much debated term, but there is a robust distinction to be made between explicit and implicit meanings. The ’tweet’ is perhaps the apotheosis of implicit meanings in the modern digital age; ‘less and less’ can mean ‘more and more’ as a tweet evokes its own context and community. Verbal language like tweets carries a heavy implicit load, and yet no one is trying to abolish these forms of natural language in the digital era, as some are mistakenly attempting in the medical record. We need our full language and para linguistic competencies to understand what people are trying to tell us, and note it in the record, if they can’t themselves. The OpenNotes project would let them, but cuts across assumptions on privacy and confidentiality that will need culture change. The assumptions of the past are summarised in something a patient once said to me as she paused at the exit door: “doctor, I know it’s none of my business but am I going blind”! She had harboured this dread through 30 years of monitoring.
EHRs which try to create pseudo text from a questionnaire are time consuming and miss the point in my view, which is that what people experience is “kind of…” seldom “exactly” any verbal category. We need to let their words resonate in our own linguistic and paralinguistic competence to know what they ‘mean’. In my view it is those EHRs which try to do away with free text which hold us up most, and lead to long waiting lists and physician burn out. Harvesting structured data is more like grabbing low hanging fruit and putting them in a box like the IPS, an activity running along side the human story. The data can get sucked out of there to be part of an AI algorithm and then feedback on care plans, but in my view management of people requires intersecting with their narrative and missing that has led to great inefficiencies and contributed to the failure of public sector health services even in the pre covid years.
Regards
Mike Mair
Although the IPS doesn’t (yet) include the Encounter Resource, it is technically possible to include structured clinical notes in the IPS, by using the note element in the Condition Resource. However, this does require a condition/problem/diagnosis code, albeit that the verification status of this can be set to one of the following…
unconfirmed | provisional | differential | confirmed | refuted | entered-in-error
Looking at the GP2GP Data Model, the Encounter Class does include a diagnosis code, together with 3 varieties of clinical notes (structured, html and plain text) - so it might be possible to map these instances, however there isn’t a status code and I’m not sure if any of the underlying GP systems contain one either. Clinical input is required here to determine what should be the default verification code in these circumstances (e.g. should it be provisional or unconfirmed if not supported by a matching entry in the ‘problem list’)?
Yes, and there is a plethora of academic writing to support this statement, if anyone wants references I’d like to underscore the fundamental importance of what you’ve said:
Therefore, in thinking of ways forward, it is the plain text@pkjordan mentioned below that would be important to think about including in the IPS.
Yes, please (as a clinician)! Really keen to discuss this element. The issue, ideally, though is one of ‘merging’ rather than ‘verification’. The term described in the literature, most described for medicines, is reconciliation.
In my ideal work-flow, when that GP2GP file comes into my EHR/PMS, as I work thru each section with importing components (e.g., medicines, problem lists, etc), I would like to control what happens. For example, if there is a 100% match between existing data and importing, then the date of that data can be ‘updated’, but I don’t do anything as a clinician. Where the data does NOT match, I’d love two fields to appear, much like when merging contacts or merging word documents, where I can chose which data is ‘correct’ . . even better, would be to have an edit function where I can select which code is going to be updated, but add some extra information (e.g., modified structured data of ‘IHD’ to ‘CHF’ and add free text ("2ry multiple MIs’). Then, I click a button to ‘verify’ this is new entry for classification/medicine and the date-of-reconciliation is noted.
This would revolutionize our workflow and reduce the many known errors that cause harm, with the poor quality reconciliation that occurs, especially for high-need patients with complex chronic conditions (who cost $$ to the system, too.).
Many thanks for the feedback, Emily. That’s really helpful and constructive in many ways.
I used the term ‘Verification Code’ as that’s the name of an element in the FHIR Condition Resource, but I’m familiar with medicines reconciliation from my work with NZePS (and as part of my ageing Mother’s Care Team!). Reconciliation is also used in many business contexts, e.g. accounting and the merging that you describe is ‘bread and butter’ to software development teams.
Your ideal GP2GP workflow is something that I will discuss with my client, Patients First, who have oversight of that service. Ultimately, that implementation would be up to the Practice Management System vendors - so perhaps we should arrange a workshop with them and a group of GP users, in the near future? The quality and quantity of data in GP2GP is a major concern at the moment, highlighted by using it for IPS which has much stricter requirements.
Kia ora @pkjordan , really interested in contributing/participating. From the research work I did based in the US (12 month fellowship), and learning from the MeaningfulUse implementation (failings), would it not be possible to think about required APIs that mandated such reconciliation/merging?? This could/should be the core component of genuine ‘interoperability’. The next step, would be to ‘ping’ whatever the latest version of reconciled components are, to all those involved in a person’s ‘circle of care’, and so ‘pushed’ out to the relevant views of the data (e.g., multiple EHRs, patient portal, etc.). How feasible would it be, from a standards perspective, to work out what a ‘reconciliation’ API must be for, say, medicines?? This might be the logical place to start, as is a known source of significant patient-harm. But, it would be useful to build such a standard thinking about how it would apply to the other components (e.g., problem lists, and best-of-all, unstructured (character-limited), ‘goals/needs’). My wishful thinking
Agree that medications would be a good starting point. Certainly, thanks to NZePS, the quality of the data in this area is better than most in the community systems. Other areas, e.g. problems/conditions, are more problematic due to varying implementations in the GP systems; some are still using Read Coding, others SNOMED CT - plus placing a whole variety of clinical data categories in a general bucket called ‘classifications’.
Posting here a summary from the Global Digital Health Partnership of activity around the IPS:
Events
December 9(multiple times) The Joint Initiative Council (JIC) will host an event focused on the IPS. This includes morning and afternoon sessions according to Central European Time. No worries if you cannot attend both, but one of the time zones should be convenient for many different nations. This is a free event. To review the agenda and register, start here: http://www.jointinitiativecouncil.org/news/GS1LAA211019-01-JIC_Webinar_Agenda_07.pdf See the new JIC website for the IPS
December 16 (8-9am ET US) The GDHP is hosting a meeting about the IPS workstream and invite vendors and implementers from GDHP nations to attend. This will be an opportunity to provide feedback and help develop the agenda for 2022 GDHP connectathons and IPS workstream planning more broadly. Attendance is free. If you’re interested to listen in or to bring a topic for group discussion, please contact me.
January 10-12 (full days) HL7 will be hosting FHIR Connectathon 29. Both IPS and International Patient Access (IPA) will have tracks with information available here: https://confluence.hl7.org/display/FHIR/2022±+01+Connectathon+29The event requires registration with HL7 (prices vary based on time of registration/membership).
January 26 (6:30-10:30am ET US) GDHP will host its next Mini-Connectathon dedicated to advancing implementation and usage of the IPS. This is a free event open to participants from GDHP member nations. I’ll be contacting individuals for topics and preparation for the event over the coming weeks as we develop the agenda. That said, please go ahead and block your calendars now. We’ll work to get out calendar invitations to the event over the coming weeks.
In terms of progress on the IPS standard, HL7 and GDHP have begun to address several issues from prior connectathons and help build momentum for the standard. Here’s a quick (non-exhaustive) summary:
Move changes from previous connectathon branches into the CI-Build of the IPS. The CI-Build branch is in a much better spot today here: http://build.fhir.org/ig/HL7/fhir-ips/ Work continues to incorporate feedback before the next publication. (Thanks to Rob Hausam and all others who contribute to this work!)
Inferno will be releasing a new set of web pages dedicated to IPS testing. This is still in development but you can check out at https://inferno-dev.healthit.gov/
New updates are expected to be publicly available on the IPS website on December 9. Credit to Robert Stegwee for leading a great deal of this work with the IPS Web Editorial Team:
