Sri Lanka considering storing data in the National Electronic Health Record (NEHR) in the IPS format, and to retrieve the information in an IPS viewer, following are some of the concerns that arised during our discussion today.
Background: There are different EMR solutions implemented in the healthcare institutions and it is planned that all the EMR should send a summary of the encounter (i.e. information pertaining to the minimum data set) to the NEHR to construct the longitudinal record for each patient. Furthermore, the EMR should be able to retrieve and view the summary of the patient from the NEHR.
In the NEHR minimum data set, there is certain information that is not directly stored in the profiles listed under the IPS “List of Profiles”. For example we are using the “Encounter” resource and “ServiceRequest” resource to store some of the information in the NEHR. In that case, will it be possible to retrieve this information in an IPS viewer?
For certain elements in IPS Profile, we are planning to add an extension to store the original value also additionally as a text, especially when they are of the type CodeableConcept. For example, the AllergyIntolerance.code is of type CodeableConcept, and if we add an extension to it to store the original text entered by the user, what would be the impact on the IPS viewer?
At the initial phase of NEHR implementation, the information that we are planning to send to and retrieve from the NEHR would be the encounter summary, which would be basically having the Patient’s demographic information, reason for encounter, allergic history, medical history, drug prescription, requested investigations, requested procedures and requested referrals. At this moment we will not be passing information pertaining to whether the medication was administered, procedures were completed or the results of the investigations.
We would like to know how appropriate and feasible to use the IPS format for this particular use case.
Hoping to find experiences from other countries and expert opinion on what we are tying to tackle.
The IPS is the summary of encounters that contain clinical data that are relevant to an unplanned cross border contact. In that sense, it should present a set of encounters, containing problems/conditions, procedures, medical devices, medications being taken, social history, family history and other bits that should portray a general understanding of the patient prior an unplanned cross-border contact. In my understanding, ServiceRequests are more of Administrative events related to the contact that may or may not generate clinical events like a Procedure, for example.
The CodeableConcepts that you usually find on FHIR elements are composed by a narrative element (text) and a coded element (Coding) . Those exist in that way so you can use both a narrative representation of the concept and a Coded (and more disciplined/structured) representation. So, CodeableConcept.text and CodeableConcept.coding can be used for that matter wihtout creating extensions for it. Further notes, can be fulfilled using the note (Annotation) element that every FHIR Resource has.
That is perfectly possible. Keep in mind that some sections of the IPS are mandatory, but some others are not. Also, Must Support elements should be supported. So, DataAbsentReason extensions should be used accordingly.
There has been something I have been questioning for some time in regards to the coded terms included in the IPS profile. Only a portion of standard terminology can be used license-free (for example, SNOMED IPS). When creating an IPS profile from an existing EHR, how are people transforming the data to the subset of terms? If the terms are already standardized, but not part of the subset, is anyone performing this transformation? I wondered whether CIEL should be providing a separate map to SNOMED-IPS for example in addition to the full SNOMED CT. BTW, translating medications to SNOMED or WHO ATC from RxNORM or local medication codes is another important use of the CIEL terminology.
It seems they extend the IPS with other requirements (eg: European guidelines on minimum dataset) to suite the local context. This is the approach we are hoping to take.
Thank you again for the insightful responses to #2 and #3. They would fit our requirements handsomely.
Hi Chaminda – thank you for sharing these super-valuable insights! The concerns you’ve raised are consistent with issues others have had to address, as well.
RE: your point-1… the IPS “composition” does not explicitly call out references to encounter resources. There is room, however, in the IPS “bundle” to add content that is important to supporting the care continuity. This is where, for example, provenance resources can be included that provide the link to underlying lab reports or encounters, etc., that represent the source of content referenced in the IPS composition. Adding a clearer description of how this is to be done is listed in the “known issues” of the IPS FHIR IG. Some really good examples can be found, here: International Patient Summary: Use Cases - Security - Confluence (including this example, which is especially illustrative: sandbox/gdpr/IPS-bundle-01-w-prov-01.xml at master · gcangioli/sandbox · GitHub). Of note – the IPS.PlanOfCare section is where you can include a CarePlan resource. This CarePlan resource can serve as the container for all forward-looking orders (such as ServiceRequest, or MedicationRequest, or even follow-up Appointment).
The provenance resource may also be a useful way to reference the original information in its original coded form (as noted in your point-2). Provenance.basedOn could point to your original resource, for example. You might also consider leveraging AllergyIntolerance.note or AllergyIntolerance.text as places where this information might be stored. It is perfectly acceptable to include these optional data elements as part of Sri Lanka’s IPS.
The plan to start by posting an Encounter Summary to the NEHR sounds like it will get the ball rolling. I hope, though, that the adoption of an IPS-based exchange at the start of the encounter could be implemented; doing this would have a very positive patient-safety and quality of care impact. Of course… at the end of the encounter… the original IPS could be augmented with the encounter’s details… and posting it back to the NEHR would contribute to a care-continuity virtuous cycle.
I’m a firm believer that the IPS “bundle” may be leveraged as an instrument of care continuity in both domestic and international use cases. I will follow, with interest, Sri Lanka’s efforts.
Andy – this is very good question that gets to an important point. Where there is a large legacy data set and a key use case is to convert content to build “on demand” IPS documents, the maps need to be there (as you note). Building such a comprehensive set of maps can be a non-trivial undertaking. It might be the underlying reason why (in many EU countries, for example) an IPS intended to support unplanned cross-border care is often manually constructed by a primary care provider. Where translations still need to be done to exchange cross-border patient summary documents in the EU, there is a “real time” infrastructure that operates during the exchange process to map between languages and (potentially) code systems. This is cross-border mapping is operationalized by each country’s National Contact Point for eHealth (NCPeH) using the Master Value Sets (MVS) catalogue and the Master Translation/Transcoding Catalogue (MTC). The process logic relies on an intermediary “pivot document” and is well-described, here: The Current State and Usage of European Electronic Cross-border Health Services (eHDSI) - PMC.
Where the IPS is being employed in support of care continuity in domestic use cases – such as the case in Canada, for example (and soon, Australia and New Zealand, I think) – it is more common to mandate that the patient summary document adheres to the national code systems. Again, for Canada, this would mean ICD-10CA, SNOMED, Drug ID Numbers (DIN), our national LOINC set, etc. This certainly helps address challenges related to map development and maintenance. Background information, and a link to the Canadian patient summary FHIR IG, can be found, here (as an example): Patient Summary | Canada Health Infoway.
In many LMICs where the domestic care continuity use case is being considered there is often not a huge quantity of legacy data. Rather than developing maps, the big implementation question might be: which code systems should we choose to underpin our national norms and standards? SNOMED-IPS, or ICD-11… or other no-fee options (LOINC, ATC, etc.) may already be in use. If not – choosing which ones to use in the nationalized “PS” is a key consideration. In making this choice, reducing the technical “lift” needed to develop and support translational maps is an important consideration. A case study of IPS use in Haiti can be found, here: Battling HIV in Haiti with the IPS – The International Patient Summary.
Particularly related to (1), as is noted in the FHIR IPS IG, unplanned cross-border was the original use case that inspired the IPS, but it is not the only use case. My home country, Canada, is leveraging the IPS data model as an instrument of care continuity within our domestic care delivery networks. To support this “toolbox” use case, all of the sections are optional in the PS-CA.
