This article appeared a few days ago:
How to Accelerate the Adoption of Digital Health Technology
April 26, 2018
In 1997, health information technology and digitial health pioneer Warner Slack wrote his bold and prophetic book, Cybermedicine: How Computing Empowers Doctors and Patients for Better Care. Slack argued that “the electronic digital computer, with its capacity to hold large amounts of data and to execute multiple complex instructions and accuracy would…find an important clinical role in both diagnosis and treatment.”
While the digitization of health information has solved many problems in American medicine — particularly, helping to reduce medical errors by enhancing clinical decision support — it has inevitably created many new ones. Clinician-oriented solutions such as electronic health records (EHRs) are contributing to physician burnout instead of facilitating patient care. Many anticipated that health information technology would reduce costs by limiting the duplication of tests and studies, but there is little evidence that it has accomplished this. And while patient-oriented digital solutions have proliferated in number, their clinical impact has been limited. Slack anticipated a world in which patient access to records would enhance “patient power” — yet many patient-oriented solutions have little relevance in the clinical exam room.
Yet there are rays of light, each of which shares a common denominator: a rigorous focus on the specific needs of the end user, be it patient or clinician. When creative health systems consider and engage the end user of the digital technology as the “customer” of that technology, adoption levels are high and so, too, is the impact. Two CareMore Health initiatives serve as examples: One provides patients with non-emergency transportation, and the other is a new secure platform for clinical team communication and collaboration.
Patient-oriented solutions.
----- Lots omitted
Clinician-oriented solutions. As a physician-led organization, CareMore’s approach to health IT implementation fully embraces the end user at the outset. Clinicians identify the problems to be solved and collaborate during the testing of solutions to help the information technology team refine the app. Once fully implemented, continual refinement and oversight of the solution is managed collaboratively by physicians and members of a digital implementation team to ensure that the technology is being embraced and effectively utilized so its benefits are fully realized.
An example is TigerText, CareMore’s new secure platform for clinical team communication and collaboration. Inpatient, hospital-based physicians were accustomed to using phone calls, text messages, faxes, and e-mails to communicate with various outpatient physicians such as primary care doctors and specialists, and information was delivered to the members of the clinical team in question in a fragmented and inconsistent way. The new platform required clinicians to move to a single platform for communication.
----- More omitted
When the end user identifies the problem, participates in building in the solution, and continues to engage during its refinement, adoption is inevitable.
***
The American health care system is in constant need of innovation and digital health has the ability to provide solutions to some of its biggest challenges. As simple as it is, the industry has often failed to engage the end user in building solutions. By placing greater emphasis on the problems of the end user — and less emphasis on the systems themselves — health care systems will perhaps succeed in creating the cybermedicine revolution prophetically envisioned by Dr. Slack.
The full article is here:
This sentence says it all:
“Yet there are rays of light, each of which shares a common denominator: a rigorous focus on the specific needs of the end user, be it patient or clinician.”
I have been making this point since the days of the PCEHR. You can’t have a system that at the same time is optimised for the clinician to use and at the same time for the patient. It just does not work and HBR agrees!
Why can’t the ADHA just stop this nonsense before we are all both clinically and technically frazzled. One application simply cannot be optimised for both clinicians and patients!
David.
A quote from the article:
ReplyDelete"While the digitization of health information has solved many problems in American medicine — particularly, helping to reduce medical errors by enhancing clinical decision support — it has inevitably created many new ones. Clinician-oriented solutions such as electronic health records (EHRs) are contributing to physician burnout instead of facilitating patient care. Many anticipated that health information technology would reduce costs by limiting the duplication of tests and studies, but there is little evidence that it has accomplished this. And while patient-oriented digital solutions have proliferated in number, their clinical impact has been limited. Slack anticipated a world in which patient access to records would enhance “patient power” — yet many patient-oriented solutions have little relevance in the clinical exam room."
IMHO, the problem lies in the title of the article: "the Adoption of Digital Health Technology"
Adopting Digital Health Technology tries to automate the past and most often does it badly and with unintended consequences.
Unless there are genuine transformational outcomes that deliver better ways of doing clinical medicine (i.e. fix problems with a siloed/disease structured health care system; diagnoses and treatment oriented towards symptoms and risk reduction; and the availability of drugs that are designed and tested based upon biomarker/risk correlation not health problem causation) then progress will be stagnant.
The problems facing health care systems/clinical medicine are far more complex and difficult to fix than simplistic approaches to gathering and storing health data. And considering most attempts to build health/Medical record systems are spectacular failures, it's no surprise that harder problems are not getting fixed.
I think for both patients and providers we want high quality standards based (HL7V2) atomic data with standard terminology and clinical models and mechanisms for authentication and encryption ie a PKI infrastructure, probably today with a public maintained OAuth system.
ReplyDeleteThe systems that patients and providers need are different, but the data should be the same and not lost from its original form to prevent loss of fidelity. If it is retained in the same form it can be on sent by providers or patients without losing detail.
So what sort of things should government be doing to encourage this process?
1. Standards Compliance
Systems need to be able to receive standards based messages and display them reliably
They also need to create standards compliant messages
2. Retention
Data should be retained in its original form so it can be resent to another system. Conversion to pdf is useless.
3. Provider Identification
The provider number data/names/locations should be freely available. The current identifiers are not location specific so would have to be combined with location IDs and they do not exist or exist at wrong level of granularity.
4. PKI Infrastructure
There is so much manual work in the current system it does not scale and many people who need data are not part of the system. It needs to be universal across all health care providers and the individual keys, which have been phased out did allow for a proper digital signature and authentication. Its all half done. A universal OAuth system maintained by government for patients and providers would be very useful. I am not sure trusting google or facebook OAuth is good enough.
5. Terminology
We have SNOMED-CT but needs more resources so can be responsive to clinical need.
6. Clinical Modeling
No standard is going to have all the data structures for every new thing and platform agnostic modelling of the clinical domain needs to be done in a similar way, although better resourced, as the pathologists have modeled cancer reports. Because there is no compliance regimen getting these implemented is problematic as end users don't demand it. Radiology reports are all text and should have atomic data for decision support and there are a host of clinical procedures that need reporting models. Getting agreement on those models is a difficult, expensive process but needs to be done.
7. Inter-operable messaging
This is highly dependent on compliance so that it can just do the messaging and leave fixing issues to the endpoints. It also requires universal PKI infrastructure as if you don't have access to trusted keys how do you secure the payload and authenticate the sender. Its useless doing this as step 1, that is just naive.
8. Stop trying to be the only game in town
Its frustrating that rather than ensuring high quality data to allow connectivity and data sharing and allow the ecosystem to flourish we are reducing the data to pdf inside a CDA document and losing the atomic data. This is the way MyEHR works and does not provide a path forward to real eHealth but is the "Expedient solution" After $2 Billion spend an expedient solution is not good enough. I considered the expedient PIT solution 20 years ago and though it was not forward looking enough because of the lack of atomic data. The PDF solution is worse than PIT as PIT would be tiny, searchable and probably widely supported, makes be wonder if I made the wrong decision back then to do it properly, but there is no way the MyEHR "Solution" is anything more than a gold plated boat anchor that they are trying to tie around our neck. I am sure the executives are planning on doing that and saying "Bon Voyage" as they race out the door with their undeserved rewards.
At some point the ADHA has to actually tell the truth and be responsible and admit they don't have a real solution and are just a road block to progress... and let someone address the infrastructure needed to ALLOW good things to grow organically.
Non-medical experts see health care as being like other industries as being a simple system to document activities and automate. While some similarities can be made across the health care domains you are talking about >100 occupations, 30'000+ conditions, 20'000+ medications/tests/treatments, and over a million possible situations combining the variations above.
ReplyDeleteIf standards are wide spread, then why does it take so much time and effort ($$$) to implement and customise an installation of software for hospitals? If the systems were based on research and standards, then the customisation should be minimal.
If software for GP's and specialist are so "great" then why is it so hard to get data from them which are statistically complete and reliable? You can get data from them but relying on text mining free text and AI doesn't make up for cases of 65% missing data. They must be a fool if they believe you can get accurate results from garbage input. We can build systems that capture data, but it requires extra time & money to incentivise doctors to ensure more completeness of just a small sample of patients.
1) What questions do you want to answer with data?
2) What data is required to answer those questions?
3) How do we minimise the data entry required to record that data?
4) How do we use standard terminologies, coding and classifications to record the data?
5) Who needs what, where and when?
6) How do we optimise the data entry layouts and processes to support the natural clinical care processes (task flow)?
Compared to banking, health care has of the order of: 10x the industry occupations; 1000x the customer types; 100x transaction types; 10'000x the rules; 100'000x scenarios. This increase in complexity must be acknowledged and respected. It's not an impossible problem but it has to be broken down, be more standardised and requires funding the required work to properly build the foundations.
Some standards fail to meet the expectations of all users, developers and potential data analysts. You cannot please all the people all the time, but we must create a roadmap for all to work towards a better future. FHIR, SNOMED-CT, interoperability, MyHR, portals or blockchains are not solutions by themselves, it will require much more. Thinking we have 90% of what we need is incorrect. We need a report that investigates the progress to date and how much more is needed.
These efforts must be started by the various occupations and organisations. The importance and the required methods must be taught in the University courses. Researchers must be funded to develop, test and maintain standards. Software developers must have a long-term plan for improving and implementing standards. You would be a fool to think an economist or business analyst could properly analyse the problems and suggest a plan to improve the health system as they have in other industries using ICT.
Why code? Why classify?
We were also promised great benefits from computerisation in health care but most of the promised benefits have never come. IT is seen as a great burden and risk. Standards are often incomplete or frowned upon by developers/users. You may think me a harsh critic and pessimist but understanding the realities of the whole system is very hard to comprehend. Over 98% of workers in the healthcare system would only understand a small area around themselves. Why else would these big projects fail? Why else would even the simple definition of "What is eHealth?" get bogged down into definitions of implementations and desired outcomes by >99% of industry participants instead of a strict definition (<1% know what they are doing). Asking more people or collecting more data is not the solution. Asking the right people, the right questions will get us closer to the solutions.
tygrus
ReplyDeleteI totally agree, especially with "Non-medical experts see health care as being like other industries as being a simple system to document activities and automate", I've been saying it for years.
I've been reading a couple of books to find out more about clinical medicine:
Oxford Handbook of Clinical Medicine and Oxford Handbook of Clinical Diagnosis
Neither book makes mention of computers or information systems, and Health Records, Medical Records or Patient Records, only in passing.
Both books put a lot of emphasis on listening to the patient - all Digital Health is doing is distracting doctors from real health care.
The Diagnosis book does cover Patient Medical History but the description and guidelines are nothing like Health Records and even less like MyHR.
I also agree with Andrew. The message behind "So what sort of things should government be doing to encourage this process?" is that government, especially the Federal government, should play an encouraging role and not be a player in the game - and "trying to be the only game in town" compounds the problem.
IMHO, the government and ADHA should identify some real problems that the medical community agrees that there would be value in them being solved. They should then facilitate work to help solve those problems. Nether the government or ADHA are equipped to solve such problems.
Maybe the new CRC might be a way forward, but until we learn more about what they will be doing and the problems they intend tackling rather than them just listing some solutions and unjustified outcomes, we won't know.
And yes, I know I'm ignorant of what the CRC is all about, but that's my complaint - they aren't telling us.
"If standards are wide spread, then why does it take so much time and effort ($$$) to implement and customise an installation of software for hospitals? If the systems were based on research and standards, then the customisation should be minimal."
ReplyDeleteThat is the problem, they say they are based on standards but they are not compliant and cannot talk to each other without significant work from "Interface Engines" in between. Usually when trying to get 2 systems talking, there are errors on both sides so you end up with a middle man trying to fix these errors rather than making compliance a requirement. If there is disagreement about what is right then that discussion should be held, and this is not what has not been done or written into contracts. Its often a commercial advantage not to allow systems to inter-operate as it locks people into one vendor.
On the web things have gradually become more compliant and standardized, but it took a lot of pain and work to make that happen. We have lacked the proper governance to allow that to occur in the health domain because people pulling the levers don't understand the technical and clinical issues. When something doesn't work they go and talk to their mate in banking because they have it sorted!
Andrew I wonder if there is also a misconception about standards. There is a lot of talk about ‘a standard’, this is incorrect. Many standards inform one or more solutions. If you look around the room you are in, how many standards support the building architecture?
ReplyDeleteAnyway on a positive the CEO of ADHA is promising that the MHR will be clinically used and useful so that must be a positive? Be simple to implement MHR compliance regimes
Hi Andrew and other colleagues,
ReplyDeleteI am not going to enter into the discussion regarding the usefulness and viability of MyHealthRecord. While I do have some views on that matter, I don't think they'd add anything new here.:-)
What I am very interested in is putting in place the right tools and processes that will help a patient in his/her journey through the healthcare system and here I am talking about referrals, discharge summaries, specialist letters, patient status reports, prescriptions, lab requests and results, when in place these are electronic transactions that one might describe as the lifeblood of the modern healthcare system.
In my view, the decision to put in place a centralised health record has distracted us somewhat from doing what we might have done without it, however MHR will not be going anywhere soon.
For that reason I believe it may be necessary to view CDA messaging as a fait accompli for all Referral and Discharge related messaging. The reason for that, is that hospitals and state jurisdictions have taken on CDA and seem to have very little interest in adding HL7 messaging to that.
Clearly pathology and radiology messaging are still better suited to HL7 v2 at this point.
A significant question is what impact FHIR will have?
But in the meantime, I think we probably should be using CDA to get the critical mass of messaging in place with larger players that will in turn drive wide-spread adoption by smaller players.
Because hospitals and state-based healthcare organisations have adopted CDA, I see little choice in terms of a way forward - irrespective of the real or perceived drawbacks of CDA.
Thoughts on this Andrew?
Kind regards,
Tom
Tom,
ReplyDeleteHL7 CDA is a document standard, not a messaging standard. CDA documents still need to be transported using a messaging protocol and standard, such as HL7 Version 2 - which is how, to use on example, GP2GP transfer (CDA) documents are transferred in New Zealand. While it's not my place to comment on the selection of HL7 standards in Australia, it might be worth noting that FHIR is now HL7 International's 'primary standard' and that there is a migration path from CDA to FHIR documents.
Best regards,
Peter
How do patient care plans relate to MyHR?
ReplyDeleteViewing a patient's care plan history using HPOS
https://www.humanservices.gov.au/organisations/health-professionals/enablers/viewing-patients-care-plan-history-using-hpos
As Peter said, CDA is a document standard so its not an alternative to HL7V2, but an alternate format for the document part of V2.
ReplyDeleteI don't see a future for CDA and don't see great support out there for it other than some canned html display of the CDA documents.
For provider to provider or provider to patient messaging I think V2 is in much wider use, is more semantic that the CDA we have and more widely supported. Systems need to have better V2 support for pathology and what works for pathology also works for clinical documents. The CDA offers no advantages and some disadvantages and does not have a coherent model underlying it. The pharmacy CDA was a total joke as using a document to manage a clinical process is just silly. You need messaging to do that!
Moving to FHIR would be a far better choice than CDA, but thats not going to happen quickly even if it does eventually succeed. CDA is a dead end back alley that is unwise to enter at night. Improving support for V2 and doing some format agnostic clinical modelling of data and workflow is badly needed for any format to work. CDA lacks an underlying model and messaging framework so I think its a waste of time, although we do support the limited functionality it provides.
Tygrus's point #4
ReplyDelete"4) How do we use standard terminologies, coding and classifications to record the data?"
illustrates the problem stifling innovation due to lack of standards for *recording* of clinical information via agreed structures and APIs/messages for electronic health records. These are necessary to enable multiple vendors, DSS organisations, academic groups etc to query applications and provide value add-on services which are beyond the reasonable capabilities of any one provider of a health care facility's main EHR+Application suite. Messaging and terminology, difficult as they are, do get addressed because of the perceived immediate need to communicate, but being able to develop processes to manage the data needed / supplied is less well targeted by standards and industry groups. EHR standards are necessary to predictably contain the HL7/FHIR, SNOMED etc information necessary to support the next level of digital health innovation.
Re David Rowed's comment
ReplyDeleteYes there needs to be a layer above the level of the standard which models clinical content, which is not modeled and never will be modeled by the standard. It also allows rapid responses to the need for new data collection and archetypes/templates can be used in HL7 V2 to achieve this (As it can in openEHR and hopefully FHIR, but have not checked lately where that is up to)
The advantage in HL7V2 is that existing systems do not see the modelling unless they want to, but continue to accept and display data without change and still have atomic data available. Retention of the original format would allow them to come back in the future and extract richer semantics.
ReplyDeleteThanks Andrew and Peter,
My interest is in seeing growth of messaging. I am particularly interested in seeing high volume adoption to replace faxes, letters and phone calls.
My observation is that a lot of the state jurisdictions are using CDA referrals and discharges wrapped in HL7 MDM messages, per a NEHTA sponsored approach. Also I note that all of the major medical GP and Specialist medical records/software providers support CDA also.
Conversely however none of these parties seem to be able to reach agreement on what constitutes an HL7 2.4 REF message and they seem to be falling back to v2.3.1 which has significant limitations and is certainly not interoperable.
Meanwhile FHIR has great promise but is not yet ready to fulfil this role.
So to me it comes back to using CDA - (the least bad option).The clinicians of Australia are long-overdue for some good news on this front. Andrew and Peter, does my logic stack up here? Or am I missing something?
Kind regards,
Tom
Tom said: My interest is in seeing growth of messaging.
ReplyDeleteMaybe that's because you're a vendor. Some of us are interested in improving health care outcomes.
Tom,
ReplyDeleteIt's not really appropriate for me to provide any prescriptive advice on the selection of HL7 standards in Australia but, as a general observation, I'd say that the quality of the information that's exchanged is a more important consideration. Genuine and demonstrable compliance with the standard of choice, and related implementation artefacts, is also critical if any true degree of interoperability is to be achieved.
Peter
I don't see hospital discharge summaries as the major component of communication and its provider to provider communication that I focus on, ideally with good semantics. If people can do pathology well they can do clinical communication with V2 well. One of the major advantages of HL7 V2 is backward/forward compatibility and we don't see a lot of issues moving between the versions in use.
ReplyDeleteBecause CDA has no underlying model and clinical communication requires new document types all the time, V2 is a lot more flexible wrt content, just like pathology is not restricted to one result type. The CDA models are fixed to one usage and in Queensland V2 discharge summaries are still in use.
So, not I don't buy the argument that moving to CDA is the answer to anything. The answer is improved standards compliance to everything, CDA included. Pathology usage of V2 means that V2 compliance should be high on the list of priorities.
Talking about discharge summaries:
ReplyDeleteGPs want clinical handovers, not discharge summaries
https://www.doctorportal.com.au/mjainsight/2018/10/gps-want-timely-appropriate-hospital-handovers/
"In the real world, GPs are grappling with being thrown links to hospital electronic records through systems such as “The Viewer”. Investigations are likely to be uploaded (after a delay) to MyHealthRecord. These are raw data, unfiltered and disorganised, and more of a throw than a handover. Being thrown raw data and being expected to catch them in this way is akin to a hospital doctor being given the login to the GP clinic’s patient management system and being expected to extrapolate a referral."
Thanks Andrew,
ReplyDeleteI think that using this opportunity to discuss debate issues in a collegial way is very beneficial. So thanks for indulging me as I try to tease apart the arguments, in the interests of finding common ground and a strategy we can take forward. Clearly there needs to be agreement amongst parties such as ourselves to make meaningful progress.
Peter, you say "It's not really appropriate for me to provide any prescriptive advice on the selection of HL7 standards in Australia" - I think actually it really is appropriate, because few people have your level of understanding and the sector as a whole is crying out for more connectivity, more information liquidity and better interoperability. Few people have the depth of understanding that you Andrew and (dare I say) I? have on this arcane but very important topic. So I would urge you to put forward your views to help the cause. It is great to have your input on it.
Andrew, while I agree that HL7 messaging is very important and has done us well to date and is likely to continue to do so on a number of fronts, my view is as follows:
The State Governments and hospitals have committed to CDA (albeit perhaps for the wrong reasons) but they most certainly are ready to send and receive CDA discharge summaries, referrals etc. The major GP EMR vendors are ready also and in some cases using it with a vengeance.
Our experience (in the Easternmost state of Australasia) is that to get information liquidity really happening you need those larger players pumping information out to general practices and that really gets the ball rolling, the GP to Specialist piece is made a lot easier if electronic communications has already become de rigeur in a region.
And lastly, while some practices appreciate the benefits of 'content flexibility' many just want to replace paper and want a reliable and straight forward, fully dependable way to do that.
In conclusion, I have no beef whatsoever with HL7 v2, versions 2.1- through to 2.9 and would strongly encourage its use in areas where it is clearly the right answer. However I do buy into the 'let's keep it simple, let's get rid of the fax machine dogma" and just want to get on with replacing paper with simple and reliable electronic comms.
Lastly - I fully agree with your comments re the need for improved standards compliance. I am very disappointed at the lack of progress on this and am currently agitating for it.
Thanks for allowing this exchange of views, let's work together and see if we can make some real progress.
Kind regards,
Tom