Very interesting and thoughtful post on the reasons for the poor performance of Epic and Cerners of this world on usability and workflow. The insights for OpenMRS are I think clear. What is needed are the following:
-
Modular architecture -
Openness -
Agile development -
Web 2.0 technologies -
Effective interoperability
Sounds familiar :- )
Hamish
···
From: Jon Patrick [mailto:support@lists.amia.org] Sent: Monday, March 14, 2016 3:34 AM To: IMplementation AMIA Subject: [Implementation] - Immediate Adaptability - Part 2Hi Colleagues, some further thoughts on Immediate Adaptability.
Part 2 : Objections to Immediate Adaptability. The EMR systems built by the large vendors have turned their code development operations into the model of Enterprise Resource Planning (ERP) ventures following the lead of SAP, arguably the most successful ERP provider globally. So I will label the big vendors technology Clinical ERP or CERP. Smaller but older vendors no doubt have similar models for software management and development. Only the more recent vendors that have appeared in the last 10 years are likely to have different approaches.
The problems with IA for CERP are that it ostensibly requires the vendor to:
- Give control of the design of their CERP to the user community.
- Have a programmer on call to respond when the user requires it,
- The programmer has to have a good knowledge of the software, otherwise they will drop behind in dealing with the user requests.
- Have the mechanisms in-built into their software to automatically manage the version control of the code and be able to roll it back at any time.
- Have in-built version control of the data so that data collected before a given change is still available after the change.
- Continually change their interoperability functions to send and receive data from dynamically changing EMRs;
- Have confidence in their technology that it is robust enough to undergo continuous changes.
All of these criteria will increase the cost to maintain their technology, but also raise a protest from the vendors that maintaining large systems cannot be sustained intellectually by their staff as the systems are too complex to change rapidly to not create unexpected consequences. This protest would seem to be entirely valid. It is this very scale and complexity that inhibits them from trying to deliver Usability to the users beyond the minimum and subsequently an inability to deliver IA.
The Best-of-Breed system vendors have done a better job on Usability because they don’t suffer the same complexity problem and their aim is to deliver a smaller range of functionality, however they do suffer from the generalisation problem described below.
The technical difficulty created by the delivery of IA is in the process of creating a CERP system in the first place. The process is basically a sequence of tasks consisting of Requirements gathering, Systems analysis, Data modelling, Code writing, Systems testing, and Deployment. The CERP providers have escaped part of this process be removing the first two steps on the basis that they have built so many systems they know the generalisations of Requirements and Analysis. Indeed they have built large code repositories relying on these generalisations and are unwilling to change them because changes will effect so many of their customers, and the code base is so large that they are unwilling to risk the unexpected consequences of changes, of which we can be certain they would be some if not many.
The CERP approach followed the practices of the general IT industry of the 1980s and so cannot be condemned for that conventionalism. However those practices can now be seen for the poisoned chalice they have presented under a new set of requirements. The CERP method suits large volume data transactions with stable patterns of work and processing. That is good for the back office of any organisation including health organisations. They do not suit the needs of dynamic work places where work flow is as important as data capture, data volumes are relatively low and local data flow and analytics are crucial for efficiency, and where staff are seeking to run continuous process improvement. In fact the insertion of fixed immutable CERPs into patient-facing front-of-house clinical operations is a disaster for creating clinical efficiencies and for gaining productivity from the IT as our colleagues on the Implementation List frequently testify.
An operations objection to IA has raised its presence more than once on the AMIA Implementation List and that is that systems should be consistent from one to another as many staff move from one site to another and find it frustrating to have to learn how to use different systems. This is the issue of Trainability of a system. A system optimised for IA will be customised for its community of use and so someone working across multiple communities will need to train on different IA systems. Generally the training costs for CERP systems are high and so moving from one CERP system is very costly hence the complaints. This argument ignores a number of matters, namely: a. A CERP that fits the local workflow poorly will need significant work arounds which will still have to be learnt by these migratory workers; b. claims that the same technology from the same vendor has the same workflow and functions can often be spurious - there are cases where the two systems ostensibly the same cannot even communicate with each other. c. Locally designed systems are truly optimal for the local work flow and so training on them is about learning how the local community actually works, surely a necessary criteria for successful health care. d. Training on locally designed systems has little training costs for local users and modest costs for new users. e. Senior staff responsible for the training of junior staff use the system to train them in the processes of work. It is often the case that a CERP system is training staff in processes that are considered undesirable, whereas an IA system would enable the senior staff to create an ideal training system. cheers jon Professor Jon Patrick PhD | CEO APAC: Health Language Analytics Pty Ltd (HLA) Nth America: Health Language Analytics Global LLC (HLA-G) Suites 4 & 10, International Business Centre 2 Cornwallis Street, Australian Technology Park Eveleigh, Sydney NSW 2015, Australia ABN: 55 131 100 019 E: Jon.Patrick@healthla.com.aumailto:Jon.Patrick@healthla.com.au | W: www.hla-global.comhttp://www.healthll.com.au/ | Ph: +61 2 8091 2690
Site Links: View post onlinehttp://communities.amia.org/p/fo/st/post=68511&anc=p68511#p68511 View mailing list onlinehttp://communities.amia.org/p/fo/si/topic=200 Start new thread via emailmailto:implementation@lists.amia.org Unsubscribe from this mailing listmailto:implementation+unsubscribe@lists.amia.org?Subject=Unsubscribe Manage your subscriptionhttp://communities.amia.org/p/us/to/
Use of this email content is governed by the terms of service at: http://communities.amia.org/p/cm/ld/fid=2