Apologies for the late contribution on this thread, some great debate!
The challenge that Hira is responding to is the inability to provide access to trusted data to those that need it (consumers, whanau, clinicians, planners, researchers etc). The way countries have approached this is changing and continues to evolve. It used to about choosing an EMR and supporting exchange of data with other systems, then it was about an EHR or HIE potentially accessed through a specific UI and/or APIs. Many western countries regardless of their starting point (UK, Canada, Australia, Netherlands etc) are evolving to a federated model where an EHR is one part of the ecosystem but not the only source of trusted data and the focus is on access to data via APIs rather than via a restricted user channel. The following G7 International Patient Summary roadmap is a good example (albeit focused on cross-jurisdiction data access) of this thinking and aligned to the Hira approach.
As Anna-Marie describes Hira is focused on making trusted data sources (NHI, medicines, immunisations etc) accessible through APIs with robust security, privacy, access and data governance controls in place and the person in control of their own data. That means a marketplace of standard conformant APIs and other services created by multiple organisations and with access only to certified products and organisations. The Hira approach will be iterative as new services can be delivered over time and the tough bit is creating the right controls initially.
Data will be federated. That means there will be many trusted sources of data, most in the sector rather than the Ministry, but it doesn’t mean it will never be aggregated, for example a medicines data repository is part of the intended architecture rather than relying on real time access to 000s of prescribing and dispensing applications. @martin.wilson maybe HealthOne is a trusted source of data for Hira?
The link from Anna-Marie is useful - separating data from function is critical for innovation, we aren’t using OpenEHR specifications but the approach is the same.
Hope that helps. More Hira engagement is planned in March and if a strategy and architecture session would be of value I’m sure we can arrange that.
Totally agree about separating data from function. However, there is point of difference in the openEHR approach which is predicated on a single persistence format (Archetypes) and data extraction via the openEHR Archetype Query Language. My understanding of the Hira design principles is that they do not require ubiquity of data at rest.
Yes totally agree but for most on this thread that might be diving a bit deeper into architecture than required. I think the key question was ‘Who else has done this’ and perhaps what is the core scope of Hira.
Many thanks @darren.douglass for the update. As @amscroggins says, this thread is about “who else has done this”… I’d personally be very interested to take up @darren.douglass’ kind offer of more detail on the strategy and architecture - that surely would warrant it’s own thread!!
The main thing in my mind when I started this thread was the avoidance of high cost failure. I readily admit that my concerns have been fuelled by personal experience of just how hard it has been to both build API layers of data to legacy systems, and to convince private entities to play nicely with each other.
One of the ?advantages? NZ has is that we don’t really have to innovate to move forwards. We are so far behind much of the rest of the OECD that we have the luxury of looking at who has done what and how it went for them… For example, copying Finland would seem like a bad idea!
Annemarie’s link to the “post modern EHR” link describes this issue too - and points towards a way forwards - a managed data layer. It seems from what @darren.douglass posts though that this is NOT the plan for us - the “management” of the data layer will mostly be via the private sector, not in a repository owned by the crown.
My personal preference would be a “copy the best” and/or “Play the winner” strategy (copy overseas successes and/or facilitate spread of domestic success stories.) No matter which way we do this, it’s gonna be a tough nut to crack!
Thanks again for the post @darren.douglass, and really keen to hear more about architecture if possible! Mat
Thanks @Mat. I’ll connect you with the Hira architects for further discussion. Totally agree that we need to learn from others both in terms of what they have done and where they are heading.
One clarification on the managed data layer. While we expect the data to be federated (ie multiple trusted sources rather than one repository) the data governance and management will be a crown function either directly or via commercial relationships. In essence the outcome is the same, secure and trusted data.
I tend to share @Mat’s thoughts re: the private sector management of data.
My experience with HealthOne as an ED clinician down on the South Island is reasonably functional – until it tries to access GP information, and the relevant and timely clinical context from private clinicians is virtually all obfuscated.
I am not specifically advocating for one foundational approach or another – only the implementation specifications to have the data from those private groups openly accessible. In the eyes of a patient, looking at the health service meeting their needs, the expectation ought to be we all readily have access to the data necessary to inform their care.
@martin.wilson
“…until it tries to access GP information, and the relevant and timely clinical context from private clinicians is virtually all obfuscated.”
They have different, separate instances installed in each region. They haven’t always used every module with it in each (e.g., lab services), but it’s pretty extensive.
CareEverywhere is the data exchange infrastructure between Epic installations; access can be gated differently for each institution.
Pretty sure Kaiser is an EPIC shop. Epic is very tightly integrated but does not play well with others (Interoperability can be a problem).
I once asked an Epic salesman how they handled interoperability - he looked at me and said “we are fully integrated - who would you want to interoperate with ?”
KP were one of the first US adopters of EHR systems and replaced an in-house/IBM system with Epic in the early 2000s. I think they spent >$4 billion on the system and probably more since - my impression is that the KP deal was pretty important for Epic becoming such a major player today. I’ve heard that a lot of what is in Epic is from the work done in the 2000s working with KP workflows etc. (the “Epic Way”, etc.).
yep and that is not for the want of trying. Private work is more often than not reflected in GP classification lists BUT H1 have been trying to work with the private specialist area and integrate their work but it sits with their vendors integrating with the H1 FHIR API. If anyone can facilitate here it would be most welcome
Thanks @darren.douglass for the clarification, and look forwards to hearing from the HIRA architects!
End of the day, we need to ensure that the underpinning data structures avoid at least most of the known pitfalls: vendor lock, vendors being able to control access to data and commercial drivers which may stymie competition were the things I was thinking of in this case…
A more complex requirement which is made more challenging by disparate data sources is the “living document” type of data.
Systems which call upon data from multiple sources work well for data visibility, but the ability to subsequently manipulate that data in a clinically meaningful timeframe can sometimes be challenging. I’m thinking of examples such as medication list, problem lists and outstanding investigations/problems. Frequently these can span multiple organizations, and disagree with each other!
@Mat I agree, viewing data from multiple sources is easy but it gets harder when you want to interact with the data in a useful way. No-one said this would be easy!
On the EPIC discussion they are a good example of an enterprise platform that works as long as they are the master source of the information and the main UI. Useful if you are a single provider wanting to impose a standard way of working on everyone, not so useful if you are trying to support collaboration and flexible working across many organisations. They integrate but its not clear that they can interoperate. Back to my previous comment, Hira wants to enable access to trusted information by many applications/services (which will include enterprise systems) rather than impose one.
Thanks @darren.douglass !
Yeah, I hear ya! That was in part why I was hoping that the MoH or HNZ would be the a repository for at least a large chunk of the most used data…
Following the EPIC discussion, I agree, you basically have to go boots and all in with them… unless you can separate the data layer from the software as we are proposing!
When I was in Alberta, they were rolling out a province-wide instance of EPIC. Alberta is roughly the population of NZ, in a bigger area.
The thing which surprised me was the speed and cost at which they were able to roll out. They signed up in 2017 for CAD$ 417M, have delivered the first 2 phases (and are currently on track to deliver the completed project by 2024. The completed project will provide services from all levels of healthcare - the remote indigenous communities in the far north through to the quaternary services such as the paediatric cardiothoracic intensive care unit.
Another question is how the EHR is applied in virtual healthcare applications e.g. metaverse, the EHR needs to be accessible outside of the traditional models of care.
My 12 year old daughter knows more about blockchain tech, NFTs and virtual accessible services than I do I’m pretty sure, so emerging clinical talent will expect the modernisation of the healthcare system to be there on arrival.
Thanks Kyle!
I find - where available - the WHO national health system reviews quite useful. This one for Estonia is pretty positive, both in terms of return on investment and healthcare gains. It is a fundamentally different strategy from what we propose based on what I can see though…
“patient success stories are tied to clinician success stories” - this is key but unfortunately our hospital clinicians are, incredibly in 2022, still poorly supported by IT.
Hira had 385m budgeted in 2021 for ‘Tranch 1’. Budget 2022 has 155m for Dunedin and 320m for ‘digital foundations and innovation’ which means everything else across the country (including Hira Tranche 2).
I have no doubt that Health NZ and the Ministry will be able to stand up a secure API integration platform with some clinical information available to view. The questions will be around what information and is it value for money.
Concerns highlighted in this blog lead me to pose the following:
No hospital in NZ has an integrated Clinical Information System that fully supports supports all point of care workflows end to end. What we have with our clinical portals in their various forms is a snapshot of available data which is not the same as workflow support e.g workflow from ED to admission, or the preoperative processes. As a ‘foundational’ problem should this not be prioritised?
Will software suppliers and private practice need to be incentivised to join the Hira party? If they don’t join, is an incomplete data set as much of a patient safety concern as no data?
Where we do have systems, e.g. GPs, what is the quality of the underlying clinical information, how is it structured, and how do you filter out information that the consumer would prefer not to be shared? Will data standards be applied or even mandated to ensure that the information presented in Hira is of high quality?
The original question about how many data sources can be held together with API’s remains unanswered. Perhaps the question should be how many do we need? That comes down to system design principles based on the workflows to be supported. Yes, healthcare workflows are complex but there are many common processes across different specialities. Defining these, and the process variations at a local level, is key to simplifying the system design.