NZ Core Data for Interoperability (NZCDI) introduction

dmeiklejohn · 12 June 2024 20:36

HISO is supporting Health NZ in developing a standardised core set of data concepts, elements and value sets for nationwide, interoperable health information exchange.

The new standard called NZ Core Data for Interoperability (NZCDI) will follow the example of USCDI and AUCDI overseas to define a standard set of the most commonly exchanged data elements for Aotearoa.

Having different terminology and business definitions is causing confusion and limitations in integration between clinical applications across the motu. NZCDI will establish a consistent set of data definitions for exchanging health data. It will provide the health sector with a single, public list of standards and implementation specifications that can be used to address health information interoperability.

Many of the most common data definitions that will make up NZCDI already exist in standards such as HISO 10046 Consumer Health Identity Standard. Over time NZCDI will bring all of these data definitions together in a consistent manner.

NZCDI will align with the NZ Patient Summary (NZPS), our adaptation of the International Patient Summary (IPS) standard.

NZCDI will be published on our website with supporting tools and materials.

NZCDI will be regularly maintained via an open process overseen by HISO to ensure it is not just a static list of data elements, but rather a dynamic framework that reflects our changing interoperability needs.

Contact us

We welcome your feedback and participation.
Our email: standards@tewhatuora.govt.nz

emily.gill · 12 June 2024 22:35

Kia ora @dmeiklejohn , this looks great and promising! Indeed, there have been recent discussions about the importance of interoperability usability: Electronic Medication and Prescribing in Aotearoa New Zealand - #41 by oliviaclendon

How can it be ensured that the NZCDI ensures data is in a usable format post exchange?

One of my mentors explained his thinking on interoperability and standards: mandate conformance testing. One of the first technological standards mandated by policy in the US was weights to measure imports arriving on ships, to accurately tax goods. Two weights, from different companies, actually had to weigh the same amount if they both said ‘one pound’. Trusting that a company’s weight with ‘one pound’ stamped on it, was not sufficient to regulating how much tax should be charged per pound.

The way we explained this in the below publication is:

The $37 billion EHR MU/PI incentive program [55] emphasizes exchange of health information as a key function of HIT to improve care coordination. Though some increase in health information exchange has occurred [18], functional electronic exchange remains poor [37,46,48,53,56–59] and may relate to how policy incentives were implemented. The criteria for successful receipt of funds from the MU/ PI EHR programs included “Care Coordination” and “Health Information Exchange (HIE2)” as two of eight policy objectives in place during this study. Manual data download for “Care Coordination” and data entry for “HIE” were allowed, but neither objective required bidirectional electronic health information exchange [31,60]. The lack of policy mandate to verify how exchanged information is presented to the receiver may explain the poor function and integration of data from external sources into EHRs. Electronically received information needs to be displayed in ways that make it easy to consume, reconcile into existing records, and respond to. Though simultaneous display of data, in a single view, from two sources has been required by MU/PI programs since late 2012 [61], specific display of CCDS data elements parsed from electronically received summary records was not stipulated in attestation criteria. To drive improved usability of received data, policies may need to focus on improving information systems that parse and incorporate CCDS data elements into EHRs.

A complementary approach might be mandating conformance testing, which would likely have an important impact if linked with mandates of exchange but may be politically challenging [62]. Conformance testing could require accuracy and completeness when comparing data in a sender’s EHR with data in the interoperable document, including deleting duplicate aggregated data.
HIT Rural Coordination.IJMI.gill_2020.pdf.pdf (481.7 KB)

dmeiklejohn · 14 June 2024 01:09

Kia ora @emily.gill ,

Thank you for your response, the publication makes for some interesting reading into difficulties observed regarding care coordination and information exchange.
It appears this article was published prior to the USCDI in July 2020 and the subsequent USCDI - US Core Implementation Guide.
It would be great to understand any impact their development and inclusion in the ONC Health IT Certification Program had on the rural setting the article addresses.

In much the same fashion as our overseas examples, NZCDI seeks to answer the “what” question of interoperability.
It will not be a technical implementation model, as that is a role fulfilled elsewhere, but it will work closely alongside these models to ensure alignment.
The primary purpose is to support interoperability by providing consistent terminology and business definitions of core data.

We would be interested in hearing more of your thoughts about NZCDI, interoperability and your experience of the challenges across various healthcare settings.
I will get in touch with you via the email you sent through to the standards inbox.

keithduddy · 17 June 2024 06:52

Hello @emily.gill,

I have a minor role in the HL7 NZ FHIR Base definition group, and every meeting I attend has a good smattering of HISO, Ministry, DHBs, Te Whato Ora people and vendors in conversation, including some of the most experienced HL7/FHIR people in the world, who initiated the FHIR standard and pioneered its use. They are very consultative to make sure that the FHIR Base Profile for Aotearoa is not prone to the mistakes of other jurisdictions. They are proceeding cautiously, starting by defining only the most common and widely used FHIR Resource extensions for NZ, and then using and testing these extensively in projects to share data between parties in NZ. Then they may move on to a FHIR Core Implementation Guide for NZ, which is a lot more constrained and extensive, having used the experience of sharing many instances of the Base definitions. I’m sure lessons from the US are pertinent. Thanks for providing the paper above. (Note “Base” and “Core” implementations have special meanings in the FHIR context, and NZCDI is an expanding set of lower-case “core” definitions for data interoperability in NZ, without, yet, being a FHIR “Core Implementation Guide”, which it will probably become at some point.)

Also Hello @dmeiklejohn, nice to meet the newest member of the HISO Team. My other engagement with e-health standards in Aotearoa is being Robin to Alastair Kenworthy’s Batman in the NZ contribution to the ISO standard for International Patient Summary (IPS). This will feed directly into the NZIPS programme, as ISO is about to publish v2 of IPS, and then it will take some time to go from the ISO “logical model” to being a specified (by various HL7 affiliates) FHIR Profile that can be implemented. All mature parts of NZCDI will then be applied as extensions or restrictions to the individual record types aggregated in a FHIR International Patient Summary. And Implementation Guides will be developed for the scope(s) and manner(s) of use of IPS. These may have both internal use for purposes such as a potential replacement of the current GP-to-GP records transfer approach, or for international use when NZ-resident patients travel to and from third countries to allow their medical context to go with them, and return. This may become increasingly useful in particular for record exchange with our Pacific neighbours.

But I don’t speak for HISO - where I’m merely a volunteer contributor - and I’m sure Demi and @alastairk will keep us appraised of progress for versions of NZCDI, re-using HL7 NZ’s Profiles and IGs, and when these get inserted in appropriate places in the IPS when NZIPS starts to become a more fleshed out initiative.

I’m enjoying the journey so far - and can report that many in Asia Pacific are also really keen to see IPS become a core international interoperability plank, through the interactions our team (at my company S23M, and via our ANZIL initiative) has within the AeHIN network, and by working with CSIRO/AUSAid in South East Asia & the Pacific. [I’m Brisbane based, but S23M is an NZ company.]

best regards,
Keith

P.S. Sorry, @emily.gill - I launched straight into the technical implementation side (HL7 FHIR) of NZCDI… but that is indeed the last step after requirements and semantics for health interchange are established by the many and various participants in HL7 processes.

In the IPS case, starting with ISO, this is definitely based on clinical/organisational requirements, and only later translated into technical interoperability mechanisms. The “Implementation Guides” I mention are intended to marry up the semantics and use cases with the means for implementation using open standards.

dmeiklejohn · 20 June 2024 00:10

Hi @keithduddy

Thanks for your comments and insight into your experience with HL7 NZ FHIR, IPS and the NZIPS programme. Great to see your perspective on the various inputs they have into the standards development and implementation processes.

Engagement with subject matter experts and stakeholders with broad representation from the many sectors of health is a core tenet of HISO standards. As with NZPS, NZCDI will follow this same development process with open review and consultation being key components in progressing NZCDI versions. We aim to align with the work of the NZPS and continue to build the NZCDI using this approach so I can confirm we will be actively encouraging feedback and involvement as we progress this initiative. We need the engagement of those with clinical and clinical informatics backgrounds alongside those with a technical background to ensure we can achieve the full benefits of interoperability from these developments.