Published by Computachem Services

P.O Box 297.
Alstonville. 2477
NSW Australia

Phone:
61 2 66285138

The following paper was not written by me, but by a person well versed in the medical software industry. The paper was written for colleagues in an attempt to highlight some of the problems the IT Industry had been experiencing in general, and health IT in particular.
It is reproduced with his permission.
The author was well intentioned at the time of writing (about March 2002) as you will find on reading the material, particularly the last paragraph.
He expected active and informed debate on the issues he raised.
Instead he was villified, called "obstructive" and given his marching orders.
Obviously, there were some vested interests involved.
However, taxpayers and pharmacists have to foot the bill if anything happens to go wrong in such projects as HealthConnect or MediConnect (Project details here).
What is immediately evident is how complicated the entire process is and how there is an attempt to achieve the "final solution" in one hit, rather than a modular progression.
Another writer for i2P, Mark Coleman, expressed similar reservation around August 2002.
This information is published in the interest of open comment, and in the hope that some of our pharmacy leaders will heed the advice so lucidly presented.
The material below being written by an "insider" is laced with acronyms and IT jargon.
The editor has attempted to simplify this, and it should be understood that as the material was written nearly twelve months ago, some changes would have occurred in the interim.

The Department of Health and Ageing has initiated the development of two potentially important Health Industry IT projects:

BMMS - The Better Medication Management System ( now known as MediConnect) is a system designed to allow electronic prescriptions to be securely transmitted and stored in a central repository and also enable pharmacists to download prescriptions via the Internet. The central tenet of this functionality is that patient prescription history will be stored in a secure central repository to allow professional providers (Medical Practitioners and Pharmacists) access to consolidated prescription/dispensed item details to assist with better patient outcomes and quality use of medicines.

HealthConnect - Is a system designed to deliver the nirvana of IT systems for the Health Industry i.e. an ELECTRONIC HEALTH RECORD. Ultimately this system will allow professional providers to view (via Event Summaries) consolidated patient history details. This is a massive undertaking and will take many years of R & D before any real results can be achieved.

Following please find an abbreviated list of issues that need to be canvassed and are not exhaustive.

IT Development Projects:

It is a not so well known or understood fact that 90% of IT development projects FAIL, either totally or in part. The reasons for either TOTAL or PARTIAL failure include:

* Change in market requirements.
* Insurmountable technical issues.
* Cost overrun.
* Completion time blow-out.
* Failure of the Systems Integration Design.
* Specifications not met.
* End user dissatisfaction with system, etc.
.
For details of the 16 different Critical Project Management issues go to: http://www.spmn.com/16CSP.html#risk

The size of a project does not guarantee success and there are many examples of huge projects totally failing eg. Westpac Bank about 12 years ago spent $250 million (over 3 years) in an attempt to rewrite their banking system. This project was a TOTAL failure.

Following is an example of a recent partial failure due to a massive cost blow-out:

NAB management software system costs blow-out: Report March 22 2002

National Australia Bank Ltd has been hit by another cost blow-out on a new management software system that is now expected to top $800 million, double the
original estimates, The Australian Financial Review reports.

A further $200 million in extra costs has been linked to execution difficulties and consultancy agreements and follows trouble earlier this year when the estimated cost
climbed $200 million, the newspaper reported.

The system is meant to provide full integration of NAB's global technology operations.

On Tuesday, the newspaper said a newly created review team presented the $800 million estimate to the bank's board, which is believed to have given management approval to press ahead with implementation despite internal concerns that costs might escalate further.
On Wednesday, a bank spokesman declined to respond to questions about Tuesday's meeting, it said.

This story was found at: http://www.smh.com.au/articles/2002/03/22/1016758525858.html

In November 2002 another TOTAL failure was announced as follows:

Sydney Water is expected to take legal action to recover some of the costs associated with its $70.2 million customer information and billing system - but just who will carry the can for the aborted project remains unclear. Earlier this month, Sydney Water announced it had terminated the CIBS contract held by PricewaterhouseCoopers.
Full story at following link: http://afr.com/it/2002/11/12/FFX32RF8D8D.html

Risk Analysis:

There should be awareness, that on any independent risk analysis of the HealthConnect and BMMS (MediConnect) projects, there is huge potential for catastrophic failure. I am not aware of any normal Project Management Systems (which includes risk analysis techniques) being utilised in the planning process of these very expensive projects. The importance of the cost of these projects (est. $150 mill. over 5 years) versus the cost benefits also need to be scrutinised.

The major risk factor here is that it is an opt-in system by the professional providers and the patients. Because of this, the effectiveness (the ability to have recorded a meaningful i.e. complete patient record) is very small indeed. It depends on the patient who has opted in presenting to GP, pharmacist, and hospital providers who have all opted in.

At this point in time there are no incentives to ensure a significant number of patients and professional providers opt-in. For this issue to be evaluated, a survey of patients and professional providers should be completed to gauge the intentions of the protagonists. Without this information the projects will only discover the "take up" after the fact.

My gut feel is that one could expect that around 15% of patients, GPs' and Pharmacists might opt in. If this is the case then it does not augur well for success. If 15% of patients present to GPs' and Pharmacists, of whom only 15% have opted in, then < 1% of the population will have a meaningful (i.e. complete) health record accessible.
How could this justify the expenditure of $150 million?
Even if 70% of patients and professional providers opt-in, the end result will be that only 35% of health records will be complete, unless patients are streamed to participating prof. providers.

In order to obtain support from the professional providers, any systems design must be such that there is minimum interaction necessary by the providers. Any system interaction that would impact on the providers' ability to process their heavy workload will be a huge disincentive to opt in.

Dependencies of the projects include:

ELECTRONIC HEALTH RECORD

Currently there is no internationally recognised Electronic Health Record standard available. The International GEHR (Good Electronic Health Record) project (the only non-proprietary "Open" system) has yet to agree on a standard.
For information regarding the complexity of the subject, go to: http://www.gehr.org/

UNIQUE PATIENT IDENTIFIER

The BMMS (MediConnect) project is committed to using the Medicare Number as the UPI (Unique Patient Identifier) and as BMMS (MediConnect) is really a sub set of the HealthConnect project it is important that they share a common UPI. This apparently is not the case, with HealthConnect seemingly committed to using a NSW developed UPI a component of which will be the Medicare Number. There is a requirement for these (BMMS (MediConnect) & HealthConnect) projects to harmonise (co-ordinate) the functionality of the applications they intend to deliver. Ultimately the two projects should be merged.

COMMUNICATIONS INFRASTRUCTURE

The Department of Health and Ageing (DoHA) and Health Insurance Commission (HIC)have abdicated any responsibility for provision of a standard communications platform, instead suggesting that all the Professional providers (GPs'/Pharmacists etc.) arrange to have their personal computers connected to the internet via an Internet Service Provider (ISP) of their choice. This is a recipe for disaster.
The on-line GP applications (ANS /BMMS (MediConnect) etc.) depend on synchronous communications, requiring response times of less than 5 seconds. With no Service Level Agreement (SLA) being available from most ISPs' in Australia and no centralised network administration/support and with low bandwidth delivery of modems, any communications consultant will advise that the system will not function efficiently.

UNIFIED PRODUCT CODE

Both systems (especially the BMMS-MediConnect) require a health industry UPC (unified product code) standard.
The MCCA project is the driver of this standard (EAN International standard) and unfortunately, due to the intransigence of the product manufacturers and Therapeutic Goods Administration (TGA) unwillingness to co-operate, it is not possible to estimate when this will become a reality. i.e. the electronic prescription will not be able to be transmitted with confidence of the integrity of the prescribed drug without there being a standard product code (The BMMS/MediConnect field tests may have to be implemented using the existing Pharmaceutical Benefits Scheme (PBS) codes, which is only a short term solution).

To further complicate matters it now appears that some product manufacturers are backing the introduction of the opposition HIBCC product coding system into Australia.

MEDICARE CARD SYSTEM

The Medicare card system, which provides the Patient identifier for the BMMS/MediConnect is a failed system. At one stage it was established that 23 million cards had been issued for an Australian population of approx. 19 million. The Medicare card system needs to be redesigned. The Health Insurance Commission (HIC) however are reluctant to entertain this for various reasons (cost, necessary legislative changes, spectre of the "Australia Card", resistance to change etc.) The Medicare database is demonstrably inaccurate and the HIC have elicited the assistance of pharmacists in an endeavour to clean it up by having the pharmacists record the Medicare number for all PBS dispensed items and check the patients' card against the HIC Database, utilising the Claims Transmission System to identify mismatches. This of course only partially addresses the problems of the system.

DRUG INTERACTION/ALLERGY CHECKING

Part of the benefit of the BMMS/MediConnect system will be to have a central database of all medications prescribed/dispensed to patients, which would enable drug interactions/allergy checking. The problem is that BMMS/MediConnect does not take the opportunity to leverage off this information. The system specs propose that Drug Interaction/Allergy checking remains with the individual Clinical Management/Dispensing Systems, without standards being imposed.

Will the results of this check form part of the BMMS (MediConnect)/HealthConnect record?
If so this will result in potentially very large files which will be difficult to interpret because there is no standard Drug Interaction database system. Each application system has its' own method of Drug Interaction reporting and Drug Interaction database. One might use the method of mild/moderate/severe reactions vs another using the 1-5 system. One system may report on all reactions or only moderate and or severe. Using a sample Patient medication profile it has been discovered that there is little correlation between the reports generated by the disparate applications.

The result is it would be impossible to have meaningful aggregation of this information. There is a need for Govt. (via the National Prescribing Service (NPS)?) to develop a standard for Drug Interaction/Allergy reporting together with a common Drug Interaction/Allergy database. The BMMS (MediConnect) /HealthConnect projects need to address this issue.

Because drugs can be combination products, an allergy checking system would need to be able to distinguish the components of the product e.g. Septrin (Trimethoprim & Sulphamethoxazole) with either of the components having potential for an allergic reaction.

This is another reason for the importance of the MCCA project. The EAN record has 43 fields, one of which is populated with the active ingredients of the proprietary product. The EAN record could assist in providing a more efficient way of building an allergy checking system.
The onus for Drug Interaction/Allergy checking usually defaults to the pharmacist who then must report any issues to the prescribing doctor, which is bad systems (procedural) design. With a centralised checking system, the doctor will be alerted at the time of prescribing, thus being able to immediately adjust the course of treatment.

MSIA

The Medical and Pharmaceutical software providers (represented by the Medical Software Industry Association) has determined that any software development that is specified by government and is for the sole purpose of assisting government projects without enhancing functionality to the professional providers, should be funded by government.
A formal Agreement for funding to be provided to the MSIA members has yet to be finalised.
Time-lines will continue to blow out as none of the software providers have written one line of code.
Worse still, because the software providers have limited resources with an ongoing commitment for development for their clientele, any additional development work will have to be scheduled accordingly.

HL7

There are still issues regarding HL7, eg. the BMMS/MediConnect non-compliance with the E-Prescription HL7 standard. Is there really a need for HL7?
Is there a more efficient less complex method of file formatting?
Why must BMMS/MediConnect use HL7 when the MedClaim system uses UNEDIFACT.
The situation in Australia is fairly unique because there is effectively only one HMO (HIC).
Electronic transmission of data is therefore from one to many or vice versa.
Use of an XML standard should be sufficient for the BMMS/MediConnect project and would be less complex to implement.

PKI

As yet there is no example of any large scale implementation of PKI (Public Key Infrastructure) similar to the BMMS (MediConnect)/HealthConnect projects anywhere in the world. Obtaining a CA (Certification Authority) is currently a lengthy procedure that could be a disincentive for Professional Providers to opt in.

PROVIDER DIRECTORIES, this important administration facility required to support PKI still has many issues yet to be resolved.

There is widespread support in the IT community for the notion that the use of the PKI standard is an "overkill" solution.

For a US Govt (General Accounting Office). report regarding problems relating to PKI go to: http://www.gao.gov/new.items/d01277.pdf). and for problems discovered by a commercial user: http://www.computerworld.com.au/IDG2.NSF/a/00081A0A?OpenDocument&n=e&c=Sc

The mandatory use of PKI /HL7 and perhaps XML (HL7 Ver 3) (for info on performance problems faced by XML: http://www.zdnet.com.au/itmanager/technology/story/0,2000029587,20264223,00.htm) comes with significant processing overheads requiring a large % of professional sites to upgrade their PCs. The use of the designated personal security token (for GPs') can only be used on later model PCs that have a USB (Universal Serial Bus) installed.

WHO PAYS FOR SYSTEM UPGRADES, WHO INSTALLS THE UPGRADED SYTEMS AND TO WHAT STANDARD?

OTHER ISSUES

Privacy and other legal/procedural aspects involving the projects, have yet to be fully addressed or tested.

FIELD TRIALS

Field trials for BMMS/MediConnect are scheduled to begin in the first quarter 2003. Huge resources from paid government consultants are working in consultation with voluntary (including unpaid expenses) industry representatives/software providers, who have been co-opted to help on a large number of committees.
From personal observation, much advice given by these industry committee workers has had a variable reception (i.e. advice is not listened to) by the government project development groups.

In particular it should be noted that the IT software developers were not consulted before the Systems Integration Designs were developed.
They should have been consulted to examine if there were options for more efficient ways of delivering the functional requirements of the projects.
As it stands they have been invited (sometimes reluctantly, in the case of the DG-BMMS/MediConnect) to join committees, to rubber stamp directions.

SUMMARY

In summary I believe that the cart has been put before the horse.
The projects need to be postponed until such time as all the dependant issues required for the projects to operate successfully are addressed.
Certainly some of the funding should be redirected to the critical dependency areas, some of which suffer from inadequate funding/resources.

ALTERNATIVE SYSTEMS INTEGRATION DESIGN

There are alternative systems integration designs for BMMS/MediConnect that could:

* Achieve greater procedural efficiency, which in turn would ensure a larger number of Professional Providers opt-in.
* Assist with overcoming some of the dependency issues.
* Achieve a faster development time-line.
* Reduce the cost of delivery of the systems.

It is not the purpose of this document to explore these options rather than to alert people to the fact that there are other viable options.
Information to support this issue is available on request."

Editor's Note: The issues raised above are extremely important and any person who would like to comment either in support or from an alternative perspective, I would be happy to hear from you.