International Patient Summary for Outpatient Health Encounter Data Exchange

1

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.

  1. 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?

  2. 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?

  3. 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.

Thanking in advance

Chaminda

5 Likes
2

  1. 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.

  2. 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.

  3. 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.

4 Likes
3

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.

3 Likes
4

@italomacedo Thank you for the response. Yes, though it was originally meant for for ‘unplanned, cross border care’, but it is not limited to it.

But as in these use cases some countries are trying to adopt it’s structure, rules and value sets for in country data exchange (The International Patient Summary: Proposal for a National Implementation for Cyprus | IEEE Conference Publication | IEEE Xplore)

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.

5

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. :slightly_smiling_face::+1:

Warmest regards,

Derek

1 Like
6

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.

7

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. :slightly_smiling_face: 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. :+1:

8

Hi Chaminda ( @chamiw2008 ),

Here are a few other thoughts for your consideration.

While it can be used as a starter data set for longitudinal health record, I would urge caution about that the notion of a patient summary is not conflated with a full/longitudinal patient record.

First, as the IPS is an HL7 FHIR Document, the following guidance applies:

FHIR documents are not intended to capture unbounded data sets such as all data stored in an EHR. Rather, consider the Bulk Data icon specification for use cases requiring access to such data sets."

Second, you cannot arbitrarily add additional resources to the IPS document as:

The document bundle SHALL include only:

  1. The composition set: the single Composition resource, and the resources it links to
  2. The supporting information: Any resources that are part of the graph of resources that reference or are referenced from the composition set, either directly or indirectly (e.g. recursively in a chain)
  3. Supporting Collateral: A Binary resource containing a stylesheet (as described below)

You can certainly create a new FHIR document that is based on the IPS that would be specific to Sri Lanka, but then it would no longer be an IPS document and you will potentially lose cross-border interoperability.

While utilizing the IPS outside the specific use case of “unplanned cross-border care” can make sense in multiple scenarios, you need to assess whether or not the data in the IPS will meet the needs of that use case. I don’t see that a full health record is a use case compatible with the dataset in the IPS as the documentation states:

The IPS dataset is minimal and non-exhaustive; specialty-agnostic and condition-independent; but still clinically relevant .

(I did not add the bold, that’s from the IPS spec itself).

It might be helpful to look at the public comment for New Zealand’s planned PS which (at least for now) does not have the recent clinical encounters. It also affirms that the IPS is a minimal, non-exhaustive starter data set. While they discuss the use of IPS for “patient record transfer between general practices” I don’t see any indication that this would be anything more than the summary.

Malaysia is similarly looking at extending the use case of IPS to domestic patient-mediated exchange between health service delivery points. Here it would be the IPS as-is and not a full health record. This is intended as a mitigating factor to increase interoperability while they taken on the much longer process of setting up a full HIE and longitudinal health record.

Here is also some more information on the Canada Patient Summary which is technically not an IPS (but closely related to it). In particular:

A patient summary is not a patient’s entire health record, but a portion of it.

Finally, taking a strictly document-centric approach to a shared health record (whether IPS or some other document) does not make really make use of the power of FHIR RESTful API.

Hope this helps.

Cheers,
-carl

9

@chamiw2008 just a few questions, as I think there’s a bit of information that is provided out of context (IPS has a clear context. I am not aware of successful implementations of IPS as a baseline for a record)). So I don’t understand the notion of “National Electronic Health Record (NEHR) in the IPS format”. The IPS format is FHIR R4. Is that what you mean? If so, some caveats: While FHIR R4 is not intended to be the language for storing EHR data, it is the data for exchanging it and it works if you know the limitations (for example, when when an EHR has elements like “recorder” or “serial number” you’ll see that not all FHIR resources map the same to these concepts).
Some questions: don’t you have a national product code for medications? I worked on this for too long, but I don’t know if it is straightforward to others as well that neither SNOMED CT GPS nor ATC can fully replace a national medication code system (usually a complex catalog).
Also, how does using a document specification work for REST? Do you want to remove the possibility to do logical references?
Or you want to have a document-based national EHR? And if so, what do you do with shared data (master data like patients, facilities, products)?
Sorry for all questions, just wondering if you went through these steps or if they make sense.