This appeared last week:
Budget 2022 invests more than $600m in data and digital health
Thursday, 19 May 2022
NEWS - eHealthNews.nz editor Rebecca McBeth
Budget 2022 signals investment of more than $600 million in data and digital health projects over the next four years.
This includes; $320 million on ‘health data, digital – foundations and innovation’; $125 million on ‘population health and disease management digital capability’; $10.8 million on the data and digital infrastructure to support the National Public Health Service; and $155 million for the Southern Health System Digital Transformation Programme.
Health Minister Andrew Little says Budget 2022 supports a shift towards a national system backed by modern technology and more secure IT platforms.
“During Covid-19, many Kiwis adapted to using modern health technology, to book their vaccinations and report test results online. The transformation of health IT will allow for better, more accessible digital supports for patients, doctors and nurses.
“It’s also important that wherever you are in the country, medical staff can access your records to make the best decisions for the care you need. That isn’t always possible at the moment, with the 20 DHBs each running different IT systems.
“Joined-up IT platforms will make care delivery and administration easier. This means being able to identify issues earlier and plan accordingly,” Little says.
The Budget allocates $220 million in operating and $100m in capital funding over the next four years to ‘health data, digital – foundations and innovation’. This builds on Budget 2021 investments and includes funding for Hira tranche two.
“Investment priorities will be aligned to broader New Zealand Health Plan activities and reform objectives,” Budget papers say.
Investments from this contingency will also include; data and intelligence, digital enablement and innovation, and data and digital foundations.
Funding of $125 million will provide ongoing funding to retain selected capability and infrastructure developed in response to the Covid-19 pandemic and to provide a basis for future population health and disease management digital capability.
“This capability will help transform the delivery of public health programmes including any future pandemic response,” Budget papers say.
As part of the new operating system under the health reforms, a National Public Health Service (PHS) will be established within Health New Zealand
The 2022 Budget sets aside $10.8 million over three years to put in place a common data and digital platform for the delivery of core Public Health Unit functions so that the new PHS can operate as a single, cohesive national service.
It includes funding for a national platform to support a standard operating model and delivery of core Public Health Unit functions, as well as money to “establish access to aggregated, population-level data drawn from primary care data sources for public health surveillance and analysis”.
The Southern Health System Digital Transformation Programme has also been allocated funding of up to $155 million over the next four years ($225 million over 10 years) to deliver the digital infrastructure required for the New Dunedin Hospital, as well as investment in digital solutions that span the whole of the Southern health system.
More here:
This follows up on the 2021 Budget:
Hira funding approved, first release May 2022
Sunday, 12 December 2021
NEWS - eHealthNews.nz editor Rebecca McBeth
Cabinet has approved funding for tranche one of Hira, covering the first 2.5 years of work, and the first release is due in May next year.
In Budget 2021, the Government announced funding of up to $385 million over four years (and a further $15 million in capital funding in 2025/26) for health sector digital infrastructure and capability.
This included funding for Hira, formerly known as the National Health Information Platform, which is an ecosystem of data and digital services that will enable access to a virtual electronic health record, as needed, by drawing together data from trusted sources.
Group manager digital strategy and investment data and digital, Darren Douglass presented at a Ministry of Health webinar on the Hira programme on December 10.
Douglass told viewers that a lot of data exists in the health system, but it is fragmented and difficult to access and while standards also exist, they are not uniformly adopted.
“What this results in is a lot of time spent searching for information and clinical decisions being made in the absence of information that does actually exist, but isn't accessible to the people that need it,” he said.
“Also, a real lack of ability for an individual and those they trust to have access to their own information and to be able to use that information in their interactions with the health system.”
He said the Hira programme is not about the Ministry choosing and delivering solutions, but about looking at problems that need to be solved and trying to join up providers and technology vendors to help solve those problems.
“Hira outcomes will be delivered by multiple sources of data, multiple solutions, multiple technologies that are all able to work together to deliver what individual stakeholders need,” said Douglass.
Hira will be delivered iteratively over three tranches, with a goal to eventually be doing releases every six to eight weeks.
More here:
https://www.hinz.org.nz/news/news.asp?id=589744&terms=%22hira+and+tranche%22
There are links to some educational webinars on the Hira Programme later in this article!
I have to say this all looks like a planned process of incremental development leading to some steady process with rather less administrative spend than we see with the ADHA and DOH here.
I would love some feed back from those on the ground as to how it is all ‘actually’ going!
David.
20 comments:
"He said the Hira programme is not about the Ministry choosing and delivering solutions, but about looking at problems that need to be solved ..."
Starting with the problems is a good thing. Where things go wrong is when they try and implement solutions that solve individual problems.
The "going wrong" starts when they fail to recognise that it's not the solutions that need to be integrated but understanding how the problems are connected and that solving individual problems creates new problems.
Proponents of the Hira style initiative have been promising for over half a century to solve healthcare with IT - and failed to deliver on their promises.
My question is - what is different about Hira that will enable success?
As you said .... the correct place to start is to first "understand how the problems are connected". So, to be clearer and more precise you are saying the place to start is to.... 1. define the problems, then 2. describe how they are connected.
To be even more precise:
1. define the ALL problems.
If you don't then you run the risk of coming up with solution that fail over because you didn't realise something.
If that sounds difficult, it's because it is.
In the case of the MyHR, the government didn't realise that patients don't want what they have been given, even though it's been forced down their throats (i.e. made opt-out) and so it has been left to fester and die.
The ADHA has finally realised this and that's why they are trying to re-architect the system.
The supposed new ecosystem will sideline MyHR and use the infrastructure to collect all the healthdata they can and put it into their own systems without it being visible to patients.
and don't forget
2. describe how they are connected
In practice everything is connected to everything else - what matters is the degree to which they interact - and than can change over time and circumstances. Have a pandemic and all the connections (and priorities and difficulties) change.
Yes, that all sounds fairly close to the mark. So, back to point 1. As you said defining 'ALL' the problems is difficult, dare I say an almost impossible task unless perhaps you can delineate some boundaries to the vast extent of the health system.
Be that as it may,:
1.1 How do you propose going about defining ALL the problems?,
1.2 What resources will you need?,
1.3 How long will it take?,
1.4 Where will you draw the 'boundaries'?
1.1 to 1.4 requires competent, informed, mature, intelligent, leadership.
@5:52 PM So 1.1 should read - How do you propose going about defining ALL the problems and describing how they are connected?
Would you not want to start with some context here? The “problem statement” would be different depending on your viewpoint. I am not sure on the goal either.
Yes, a well constructed problem statement MIGHT lead to defining ALL the problems and outlining HOW they are ALL connected.
Have to agree with @john. Context is key. One actor's perceived problem, challenge or opportunity may not be the same for others and certainly not necessarily translate into actionable things.
I’d say, for example, the ability for information systems to share information and achieve Symantec interoperability was a goal - the context for a small general practice vs a large hospital vs a statewide healthcare organisation vs a federal department are very different- as are the challenges Evan at a superficial affordability level.
I don't think its possible to define the whole problem or solution in health as the domain is large and ever changing. Defining the data and a way of moving that data around quickly and reliably allows endpoint solutions to do innovative things with the data that suit the workflow of that user. A messaging model that decouples the sending and receiving system is the best option, but you have to ensure the message is compliant both structurally and wrt terminology. The simplest version is a textual document, but even that does not work reliably due to non-compliance with standards that are not rocket science.
Creating a common system or EHR is never going to work unless you impose totalitarian rules that everyone uses the same software. Given what else is happening with health I don't want to give them ideas! Such a system would become a lumbering giant that didn't work well for anyone and would advance at a glacial pace. By using a messaging model with compliance testing and only core clinical concepts modelled you can add 2 level modelling of clinical data to rapidly add clinical data models, which are inherently compliant with the messaging model. A national program would then be rigorous with compliance testing of both senders and receivers wrt the data format and enable/help clinicians to develop clinical models on top of that at a rapid pace. This is the archetype model and the focus is high quality data transfer with rapid development of needed data models which do not require changes to the underlying messaging standard.
Decoupling the layers is a core concept of creating scalable, flexible, robust systems. Each layer needs to be reliable in order to build on it, and no attention has been placed on compliance so we are going backwards as large scale systems cannot rely on getting compliant data. This is why interoperable messaging cannot work unless you have interoperable messages, but I have been banging on about that for decades to no avail.
Kind of useful to work your way through different problem perspectives. Understand the policy, regulations, and agreements that impact connected healthcare. The Australian healthcare space puts the clinician at the centre of care rather than the patient. So for connected care to be successful, there needs to be sound business models to make sharing of healthcare data sustainable regardless of the clinical benefit that might come about. Then understand the clinical and patient workflows and value propositions. After all that we can probably get down to dealing with the content and the technology. I struggle with a business model for connected care without either the patient or the govt paying. Of course, all this could be turned on its head if we decided to turn the policy model on its head and put the patient at the centre of care, including giving the patient or their assigned agent ultimate rights over their healthcare data.
Patients should get the data in the same format, its just a patient layer rather than a provider layer. There are many uses for the data, some we don't yet imagine.
Andrew are you suggesting software and information handling should be subjected to the same high standards and oversight as other trusted tools and processes used in healthcare?
Would seem a reasonable ask.
Yes, its total negligence that it is not! Decisions are made on the data and I can assure you the data is often lost or not displayed correctly currently but no one seems to care. Grade F for every eHealth agency that has existed, and there have been many, each seemingly less capable than the one that preceded it?
This is a very interesting 'thread'. Looking back it all started with Bernard's comments that the first steps are to define all the problems and describe how they are connected.
Subsequent contributors have shown this 'approach' to be somewhat unrealistic and far too generalised as it fails to acknowledge what Andrew McIntyre so succinctly states that it is not possible "to define the whole problem or solution in health as the domain is large and ever changing".
Sarah Conner said...
Context is key. One actor's perceived problem, challenge or opportunity may not be the same for others and certainly not necessarily translate into actionable things.
I agree with Sarah. Context is key, which is why it should be the first question.
There will always be more than one actor in any context. At a minimum there is the individual and their carer(s). As you start analysing the problems you realise that the format of a patient's data is very much defined by the role of the actor who needs it.
The question is - "is it possible to define a set of core health data that can be transformed into the different needs of each actor?"
My understanding of Andrew's position which he has stated several times elsewhere, not just in this thread) is that he believes the answer to be yes.
My question is - how does this happen and who does it?
My contention is that it is an unrealistic goal - but it's the goal behind "connected healthcare".
IMHO, connected healthcare can really only happen at the interface between healthcare providers (i.e. people), not IT systems.
My suggestion that we need to "define all the problems and describe how they are connected" cannot be achieved. That is useful information because it means that a lot of what people are trying to do is not possible. Rather like a perpetual motion machine.
It would seem that we need an environment in which healthcare providers can be assisted to better solve problems, rather than try and build systems that are solutions to intractable problems.
Which, in turn suggests that healthcare providers need to acquire the healthcare data they need at the point of care, not access to historical data that is quite possibly irrelevant, incomplete and incorrect.
Which translates into the problem "how can healthcare providers acquire the healthcare data they need when they need it?"
ABMay 31, 2022, 8:32 AM is a well-laid set of arguments. The “business model” in its various forms and manifestations is a problem that cascades throughout the various interested parties. It's quite an insightful post and has opened a lot of thoughts on my part.
My position is that it is not possible to "solve" the whole problem, but it should be possible to transmit the data you collect, with minimal loss, without awaiting changes to the standard. This is the aim of 2 level modelling. You want to collect some data, which should be able to be shared with another health care provider or the patient. Archetypes allow you to create a data model very quickly and is the metadata for that data. The metadata is also shareable and if it is useful should be shared and refined which is where a national body should do. It builds on the standard, but remains standards compliant and the receiver does not need to understand the archetype to view the data, but can leverage the metadata if they want.
Attempts to model the whole field are doomed, but allowing people to to create models of data quickly (Archetypes) and share those freely. Good models will become commonly used and rise to the top and those that are not interested can ignore them, and still view the data. Sharing results with patients involves sending them the data that was collected about them and opinions on that data. It should not be downgraded to eg pdf as the patient should be able to share that data with a future provider without data loss.
Its a little like having web standards and letting people use the standards to create what website they need. As something is proven useful it may get used by many users/developers.
What an individual application does with the data differs depending on the users focus, but the data is not lost and can be on sent to other users, which may use it in a different way.
Pathology does this in a basic way by using LOINC codes with lists of name=value data pairs but many clinical interactions require hierarchical models with eg repeating items in a list. This should be done outside the standard (eg HL7V2) to allow users to create models, which are ideally widely agreed to, but should not be subject to restrictions of "standardization" as its very hard to get agreement and these models should be allowed to evolve and be created by high end users as need be. We have worked with Cancer Histology reporting which is very complex and ideally standard, but that's where the resources of a national body should be used, to bring histopathologists together to agree on a model.
Having clinical datatypes, like Physical Quantity/Coded concepts in the base standard makes the job easier, but those things are already there. What I don't agree with is building all the needed clinical models into a standard, as that will go on to the end of time! Its better to have a few competing clinical models than none at all, as evolution can then occur.
Agree trying to solve a distributed model with a singularity is never going to work better to focus change on multiple small projects, some of which contradict each other but which overall have coherence.
Post a Comment