Thursday, October 19, 2017

Grahame Grieve Points Out That The Architecture Of The myHR Is Fatally Flawed And Needs Change!

 Grahame Grieve posted this a day or so ago - and remarked to me that the audience here would expect me to repost it for their consideration and discussion!

Argonaut in Australia, and the MyHR

Posted on October 17, 2017 by Grahame Grieve
Project Argonaut is coming to Australia. That is, at least one major US EHR vendor is planning to make their SMART-on-FHIR EHR extension interface available in Australia during 2018 (discussion about this at Cerner Health Conference where I was last week). HL7 Australia will work with them (and any other vendor) to describe what the Argonaut interface looks like in Australia (short answer: not much different: some different patient extensions, a few terminology changes (not RxNorm), maybe a couple of extensions on prescriptions for Reg24 & CTG). Also, HL7 Australia will be planning to engage with Australian customers of the US EHR vendors to help build a community that can leverage the capabilities of the SMART on FHIR interface.
This is a big deal for Australian EHR vendors that compete with the US vendors – they better start offering the same capabilities based on the same standards, or one of their key market advantages will be consigned to the dust of history. They’ll also find themselves competing with established SMART on FHIR Application vendors too. So I look forward to good engagement with Australian companies as we flesh this out (I know at least one will be deeply involved).
This also offers us an opportunity to consider what to do with the MyHR. The government has spent a great deal of money on this, and results have been disappointing. (Yes, the government publishes regular usage stats which show continuous increase, but these are not the important usage metrics, and they’re not the kind of stats that were hoped for back when we were designing the system). And it’s hardly popular amongst the typical candidate users (see, for example, AMA comments, or for more color, this or even David More’s blog).
But I’m not surprised at this. Back when it was the pcEHR, the intentions were solid, and though the original timeline was impossibly tight, it came together in an amazingly quick time (kudos to the implementers). But as it came together, I knew it was doomed. This is inevitable given it’s architecture:

Salient points about this architecture:
  • The providers push CDA documents to the central document repository
  • Patients can view documents about them
  • Patient’s can write their own documents, but providers won’t see them
  • Patient’s can exert their control only by ‘hiding’ documents – e.g. they can only break the flow of information (reminder, the internet age treats censorship as damage and routes around it)
  • Clinicians can find and read documents
  • Each document is it’s own little snap shot. There’s no continuity between them, no way to reconcile information between them
  • There are no notifications associated with the system
You can’t build any process on that system. You can’t even build any reliable analysis on it (stakeholders worried about the government using it for secondary data analysis shouldn’t, in general, worry about this, it’s too hard to get good data out of most of the CDA documents). These limitations are baked into the design. That’s why I went and developed FHIR – so that when the full reality of the system become evident, we’d have a better option than a document repository.
Well, 10 years later, and we’re still trying to load ever more use into the same broken design, and the government sponsors are still wondering why it’s not ‘working’. (at least we stopped calling it the ‘personally controlled’ EHR, since it’s the government controlled EHR). And as long as it exists and is the focus of all government efforts to make digital health happen, it will continue to hold up innovation in this country – a fact which is terribly evident as I travel and see what’s happening elsewhere.
But it doesn’t have to be like this.
The MyHR is built on a bunch of useful infrastructure. There is good ideas in here, and it can do good things. It’s just that everything is locked up into a single broken solution. But we can break it up, and reuse the infrastructure. And the easiest way I can see to do this is to flip the push over. That is, instead of the source information providers pushing CDA documents to a single repository, we should get them to put up an Argonaut interface that provides a read/write API to the patient’s data. Then, you change the MyHR so that it takes that information and generates CDA documents to go into the MyHR – so no change needed to the core MyHR.
What this does is open up the system so all sorts of innovation, the most important of which is that the patient can authorise their care providers to exchange information directly, and build working clinically functional systems (e.g. GP/local hospital, or coordinated care planning), all without the government bureaucrats having to decide in advance that they can’t be liable for anything like that. That is, an actually personally controlled health record system not a government controlled one. And there’s still a MyHR for all the purposes it does exist for
This alternative looks like this:


All the providers – even the MyHR – put up the same Argonaut interface.
The salient features of this architecture:
  • The providers make healthcare information services available using an Argonaut interface (including write services)
  • Patients can control the flow at the source – or authorise flows globally through myGov (needs new work on myGov)
  • Systems can read and write data between them without central control
  • The MyHR can pull data (as authorised) from the sources and populate the MyHR as it does now
  • Vendors and providers can leverage the same infrastructure to provide additional services (notifications, say)
The patient can exert control (either directly at the provider level, or through mygov as an OAuth provider) and control the flow of information at the source – they can opt-in or -out of the myHR as appropriate, but they can also share their information with other providers of healthcare services directly. Say, their phone’s very personal health store. Or research projects (e,g, AllofUs). Or, most importantly and usefully, their actual healthcare providers, who can, as authorised by the patient, set up bi-directional flows of information on top of which they can build better coordinated care processes.
These features lead to some important and different outcomes:
  • Clinical Trials and companies can innovate to build distributed care models that provide a good balance between risk and reward for different populations (instead of the one-size suits bureaucrats that we have now)
  • Patient’s can control the system by enabling the care flows that they want
  • Clinicians can engage in better care processes and improve their process and outcomes (though the US process shows clearly that things get worse before they get better, and you have to plan for that)
This isn’t a small change – but it’s the smallest change I know of that we can make that preserves the MyHR and associated investment, and gives us a healthcare system that can innovate and build better care models. But I don’t know how we’ll think about getting there, given that we’re still focused on “make everyone use the MyHR”.
Note: Adapted from my presentation yesterday at the HL7 Australia Meeting

Here is the link to the original blog:

http://www.healthintersections.com.au/?p=2720

To me this is spot on but it is my view there are additionally some other issues that add to the 'fatally flawed' case. Among these I would highlight that you can't build a system for both patients AND docs and that any secondary system is intrinsically dangerous because of synchronisation and currency issues. I hope the ADHA is listening!

Enough said - this is Grahame's blog!

Comments welcome!

David.


18 comments:

  1. Why should there be a central repository of any sort?

    The problem facing health professionals is one of access to data. Any solution that involves a central database is fundamentally flawed. The cost of making such a database highly available 24/7 is a) very very high and b) impossible

    It also introduces problems of data synchronisation/consistency/completeness and, as David points out, has no processes/data management associated with it - it's just a data bucket/hacker's honeypot.

    The alternative - a distributed system that puts the data close to a patient's health carers (whose systems are designed to support processes and provide data management), and which offers redundant pathways to be used to access these data in times of emergency is a) much more resilient, b) cheaper and c) clinically useful.

    Oh and it also means not giving your health data to the government to keep forever.

    I totally support Grahame's statement that the architecture of MyHR is fatally flawed, however, I don't agree with publishing data. IMHO what is needed is an indexing system letting local health systems know where the data is, interoperability on a point-to-point basis and controlling access on need to know policies.

    Patient access should be mediated by the patient's health carer who can interpret/curate the data according to the patient's needs and capabilities.

    IMHO, giving all patients access to lots of raw medical treatment data is naive. Giving it to the government is totally unjustified.

    ReplyDelete
  2. > however, I don't agree with publishing data. IMHO what is needed is an
    > indexing system letting local health systems know where the data is,
    > interoperability on a point-to-point basis and controlling access on
    > need to know policies

    I'm not sure what you think the difference is... what I meant is pretty much what you described

    On the other hand, there is very clear reasons to think that "giving all patients access to lots of raw medical treatment data is" a good idea, not a naive idea. What is naive is thinking that that giving patient's to raw data is all you need to do

    ReplyDelete
  3. Grahame,
    I was drawing a distinction between the data and the location of the data. I assumed that "publishing" meant the data rather than the location. My apologies if I got that wrong.

    Having seen the raw data from my GP's system, a lot of it is incomprehensible to me because it is in a language meant for health professional-to-health professional communication, not professional-to-layman communication, even an informed and motivated layman.

    I certainly agree that there needs to be more than just giving patients access to the data. That's why I suggested that the GP should be the intermediary. IMHO, underpinning patient centric health care is a primary contact between the patient and the health care system. It doesn't always have to be the same contact but having multiple contacts can lead to problems.

    There's more to improving health care than just better access to data.

    ReplyDelete
  4. An interesting perspective and welcomed reintroduction to the debate, thanks Grahame. However, does this solved the centralised/federated architecture question? Probably not in as far as it brings closure. It certainly opens things up to a wealth of possibilities that frankly a PDF store will never reach. Does it allow information to be sourced and injected directly and effortlessly into clinical workflows? Love to here other thoughts.

    ReplyDelete
  5. And like it or loath it, FHIR has been created using all the ingredients that we say are missing in other areas, it is open to all, collaborative and inclusive, the full spectrum of stakeholders and their respective view points created this standard and its meritocracy puts many to shame.

    ReplyDelete
  6. Grahame, thank you for opening up the whole architecture question. Hopefully, we can move the e-Health agenda forward through a productive challenging of the knowledge and assumptions underpinning the MyHR and indeed other digital health strategies. And, the MyHR is as good a place to start.

    I would add the following comments / suggestions:

    1: I suggest that architecturally we need to separate the people from the technology, most notably the clinicians and then the patients/carers, etc.

    2: I suggest we put the EHR in the background. Most of the current issues at their core are about human relationships, trust and information flows leading to appropriate action. EHRs play a critical and supportive role.

    3: Following on from above, we need to be very careful in our use of terms such as 'Access'. IT professionals have an understanding of what this term means BUT it is not the same meaning as a health professional. There is an implicit and at times very explicit Request-Disclose dialogue at the human level with the Duty of Care imposing its presence. We need only think about children receiving clinical help from psychiatrists.

    4: Requests and disclosures of personal health information for a variety of proposed purposes are better addressed, in the first instance, through the human sphere. This is the proper context within which to discuss the value of any centralized collections of personal health information as well as privacy, medico-legal, etc. issues. Equally, it is only possible at the human level to talk about concepts like "Authenticated Anonymous" communications for safety and quality reporting, analysis and response.

    5: Finally, I fully support the collaborative, inclusive, and transparent processes that have resulted in the FIHR. We need a means to engender the same collaborative effort at the human layer/sphere in order to properly connect it with the electronic layer/sphere.

    ReplyDelete
  7. IMHO, the first and most important architectural question is: Who should have access to a patient's medical treatment data?

    1. Health Professionals directly involved in a patient's care.

    2. Health Professionals directly involved in a patient's care and the patient.

    3. Health Professionals directly involved in a patient's care and the Federal Government.

    4. Health Professionals directly involved in a patient's care and the patient, and the Federal Government.

    There may be other combinations (e.g. research institutions), but I suggest that any that involve the Federal Government are totally unacceptable. They have no need and all they will do is distort the use of the system and the data in the system.

    ReplyDelete
  8. Perhaps we should focus on the architects behind the funding models, seems that is the biggest constraint/elephant in the room

    ReplyDelete
  9. Bernard,

    I have trouble with the generic term 'government' as a catch-all prohibition.
    If what you mean is 'personally identifying' health information, then we need to look to context and outcome(s) sought.

    I would prefer an architectural approach that is anchored in the ability to 'Ask questions' and the mechanisms and principles governing requesting and disclosing of personally sensitive information.

    Anonymous 1:29PM, your suggestion is a good one.
    We really do need to better understand the 'world view' perspectives of the key stakeholders. They are not aligned and the absence of alignment has serious consequences for e-health strategy.

    The 'elephant in the room' at least in part can be characterized by how we think about the role of markets and productivity in our health system.
    Whether we like it or not, consider these issues strategic or not, the reality is that the 'funders' think the are important. And, for government, the issue of financing health care is an increasingly urgent topic for discussion.

    Both government and the private sector have been immersed in this paradigm for a very long time. They are the air they breathe and the water they swim in.

    Commonwealth Health has tried quietly to challenge this line of thinking and acting in years past. But, to little avail.

    The reality that the dominant form in the economy is now SERVICES and the current economic reform narrative either exhausted or irrelevant is not good news--for government, at the very least. And, they don't know what to replace it with.
    The above comments are drawn from The FH Gruen Lecture at the ANU on 4, October, 2016 entitled: AFTER REFORM: THE ECONOMIC POLICY AGENDA IN THE 21ST CENTURY.

    So, while these more esoteric considerations seem far from out daily living, they have a direct and tangible impact on health care and importantly on e-Health.




    ReplyDelete
  10. John,

    Apologies, I should be more specific. I am suggesting that the Federal Government has no need for direct access to personal health or medical treatment data. They do not provide health care services. The best way to ensure (as far as is possible - there may always be some way) they do not access personal health or medical treatment data is to prohibit them from gathering and/or storing such data.

    Neither should State Governments have access to personal health or medical treatment data, even they provide services through hospitals; which is where the data should stay - close to health professionals.

    The Federal and State Governments fund and run the health care system. They do not need access to the health or medical treatment data of individuals in order to run the system. They need performance and analysed data, which can be generated by trusted research institutions.

    ReplyDelete
  11. Semantic interoperability deals with the actual “language” contained in the conversation between applications. Solving the syntactic interoperability issue by using a standard message format does not mean that the terms used by one application are the understood by the other.

    Semantics is only one of a number of layers of interoperability but one that seems to relegated to the to hard shelf although it is perhaps the one area of interoperability that addresses the unique aspects of the health domain. If a goal is to enable the integration of information from a range of trusted sources directly into clinical workflows then semantics surely must be a goal of the ADHA, they talk about Interoperability but in a very generalised flag way manner. I might be wrong and perhaps behind the many closed doors a team of computer scientists and health informaticians are beavering away. It does not go unnoticed the emerging vents that those we would expect to be leading the discussions around the complexity of health architecture are having to find.

    Power point is great for selling a dream, to realise that dream takes a whole different set of skill. With an incomplete complement of skills the talent that ADHA has would not be able to maximise their contributions, which is a real shame

    ReplyDelete
  12. To get Semantic interoperability we need high quality standards compliant messages first up to transport the data safely and in addition need agreed clinical models with terminology to structure the data in a way that can be agreed on. Pathology has gone some way down this path with agreed LOINC code sets and units, but pathology is mostly a collection of data points that are only loosely related to each other eg Electrolytes each stand alone. For clinical data, which includes histopathology, we need implementation independent clinical models and again pathology has moved down this path for cancer reporting, but radiology and clinical reports have barely left the starting blocks.

    Given the budget of the ADHA it would be useful if some small amount of resources could be devoted to building agreed clinical models. The pathologists already know they need this but other areas of medicine are 2 decades behind currently. Think echo reports, CT reports, endoscopy and capsule endoscopy reports. It would help decision support enormously if you could reliably read a cardiac ejection fraction from an echo report or know that a patient had Barretts Oesophagus and degree of dysplasia on biopsy with requiring a human to read the text.

    I think the PCEHR is a folly and they obviously disagree, but it would be sensible to have a bet each way and actually devote some resources to improving data quality for future use in decision support. The lack of this is concerning wrt deeper understanding of the issues.

    ReplyDelete
  13. Andrew,

    "For clinical data, .... we need implementation independent clinical models.

    Agree totally. Data only supports models; without models the data is useless.

    II have never seen anything from PCEHR/ADHA about any sort of model, whether it be models of health care processes, clinical decision support, diagnostic analysis.

    However, producing a good set of agreed (by the medical profession, not IT gurus) models is probably far more expensive and time consuming than the document oriented database model that is the MyHR.

    Or to put it another ways, the development of useful models will take far more than a "small amount of resources" and the MyHR it totally unsuited to support these models.

    ReplyDelete
  14. There are many tried and proven forms of securely delivering a message, health seems to want its own unique form. I agree the semantics is a far to important component to continue to push out of sight. This is about people being able to communicate effectively, and through technology have that information stored and retrieved to be reused in a future time.

    ReplyDelete
  15. Its not about the delivering a message, its about having that message work reliably. We need that to deliver pdf or text and we don't have it. Once we have it we need models to transfer better quality data and the format has to support that and HL7 V2 will allow that.

    The actual messaging part is mostly dependent on decent PKI and directories, areas the government has performed badly on. Current messaging requires a lot of attention to the quality of the content. Many labs have this under control, although still produce customized non compliant versions to "make it work" with known non compliant end points.

    ReplyDelete
  16. Is this what they mean when they say 'the BON FHIR of the faxes!'

    ReplyDelete
  17. There are no data, there are only documents.... (centrally stored or distributed) we need REAL atomic, semantically interoperable, transactional and analysable data (as we know traditional data, in cells and ENCODED, and standardised (and not free text and not in pdf or CDA) and therefore tractable to computational approaches (not just human readable gumpf), and if such data could be FORCED to be current and up to date and comprehensive, then great... but UNTIL we have that, then almost all this conversation is moot.... and the Govmint can consult with the community all they want about use and re use of data, but they don't have any to speak of - and with the current MyHR architecture, they don't seem likely to get any useful data either

    ReplyDelete
  18. "if such data could be FORCED to be current and up to date and comprehensive"

    And how, exactly, could that be done? Make everyone visit their doctor every week to update their MyHR? Some large percentage of people never see a GP from one year to the next. The govmint is living in cloud cuckoo land.

    ReplyDelete