Interoperability

Patient Summary is here!

Whether you handle patient transfers or need snapshots of patient health records, our new Patient Summary feature is a great way to get the big picture with one tiny call.


Fetching a patient’s clinical data out of a database can be complicated, with having to find all the data and stitch it together into a coherent whole. Interoperability can add a whole other layer of issues: What format is the source data in? What format does the receiving system accept? How do you translate one to the other?

This isn’t a new problem, and that means there is already a solution:

The International Patient Summary (IPS) standard.

What is an IPS?

The International Patient Summary (IPS) standard, maintained by HL7 International, defines “a minimal and non-exhaustive set of basic clinical data of a patient” which is designed to be returned as a single, easy to parse document. It came from a need for a standard for sharing patient data across borders in Europe and has since been adopted by the International Organization for Standardization to support global adoption and interoperability across many use cases including patient transfers.

Both CDA and FHIR templates exist for the IPS — the latter being what we have implemented in our FHIR API for Bp Premier.

IPS in FHIR

In FHIR, the structure of an IPS document is specified by the IPS Composition. It defines which FHIR resources are used in the construction of an IPS document, including how they are organised, plus additional information that should be included about the document itself.

To borrow a diagram from the IPS Implementation Guide:

image

 

The blue boxes list metadata that provide context regarding the subject and generation of the IPS document. The red, yellow, and green boxes represent sections within the document which may contain one or more FHIR resources relevant to that type of healthcare data.

For example, the Allergies and Intolerances section may contain multiple AllergyIntolerance resources, one for each allergy the patient has, and the Medication Summary section can contain multiple MedicationStatement or MedicationRequest resources, to represent the medications a patient is taking or has taken.

For a patient with even just a short medical history, this means that fetching their IPS can return a lot of data. It’s a lot to process, but it is only one request and the data is consistently and formally formatted, to assist with parsing.

How does it work?

For anyone already using Halo Cloud, the IPS is just another FHIR API endpoint. Specifically, our implementation utilises a $summary operation that can be invoked on the Patient resource type, in order to retrieve a patient’s IPS using their Medicare, DVA, or Pension identifiers.

Not sure what that means?

If you already know the Halo Cloud base URL for your environment, an example request might look like:

GET {baseUrl}/fhir/R4/Patient/$summary?identifier=http://ns.electronichealth.net.au/id/medicare-number|21234765614

This example is searching for the patient using their Medicare Card number (including IRN). If you wanted to use a different identifier, you can just switch it out.

If successful, this request will return a very long JSON response, which is the full IPS document. We won’t include a full example here — that would be hundreds if not thousands of lines of JSON — but reach out to Halo Support if you would like to see more.

What data does it return?

You’ll notice that not all of the sections in the diagram above are required. Our implementation does support all required sections, plus a couple more. Specifically, our implementation currently returns data regarding:

  • Patient
  • Author
  • Custodian
  • Problems
  • Allergies and Intolerances
  • Medication Summary
  • Immunizations
  • History of Past Problems

And the best part of using the IPS endpoint, rather than fetching all this data yourself? When we add more data, you will receive the new functionality automatically — no need to implement extra queries.

What about an Australian Patient Summary?

Great question! The AUPS is a very recent addition to Australian FHIR standards, and has not yet released a stable version. We are involved in the community discussions that are driving that standard, and are keen to adopt it once there is a stable release. However, until then, we will continue to target the international standard.

That said, the AUPS will be based on the IPS and AU Core (the main Australian FHIR standard). Most of our FHIR resources are already AU Core compliant, including the resources returned as part of our IPS document, so the changes when we adopt AUPS should be minimal.

How do I get started?

If you’re interested in using IPS in your integration, feel free to have a play with the API if you’re an existing customer or to reach out to support@haloconnect.io if you would like to learn more.


Similar posts