Quote Of The Year

Timeless Quotes - Sadly The Late Paul Shetler - "Its not Your Health Record it's a Government Record Of Your Health Information"

or

H. L. Mencken - "For every complex problem there is an answer that is clear, simple, and wrong."

Friday, August 11, 2017

A Request For Views - What Do You Want To See In The New ADHA Interoperability Strategy?

For a quiet Friday I thought it might be useful to get out ahead of the ADHA and think what we really want from the new Inte-roperability Strategy and how do we expect it will be implemented to actually make a positive difference?

We also need to consider just what role the ADHA might actually play - encouragement, regulation or whatever?

Over to you - this is an important area to get right!

David.

17 comments:

Paul Fitzgerald said...

Getting rid of the HL7 "industry" would be a good start. Force the dinosaur vendors to use open APIs and other modern ways of connecting to other systems. Then again, I might win lotto as well! :-(

Grahame Grieve said...

Paul: How do you see that 'getting rid of the HL7 "industry"' would force dinosaur vendors to use open APIs? How would the government construct a strategy to get rid of it? How do you think the government should force vendors to use open APIs? what other ways would you recommend?

Bernard Robertson-Dunn said...

David,

Why?

1. If they don't know how to develop an interoperability strategy themselves, they won't understand the people who do.

2. Why would someone do it for free and they get the benefits and the cash.

3. Let's face it, they've never listened to experts before, this isn't going to be any different.

4, It's actually very hard if you do it properly. And by doing it properly I mean looking at the processes of acquiring data, of managing data, of responding to requests for data, of pushing data, of receiving data, of managing it at the the receiving end and of using it for clinical outcomes.

There's much more to interoperability than data standards for interchange. It's the processes that matter, the data requirements then follow.

Considering Health, NEHTA, ADHA have never looked at any of the processes of creating and then using health data for clinical outcomes, it's most unlikely they'll start now.

These are all issues that should have been covered in the Business Architecture and as we know, from someone who commented on this blog a while ago (March 03, 2017 9:36 AM) when I pointed this out previously

"Anyone in manufacturing or construction (be it highways or software) would recognise the Owner's requirements, the Engineer's design and the Manufacturing Engineer's design"

they didn't develop a Business Architecture, they thought they were building a factory or a building.

TL:DR They don't understand the problem.

Anonymous said...

Fair question Grahame, not sure why standards are referred to as dinosaurs they like legislation the status quo the breads a need to extend barriers. Anyway and under whose mandate will the standards exist? standards australia? hl7 australia? agency? Who is the newly discovered standards expert in the agency?

Is the ADHA now the national SDO? if so do they now fall under ANSI?

As for there interesting leap into interoperability, let them, the current narrative is great, I look forward to the balancing layers of agreement and divergences, after all there is not much on Tv at the moment.

Grahame Grieve said...

All good questions. 1 comment: ANSI = American National Standards Institute. They are not interested in standards from other countries

Anonymous said...

Perhaps not Grahame but SDO's are overseen but bodies like ANSI are they not to ensure due process is followed? I believe HL7 is under the same inderpendent oversight and thus HL7 Aus. The value of standards is the process in which they are created. I wonder if the ADHA is

John Scott said...

Bernard, agree fully on points 1-3.

Further, agree on point 4.
We need to separate the human clinical communications from the electronic in order to establish the base for shared meaning and the norms of healthcare communications.

These are intrinsic to providing the foundations for connecting the human sphere of healthcare with the electronic sphere and addressing the interoperability specifications.

This appreciation and the value it delivers to both healthcare and to technology vendors has not been recognized by government.


Anonymous said...

Perhaps the ADHA needs to go on a journey of discovery, will they copy ONC, UK, or Joinup EU. Do they appreciate that everything the do must contribute to interoperability. A standard does not live in isolation from other standards, nor will technical standards alone, deliver you interoperability. I would like some architecture positions from ADHA, and consensus based guidance on how numerous competing and complimenting standards will co-exist. For interoperability just simply identify the consequences of interoperability, who knows maybe we are not ready, it's not safe, maybe we only want to see it in certain settings.

I am interested who is to lead this, the forum Bernard posted a few days back claims a panel of experts in this field, what is interesting apart for the bold claim, is who is not on it. That maybe the tick in the box session for these questions.

Personally I think they are doing this for perception reasons, the MyHR is all they care about.

Andrew McIntyre said...

The concept of "Getting rid of HL7" is quite amusing, Health connect, and the NEHTAs tried this and discovered after many years (and just before they were axed) that it was a bit harder than they thought. Just because something was developed many years ago does not mean the "replacing it with something more modern" is useful. In fact something old was developed to function on limited computer resources and it should fly on modern hardware and in fact it does. Given that the functioning eHealth we have is based on HL7v2 and we have transmission of the vast majority of pathology as atomic data now and there is nothing left of the work done by Healthconnect or NEHTA, I would argue that we need to get rid of all this government "help" and let the things that work - work without clueless generic managers wanting something "more modern". Look at how much risk is involved in replacing the old Government IT that runs Medicare. If we could easily solve problems with something "More modern" that would be an easy job. Code does not rust and progress is not always forward.

In reality all the effort on replacing HL7 V2 has allowed implementations to actually prove they work while HL7V3 failed. If FHIR will replace V2 is yet to be proven. Most likely it will have a place in new things rather than replacing V2, but widespread use will take significant time.

Lets get rid of government "help" and clueless middle managers, rather that proven technologies like HL7V2.

Anonymous said...

The contrariness of your last para Andrew (which I support) is that you and other vendors contradict yourself by taking the ADHA's money to feed the MyHR with data from your system perpetuating the survival of those you are complaining about! Sorry to be so blunt.

Grahame Grieve said...

With regard to ANSI: While HL7 - inasmuch as it produces US standards - is subject to ANSI auditing, HL7 Australia is not under the supervision of ANSI. Nor anyone else. HL7 Au may choose to follow ANSI rules (they aspire to) but ANSI won't audit them. Nor is there an appropriate body to perform this role, either for Stds Australia, HL7 Australia, ADHA, or DOHA, at least not to my knowledge (and we've seen the fall out from Stds Aus lack of one)

@John Scott: "We need to separate the human clinical communications from the electronic" - how do you see that working? removing electronic support for human communications? Long live the fax? or just the phone? Perhaps I've drawn the wrong inference?

@Andrew McIntyre: one of the interesting things about your well-established position is that you externalise some costs to other parties, but then pretend that no one should object to this because 'the market should sort it out'

Anonymous said...

Thanks for the clarity regarding ANSI type organisations I assumed there was oversight and governance that ran through all the various SDOs. Andrew I think tearing people with the same brush does not help, not sure what middle management is from the fizzing hieghts of leadership in a local IT firm catering to a cottage Iat industry but I do know there have been managers who at great personal cost tried over the years to keep standards front and centre.

Andrew McIntyre said...

At this point we have received no money from the ADHA, although we are part of a project to improve HL7V2 compliance of REF messages, which, from what we are likely to get paid would not cover our costs. This is in line with my "position"

Sorry Graham, I have no idea what you are talking about. I don't think the government should splash money about as they are so bad at directing it. I think governance should force endpoints to be compliant and users should pay as users will want value for their money.

I would prefer that all costs were externalized from government so people evaluate their value for money. However we do need a requirement for quality which probably has to come via regulation. The costs should they be born via government should go to $ to providers to spend as they see best. Medical/Allied health providers have to pass exams and Medical Software should also pass exams.

Anonymous said...

What does the ADHA mean by license to operate? This smacks of market manipulation, how does the ADHA, having any say in what private health do? The Federal Government can't even get the States to adopt things?

Anyone have any insights?

Anonymous said...

Why would the ADHA invest in standards work? They operate systems now unlike NEHTA that was there to create national standards and specifications that allowed any number of solutions to be created from. As a system operated I would assume they expect products and services to standards compliant? As for interoperability the same thinking would apply, their concern will be that everything is interoperable with their products and services.

Andrew, Tim seems clear on this and the ADHA, is the market

John Scott said...

Graham, you have drawn the wrong inference. You separate the human communications from the electronic enabling communications to recognize that clinicians, especially doctors, have to sort out how they want to communicate with each other and under what circumstances.

For example, in a project some years ago, we were challenged to sort out the use of the term 'acute' in respect of 'Acute, Unstable, Pediatric, Asthmatic' for use in electronic communications. The question was, can a GP apply the qualifier 'acute' and if so, will it be trusted by other parties involved in supporting children with this diagnosis? These other parties being the respiratory specialist, A&E, and the Pediatric Ward of the hospital. The short answer was NO. It was agreed, at the time, that the determination was to be made by a respiratory specialist.

This is but one example where well-meaning IT professionals should stay well clear. Once there is agreement on semantics and the conditions under which particular information can flow, then you have the basis for technical specifications. And, I would add from personal experience, these discussions can be very difficult and even approaching some of them can take months to set up the forum just to talk about them.

I can go into some of the institutional apparatus you need, but I respectfully suggest this is a critical, strategic issue.

Grahame Grieve said...

ok, that's clear. My experience is that the process of figuring out how clinical communications are best served by IT capabilities is best done as a partnership, with clinicians driving the requirements, but with strong informatics support to help them frame the requirements so that lead to useful outcomes. But even then, there are many things that can wrong - stark variance between different clinicians, engagement from the wrong ends of the normal distribution, managers using IT techniques to force business process change, arcane informatics techniques obscuring problems with the requirements or the expression of the solutions (etc).