I am working on a project aimed at improving healthcare delivery in a resource limited setting; and we are looking to implement interoperability standards to enhance data sharing across various health information systems.
With so many interoperability standards available, how do we determine which ones are most suitable for our context? Are there any particular standards that have proven to be more effective in low-resource settings?
What are some cost effective ways to build the necessary infrastructure to support these standards? We have limited technical resources and expertise, so any recommendations for scalable and maintainable solutions would be greatly appreciated.
Implementing these standards will require training our staff and building local capacity. What are some best practices for training healthcare workers and IT staff in using and maintaining interoperable systems?
We already have some legacy systems in place. What are the best approaches for integrating these with newer systems that comply with modern interoperability standards? Are there tools or frameworks that can facilitate this integration?
Ensuring the security and privacy of patient data is a top priority. How can we implement robust security measures while still maintaining interoperability? Are there specific guidelines or protocols we should follow?
I would greatly appreciate any insight; experiences; or resources that you could share. Your advice will be instrumental in helping us create a more connected healthcare system that can ultimately improve patient outcomes in our community.
I’ve been collaborating with World Bank colleagues for the last couple of years in the development of a Buildable Digital Health Blueprint Toolkit. The Toolkit has been leveraged in multiple country projects this year. Feedback from these projects has been incorporated into a “release candidate” version of the artefact. This asset will, we hope, be released as a global public good later this year.
I had a chance to co-present with Ali Habib at an AeHIN Hour a few months ago. Our introduction to the Toolkit can be found, here.
To leverage the Toolkit, now, it is best to approach teammates at a World Bank county office. We’ll post to this forum when the final version is released.
Hi @elijaah – I also did, in 2020 (I think) an AeHIN Hour presentation related to the digital health “buildable” blueprint project in Myanmar. The video can be found, here. This was an early use of the Toolkit described in the other post.
I hope this may be helpful, too.
Warm regards,
Derek
@dritz , something came up that I wanted to ask you about. When looking at the integration between OHIE and SMART guidelines, it appears that common data dictionary elements are using SNOMED-GPS. I had understood the IPS use case primarily to be used for exchanging summary information across borders and not for transmitting specific patient information that might be required for CDSS (where SNOMED CT might be required). The latest TB DAK that I saw also specified SNOMED GPS. This could be an incremental step to get to semantic interoperability, but I would be concerned that GPS does not necessary contain the detail necessary to support a CDSS. Thoughts?
First, a bit of history. SNOMED-GPS was commonly called out in IPS related documentation and it sounds like some of this persists in the data dictionary references you’ve seen. The “GPS” was the original terminology associated with the IPS spec. In the ensuing years, and in response to issues brought back to them from IPS implementers, SNOMED has open sourced a full-fledged terminology rather than just a codes list: the IPS Terminology.
The IPS Terminology is a subset of SNOMED-CT… but a pretty fulsome subset. To quote the good folks at SNOMED: “the IPS Terminology will provide implementers with an open product that can be used in healthcare solutions using the power of SNOMED CT through its query language and hierarchies for the specified scope. Use of the IPS Terminology will allow for more effective use of clinical data analytics and decision support, and for Artificial Intelligence applications.”
Re: my thoughts on supporting CDSS – I’m benefitting from experience gained on some EU projects that I’ve been working on these last couple of years. There is a lot of momentum within European member states to leverage patient summaries, domestically, in support of broadly deployed CDSS. Of note: the European PS spec has since grown and evolved to become the IPS – but they remain very similar. I’m particularly impressed with what the Danes have accomplished. From what I can discern (so far), the codes driving this broadly deployed CDSS logic are found in the IPS Terminology.
We’re taking note of the successes in Europe, and there are now Canadian efforts to leverage, domestically, our PS:CA (the Canadianized IPS spec) to drive CDSS initiatives within our care delivery networks (not as a cross-border use case). I live in hope that such an approach might someday be considered for our SMART Guidelines work, too. For now, it is the way we’re framing the conformance-testable IHE Computable Care Guidelines (CCG) spec – so there will, hopefully, soon be Connectathon proof points that could inform how things move forward.
Great topic, Andy! Thanks for posting the question.
Warmest regards, and happy summer, my friend.
Derek
Thanks for the informative answer, Derek! Hope you are also having a safe and happy summer! I had not seen the IPS terminology and do not know the relationship between the concept_IDs in it versus SNOMED-GPS. I wonder whether it is just GPS with the relationships and other metadata. When I see SNOMED-GPS listed in the DAK, I assume that those SNOMED codes are valid SNOMED CT codes, and if they are included in the IPS terminology then one can find your way to them from other SNOMED codes using the full SNOMED CT. My concern is that managing an interface terminology to SNOMED has frequently meant that there are not 1:1 maps to SNOMED CT let alone SNOMED-GPS. Building a patient summary will require transforming the more granular codes to the subset used by the DAK. Sometimes this can be an appropriate transformation, but my intuition is that it is not always going to work. An example would be the use of “severe headache” in a decision tree for pre-eclampsia. Rolling all headaches up to “headache” would be a problem. I will take a look at the IPS Terminology and see if there are other examples. However, you mentioned that you had reviewed like 5 clinical domain areas and found them acceptable. Although, you mentioned that in the context of the resources/architecture, not the specific terminology required to interface with an actual EHR. Could you comment on the content as well?
@elijaah we do quite a lot of work in this space at PharmAccess Foundation, and are in the process of writing up our learnings and findings. Some of the material is already available, please be aware that they are still quite rough here and there:
These are really excellent resources and I will read them over closely (perhaps again for one of them). I am naturally biased in favor of OpenMRS given my history (and its implementation footprint) but the general principles seem sound. I have always been a little concerned given FHIR’s lack of post-coordination support, particularly when it applies to certain LMIC use cases where there is not SAME-AS representation within SNOMED. Did you have any specific instances where the FHIR resource was not an acceptable match to support the use case? My “severe headache” example, above, for example? I am convinced that FHIR is the right way to go, but I think it might require temporizing with use of an interface terminology like CIEL which provides a single code pre-coordinated concept for a post-coordinated expression in the immediate term.
I must admit – the issues related to interface (mapping) terminologies are ones that I’m not especially up to speed on. TBH… I’ve long thought that the “best” approach is to address the need for them, wherever possible. One approach is to record two (or more) observations at different levels of precision. For example… IPS requires pregnancy status (LOINC 82810-3) to be logged using a specified value set (with specified maps): Pregnancy Status - IPS - International Patient Summary Implementation Guide v2.0.0-ballot. This isn’t exclusive, however; other observations can be recorded along with the first one (e.g. pregnant with breach presentation, SNOMED 6096002). My sense is that the DAKs are referencing the higher-level codes in their logic (and so these “less precise” codes must be in the IPS)… but that doesn’t mean the other codes can’t also be part of the IPS. These more precise codes convey information valuable to a provider, even if they don’t drive the SMART Guidelines’ CDS logic.
RE: the various care paths (domains) that I’ve looked at – the analyses were often done by MOH TWG teams… and it was “by inspection” (we didn’t develop full-blown DAKs). Our approach was to review the recommendations from care guidelines and answer the question: “could the content needed to drive the care logic behind these recommendations be persisted in an IPS document?”. For the ones we looked at, we found that the answer was yes. As a caveat, we were looking at care… not at indicator reporting. There are definitely cases where the data needed for WHO-recommended (or donor-mandated) indicators does not naturally arise from care delivery. In Canada – clinicians have pushed back hard against the invitation to busy themselves administering statistical surveys – and have generally prevailed. Today, practically all of Canada’s primary care indicators can be developed from data that arises from care delivery. I’m sure many LMIC teammates wish they had the agency to get to that point…
Thanks so much for the excellent insights and questions, Andy. Let’s keep the conversation going.
Warm regards,
Derek
projects that I’ve been working on these last couple of years. There is a lot of momentum within European member states to leverage patient summaries, domestically, in support of broadly deployed CDSS. Of note: the European PS spec has since grown and evolved to become the IPS – but they remain very similar. I’m particularly impressed with what the Danes have accomplished. From what I can discern (so far), the codes driving this broadly deployed CDSS logic are found in the IPS Terminology.
efforts to leverage, domestically, our PS:CA (the Canadianized IPS spec) to drive CDSS initiatives within our care delivery networks (not as a cross-border use case). I live in hope that such an approach might someday be considered for our SMART Guidelines work, too. 
There are definitely cases where the data needed for WHO-recommended (or donor-mandated) indicators does not naturally arise from care delivery. In Canada – clinicians have pushed back hard against the invitation to busy themselves administering statistical surveys – and have generally prevailed. Today, practically all of Canada’s primary care indicators can be developed from data that arises from care delivery. I’m sure many LMIC teammates wish they had the agency to get to that point…