The following carefully researched and desperately sad article (for Australian E-Health) appeared today.
Poor prognosis for medical software sector
- Karen Dearne
- From: The Australian
- January 18, 2011
THE medical software sector hit the wall last year, with large and small players that had geared for expansion hit by a triple whammy.
Long-anticipated e-health projects did not materialise, the global financial crisis had people scrimping every last penny, and currency exchange losses added insult to injury (see table).
Medical Software Industry Association president Geoffrey Sayer said it had been a tough period for the sector.
"The outlook for e-health in 2011 is challenging for everyone, to say the least," he said. If we are to be successful, we will need to establish a transparent leadership partnership between all stakeholders that delivers tangible and measurable benefits."
Australia's largest health IT company, iSoft, crashed hard, but it was by no means the only local firm to bleed red ink in a year that also brought a retreat from the sector.
ICSGlobal exited in April, selling its core Thelma medical billing and claiming transaction hub to CargoWise subsidiary eHealthWise for a total consideration of up to $1.45 million.
The e-commerce pioneer, which listed on the Australian Stock Exchange in 1999, was still licking its wounds from a lengthy anti-competitive action against Medicare.
It alleged the government agency had misused taxpayer funds to replicate its computer program, and offer it free to the private health sector.
Medicare settled the claim for $460,000 in October 2009, a month before the matter was due back in the Federal Court.
ICSGlobal also sold its US business, Medical Recovery Services, in April after a disastrous bid to take the clearinghouse model into the large private market there.
After management redundancies, including former chief executive Tim Murray, and closure of local offices, ICSGlobal now operates only in Britain, where its Medical Billing & Collection unit is a $200,000-a-year business.
Most of the local medical software companies are too small to report their annual results to the Australian Securities & Investment Commission or are exempt foreign-owned companies, but a flood of special-purpose financial reports over the past few years reveal a sector under stress.
Lots more sad stories and a must see table here:
Really I believe it is really simple to understand what has caused all these issues for e-Health providers.
The key issue is a lack of regulatory, political and commercial certainty that would allow for proper business planning and for taking on reasonable risks to grow and provide quality solutions for those that need them.
Rather than a supportive, innovation friendly environment we have seen Government agencies make sudden unexpected policy decisions (e.g. the effective cancellation of HealthConnect in 2006/7), announcement of strategies that are then not actually funded (e.g. the Deloittes 2008 National E-Health Strategy) and Government deciding to compete with established businesses on a very unfair playing field (e.g. Medicare and Thelma).
We have also seen chopping and changing in incentive rules and requirements and the list goes on.
Until there is consistent leadership, policy and clarity of direction to provide business certainty our providers are going to continue to struggle.
Yesterday’s blog actually explores some of these issues in a little more detail.
See here:
http://aushealthit.blogspot.com/2011/01/post-of-january-11-2011-has-really.html
What is needed is for Government to set the rules of the game and the objectives it wants to meet. Once it has done that all that is needed is a steady strategic hand on the tiller, appropriate leadership and relevant funding where the is market failure. The private providers can then be left to do what they do best - develop and innovate for their clients!
Sadly for Government to properly undertake its role it requires a level of understanding and skill in the e-Health domain I am not sure is there. One can only hope!
David.
Hi David,
ReplyDeleteWhile what you say is mostly on the mark, you can't blame government and associated macro forces for all the troubles of the industry - the companies themselves and themselves alone are in charge of their business plans and strategies...if they want to roll the dice and hitch themselves to a solely/mostly government funded model of operation, they have to expect a road filled with many twists and turns.
I note the folks in the industry that are not beholden to tax payer funded revenue streams, live and die by the strength of their offerings and stay clear of the paperwork and conditions associated with the occasional government treats are all missing from Karen's list of troubled companies...some of these are doing quite well in fact.
Karen's list is not all inclusive, that would be almost impossible to do. It is however highly representative of the state of the health IT industry.
ReplyDeleteThe great tragedy for the industry and for Australia is that no-one in Government (politicians and bureaucrats) is prepared to consider alternative options to developing the ehealth marketplace. Yesterday's blog including in particular the extraordinary range of comments demonstrates that quite clearly.
So much so that everyone with a genuine interest in this subject including politicians, bureaucrats, health informaticians, industry associations, professional bodies, consumer representatives, health departments, NEHTA, vendors and others should all be very concerned about the status quo of ehealth in Australia.
However, being concerned is one thing, doing something about it is something else altogether.
Carping, criticism and exposes of what is wrong, whilst an important part of the equation, do not engender a great deal of confidence or willingness for anyone to want to find a way to rectify the current situation.
The issue is that government wants eHealth, but they seem to work against companies that do sensible things to try and enable it, especially when industry knows we need standards and the government just keeps ignoring standards and coming up with half brained schemes that benefit the big end of town and deliver nothing.
ReplyDeleteIf we have governance that worked then companies that tried to support standards would be rewarded. This is far from the case currently as it seems that they want to do it with "Commercial in Confidence" deals with secret "plans" rather than transparent rewards for supporting open standards.
It harps back to the Ronald Reagon days when he said: The ten most dangerous words in the English language are "Hi, I'm from the government, and I'm here to help.".
With help like this we are going backwards fast. In reality they need to spend much less and reward open standards and get out of the way! They should stop trying to "DO" anything as they just distort the market in perverse ways.
Looking at Wiki Quotes there are a few other Reagon quotes that are relevant here:
"Government is like a baby. An alimentary canal with a big appetite at one end and no responsibility at the other."
"government is not the solution to our problem; government is the problem"
There is no doubt government wants eHealth and they have certainly channeled a lot of money in that direction.
ReplyDeleteTo suggest that Government seems to work against companies that do sensible things to try to enable standards suggests that you see this as the root cause of the problem. You go so far as to say that government just keeps ignoring standards and instead comes up with half brained schemes that benefit the big end of town and deliver nothing.
I would suggest to you that government doesn’t intentionally ignore standards it just doesn’t appreciate the depth and complexity of the issues. Also, standards and governance are very difficult issues to bring to the table and see though all the way to completion for there are many potholes along the way and numerous detours and political will wanes the longer the issue continues.
The big end of town has a voice and so too do you and all your colleagues. Rational reasoning and arguments is one thing but bear in mind they are also wrapped up with vested interests and compelling sales and marketing campaigns. If you rely on intellect, reasoning and logic to get your message heard you will fail.
To suggest that “if we have governance that worked then companies that tried to support standards would be rewarded” is a shallow view of the real world. Governance and standards alone will not fix the problem.
Ronald Reagan did say those words which can be just as easily parodied into another ten highly dangerous words “"Hi, I'm from the computer industry, and I'm here to help.". Let’s be honest, the computer industry is not immune from being the originator of some very very big problems.
.
Finally let me say that your suggestion that the government should “stop trying to "DO" anything as they just distort the market in perverse ways” is the worst possible outcome. With that attitude you will continue “going backwards fast”.
You need to take a deep breath and think more carefully about the problem and you need to enrol your colleagues to do the same.
You also need to appreciate Government is needed if we are to make progress. Government is an essential partner in the equation. Government is a very important source of much needed funds to support progress in ehealth. You should never forget that.
How it’s done will determine the outcome and that is the nub of the problem.
Ian Colclough said that Government is needed as an essential partner in the equation for he sees it as a very important source of funds to support progress in ehealth.
ReplyDeleteMany of us would disagree with him because our experience has been that more often than not government is so hog-bound in 'process and policy procedures' that while the underlying intent may be good the projects become subsumed by a wall of obstacles which, as small software vendors, we are unable to shift because we do not have the political leverage to make ourselves heard.
Even so I agree with him absolutely when he says "How it’s done is the nub of the problem".
Of course the government should do something, they should stop funding anything that resembles HealthConnect or NEHTA and legislate for standards compliance. These standards should be the ones created via the usual processes and not the ones rammed through the standards process in inappropriate ways.
ReplyDeleteIf standards were enforced then the level of interest in fixing and creating them would rise and industry would become involved again. Currently they are sitting on their hands not knowing what crazy plan will be enacted next.
Some incentives to allow providers to pay for the more expensive standards compliant software would not go astray, but not via the PIP system! The previously posted plan would be about right for this.
Government writing software and creating standards just does not work, we have ample proof of that to date!!
The need to govern, and not do.
Thursday, January 20, 2011 2:46:00 PM makes it all sound so terribly simple - legislate for standards compliance and everything will be ok.
ReplyDeleteGet real.
Which standards?
Oh, and please be very precise - no ambiguity.
Sounds like a nightmare waiting to happen. Before one can legislate for compliance to a standard one has to identify the standard to which compliance is required.
ReplyDeleteHow many standards are there in health IT? Who decides which of the many standards currently being used will apply and which should be discarded? How will compliance be enforced? Who will make vendors change their technology to embrace each standard?
I would agree that compliance is the key.
ReplyDeleteIf we had good support for AS4700.2/AS4700.3 and AS4700.6 for both production and consumption we would be over the hump well and truly.
We would then be at the point of adding meaningful semantics with a solid base. No matter what happens we need solid support for V2 to get better, as Lab data is unlikely to move from that in the next decade.
It would solve the majority of the interoperability problems in existence and pave the way for adding a rich layer of semantics. The number one issue at the moment is poor compliance with standards, not the standards.
That is real.
Andrew McIntyre's comments tie in with Tom Bowden's remark on the previous thread...
ReplyDelete"Recently I heard Dr Pesce quoted as saying the most important way to push the e-Health agenda forward is to fix pathology messaging."
Obviously we have dived down from strategy to implementation tactics here, but that is probably the only way forward. Adopting a standard messaging format (HL7 v2.4?) and, even more crucially, a common clinical coding system (SNOMED CT) are the necessary first steps towards E-Health interoperability. Aggregated Patient records - such as PCEHR - are the final step.
"Adopting a standard messaging format (HL7 v2.4?) and, even more crucially, a common clinical coding system (SNOMED CT) are the necessary first steps towards E-Health interoperability. Aggregated Patient records - such as PCEHR - are the final step."
ReplyDeleteAbsolutely!
David.
Anonymous says:
ReplyDelete"How many standards are there in health IT? Who decides which of the many standards currently being used will apply and which should be discarded? How will compliance be enforced? Who will make vendors change their technology to embrace each standard?"
This incorrect in Australia, we only have HL7 V2 content standards and each of the AS4700 standards are a constraint on one section of the master HL7 V2 standard. There are V2.3.1 and V2.4 versions but the differences are minor and backward-forward compatable in general.
Australia has, on several occasions made the decision to go with HL7V2 but because there has been no compulsion for compliance, there is none. We do not get requests to message any other standards based data, other than HL7 V2 (and PIT which can be carried in HL7V2 as can CDA for that matter).
The interoperability problems are related to poor compliance with the standards which have been specified. We cannot possibly look at using SNOMED-CT in any meaningful way until the basic compliance improves, so the first step is the get reliable quality of HL7V2 production and importantly comsumption.
We have AHML as a message testing facility, but it is little used as there is no compulsion to use it. As it stands it is not enough to solve all the problems, but AHML compliance would be a huge step forward and its functionality could be enhanced if they had demand! Only legislation will create that demand it seems and I think this is what is needed.
In a guest blog in Feb 2007, Ann Webb, the deputy CEO of the Australian Association of Pathology Practices wrote "The AAPP endorses ‘AS4700.2-2004 Implementation of Health Level Seven (HL7) Version 2.3.1 Part 2: Pathology orders and results’. Furthermore member practices currently provide significant volumes of electronic messaging to GPs, Specialists, and hospitals using these standard messages. The Pathology Practices are not the source of delay in widespread standardisation and would be pleased to move their customers to this mode of messaging now. The report receiving systems however have to be capable of managing these messages properly. That PIT is provided at all by AAPP member practices is because that is what their customers have asked for."
ReplyDeleteSeems like not much has changed in four years!
How about this from the Dept of Health website, dated January 2008. These are requirements for accreditation of pathology services:
ReplyDeleteRequirements for Information Communication (2007 Edition)
6 - Compliance with electronic messaging standards
Guidelines
G6.1
Electronic communication of requests and reports should comply with protocols set out in the Standards Australia publications AS4700.2–2004 and HB262–2002 and their subsequent revisions.
G6.2
Where an electronic request is not accompanied by a paper request form, processing of the electronic request should comply with current Medicare Australia regulations for processing such requests, in order to be eligible for reimbursement under the Medicare Benefits Schedule.
Commentary
C6.2
Laboratories should have their electronic messages certified for compliance against AS4700.2–2004 by an accredited message compliance organisation such as the Australian Healthcare Messaging Laboratory (AHML), which has recently been accredited by the National Association of Testing Authorities (NATA).
Well, the intention was there. I note these are guidelines, not absolute requirements, and it seems like not much has been done to encourage much less enforce compliance.
Keith Heale has demonstrated unequivocally that compliance will not make one jot of difference.
ReplyDeleteHow it’s done is what will determine the outcome. That is the nub of the problem.
The nub of the problem is surely that they can't produce compliant messages because the systems that receive them can't process them!!!
ReplyDeleteWe need to get serious about standards support and the only way to make that happen is to legislate for it. Every other part of healthcare has to adhere to standards, but for some reason not the messages that carry critical data!!!
Saturday, January 22, 2011 4:01:00 PM makes 3 points:
ReplyDelete1. they can't produce compliant messages - Agreed
2. the receiving systems can't therefore process them - Agreed
3. the only way to make standards support happen is to legislate for it. - Not agreed.
3. Will not fix the problem. Legislation will make bureaucrats and politicians comfortable. It will not change vendor behaviour. It will give some vendors a false sense that once legislation has been passed the problem will be fixed.
Let me repeat - the nub of the problem is not legislation it is how you enforce standards. You can legislate till the cows come home but that will not make vendors and their software compliant with each other.
The answer lies in How it’s done is what will determine the outcome. That is the nub of the problem.
Many can produce compliant messages, but don't use them as receiving systems can't handle them. Universal consumption of compliant messages would allow the production to happen.
ReplyDeletePerhaps you can suggest how it should be done. A requirement, in legislation to have the testing done would seem to be a sensible path as voluntary compliance does not work. That has been proven.
Saturday, January 22, 2011 8:56:00 PM has refined the problem a little more by stating that a legislative requirement must be "to have the testing done".
ReplyDeleteThis must be tightly linked to some form of financial reward. In that regard an earlier discussion revolved around the word "incentives".
Incentive payments need to be very very carefully designed if they are to effect the desired change in 'behaviour' across a broad population of competitive software vendors.
The earlier discussion on incentives was a crude start in that regard.
Someone suggested that "providers or users should be able to access a software subsidy to purchase software that complies with the standards" and that PIP is not a suitable incentive tool in that regard.
I agree. PIP is an inappropriate tool to use in this context. It does not generate appropriate motivational forces among providers/users. As a motivational change management tool it is far too crude to be of much benefit in achieving desired outcomes.
Unfortunately, in my view, the same applies to the simple concept of a software subsidy. Both tend to create an unhealthy and inappropriately competitive environment between vendors.
That being the case somehow some other 'incentive' model needs to be designed to overcome these shortcomings.
As a point of information, at least 2 of the Health Message Service Providers - namely Argus and Healthlink - validate the format and content of HL7 v2 messages before they are sent and reject those that are incorrectly-formatted or where mandatory fields are not populated.
ReplyDeleteHi,
ReplyDeleteI strongly believe that all labs should be compelled by legislation to send conformant HL7 v2 lab messages and all hospitals should be compelled to send conformant/compliant discharge messages, once again AHML or other suitably qualified organisation approved.
Anyone who knows me will be clear about the fact that I am a true blue free enterpriser, however I do think government has a role and firmly mandating adherence to widely agreed standards is a key part of that role.
The wording of the 'Requirements for Information Communication' referred to above should immediately be changed from 'should have their messages certified' to 'must have their messages certified'.
I have already lobbied DOHA on this, visiting Canberra to do so and will now approach Dr Pesce to ask for it. Sounds as though there will be some strong support for this. Good thread.
Legislating for sending conformant HL7 v2 lab messages and conformant discharge messages is insufficient for system interoperability for at least the following reasons:-
ReplyDelete1. As Anonymous of Saturday, January 22, 2011 4:01:00 PM states, legislation "will not make vendors and their software compliant with each other"; it requires testing.
2. The current "standards" being promoted in Australia, are insufficient to reduce ambiguity sufficiently for receiving systems to reliably and consistently parse messages from different sources. I defy anyone to state the definitive way to send "blood pressure" in an HL7 v2 message based on current Australian standards. The fact that a sender might send data conformant to Australian standards, and passes AHML testing, does not mean that "blood pressure" information can be exchanged.
3. Not only do sending systems need to send data in a consistent and deterministic format, the receiving systems have to parse and interpret the data accordingly. Currently, the way this is done appears to vary considerably, particularly around coded data. This is at least partly due to the ambiguity inherent in the standards and partly due to the historical implementation approaches required to get things working sufficiently on a party to party basis. I am not aware of any published analysis of the capabilities of current systems to digest HL7 v2 messages, nor of any vendor's approach to dealing with the myriad terminologies used.
Hi Eric,
ReplyDeleteI agree that AHML testing will not result in semantic interoperability, but we need structural and administrative compliance to allow for reliable exchange of compliant data as a first step.
Medical Objects has had AHML compliance for 5 years but most systems cannot correctly display the administrative aspects of compliant messages and many cannot handle the escaping of reserved characters etc etc
In my view it would be a mistake to start with semantics, but first aim for reliable messaging of compliant content. Once that is in place adding the semantics becomes much easier. We need solid foundations for semantics and reliable parsing and display have to be in place first. Walk before running is a good policy. However rich semantics are possible in V2!
Thanks Eric, but I do think mandating AHML compliance is a good first step. AHML does do testing, indeed, that is what it exists to do.
ReplyDeleteWhile you are no doubt right that there is a lot more to be done to achieve full semantic interoperability, AHML accreditation would be a much better starting point from which to embark upon that journey than the current place we have been stuck in for the past ten years. Kind regards,
So in summary the problem is that there are differing views at a critical level.
ReplyDeleteSo the nub of the problem therefore, forgive me for harping back to it, lies in "How it’s done". Not what needs to be done [there seem to be some semblance of agreement albeit with differing views and philosophies of approach] it is the HOW it's done that is so elusive.
I don't think the issue is that complex. We have had suggested standards but a total lack of any will to actually enforce them. Perhaps this is because there is a total lack of understanding of IT by the powers that be. I suspect they don't have the level of understanding to actually enforce anything as they worry about looking stupid. Instead they let NEHTA's attempts at solving the problem look stupid.
ReplyDeleteWe need someone at a policy level to understand that enforcement of existing standards is what is required and not "New Standards" invented by people who don't yet understand the problem. The moves to do business analysis of pathology to work out what is required is a joke. The existing standards already know what is required and the smarts are in the standards, but no one has bothered to understand them!!!
"We need someone at a policy level to understand that enforcement of existing standards is what is required and not "New Standards" invented by people who don't yet understand the problem." said Monday, January 24, 2011 12:15:00 PM.
ReplyDeleteVery succinctly put. That too lies at the nub of the problem.
Enforcing existing standards is required but legislation for compliance won't fix the problem as it is insufficient to enforce the standards and bring about change. So how do you make change happen?
ReplyDeleteMarket forces are what is needed to 'fix the problem'. However to assist that along, one of government's few roles and responsibilities is to set and uphold key rules: The wording of the "Pathology Communications Requirements Document" referred to above has to change forthwith from 'Laboratories should have their electronic messages certified for compliance against AS4700.2–2004 by an accredited message compliance organisation such as the Australian Healthcare Messaging Laboratory (AHML)' to "Laboratories must have their messages certified ...." And a fixed deadline imposed.
ReplyDeleteI think things would then improve overnight.
Anonymous said...
ReplyDelete"We need someone at a policy level to understand that enforcement of existing standards is what is required and not "New Standards" invented by people who don't yet understand the problem." said Monday, January 24, 2011 2:31:00 PM
I just think you are all looking at this from the wrong direction. Enforcement will never work because it is too static and much too expensive and invariably involves testing of a lot of activity that is not required - which also makes it cumbersome.
At the end of the day e-health will just provide another tool in the management if individual patients! Just like a lot of technological advances in health have allready done for the last 50 years. It will be the providers that decide what is useful (or not). So most of the cumbersome EHR archetypes will not be able to be implemented. Even SNOWMED is of little use compared to the richness of clinical language that has been developed over 200 years of medical care.
Incentives (or bribes) may mean systems are bought but that does not mean that they will actually be used - especially when incentives cease.
There seems to be a complete lack of understanding of change management in most of this - along with a lack of understanding of how the health system actually works. Change will come - but it will not be driven by government or legislation.
Tuesday, January 25, 2011 7:42:00 AM said "There seems to be a complete lack of understanding of change management in most of this - along with a lack of understanding of how the health system actually works. Change will come - but it will not be driven by government or legislation.".
ReplyDeleteAbsolutely correct. That too lies at the nub of the problem.
I am afraid I do not get this change management viewpoint. Our day surgery has painful accreditation because the legislation says it has to, to get paid and operate. We certainly would not do it for the fun of it.
ReplyDeleteI am sure drug companies only comply with testing because they are required to do so. A clear statement that (for safety reasons) all patient data communicated must meet quality standards (eg AHML certification) would change the landscape greatly in my view. Why do people think this is not the case?
"A clear statement that (for safety reasons) all patient data communicated must meet quality standards (eg AHML certification) would change the landscape greatly in my view."
ReplyDeleteI would like to see the evidence that supports 'for safety reasons'!
There is a world of difference in meeting certain standards in regard to the operation of a facility versus trying to get individual providers to communicate about patients in a certain way. Considering that most medical specialists currently still write (albeit usually word process) and snail mail letters to their referring GPs there would be a major revolt if there were attempts to 'force' them to use probably cumbersome and unproven (in relation to improved safety or efficiency) electronic tools based on a legislated set of arbitary standards! Good luck for that that approach!
They can use paper if they want, but if they send it electronically it should be compliant for safety reasons!!! Non compliant data is unsafe.
ReplyDeleteI am not suggesting that we should force specialists to send electronically, but I am suggesting that all data that is sent electronically between providers should be sent using valid, compliant HL7 messages.
ReplyDeleteHow can non-compliant messages be safe? Surely the only safe way to conduct eHealth is for the data to be represented in structures that comply with the standards?
This also involves receivers being able to deal with compliant messages, which is a problem currently. The labs are in many cases sending non-compliant data because of the limitations of the receivers and a requirement for compliant data would force receivers, as well as senders, to improve.
Currently we are in the same situation as the airlines who were getting bogus spare parts of dubious quality. That caused several crashes and resulted in tightening of the regulation in the airline spare parts industry. The eHealth situation is in the same position, but it seems some people still don't get that standards compliance is the critical safety factor. That concerns me!
Andrew's company (Medical Objects) and mine (HealthLink) are responsible for the majority of clinical messaging in Australia, please accept our assurance that this is a critically important issue to address if you really want to sort out e-Health. I am sure there are lots of other things to consider , but enforcing message accreditation to ensure that outgoing messages conform to standards is an essential first step.
ReplyDeleteAs fierce competitors Andrew and I probably do not agree on many things, but this is certainly one we do agree on and have done for some time.
Referring to an analogy above, I am sure that Boeing and Airbus would be in a similar position re agreeing on use of standards in their industry.
Enforcing AHML message accreditation is only one step as AHML only checks a message's structure. Reading Healthlink's Kyle Macdonald's excellent feature in the November 2009 issue of PULSE+IT magazine, it seems that at least one messaging service provider extends this by ensuring that the contents of the message are correctly displayed in vendor systems.
ReplyDeleteThis really has to be the shortest step to compliance heaven, as there are far fewer messaging services than creators & receivers and these service providers have the ability to check every message and reject those that do not comply. Awarding Compliance Certificates on an organisation basis will not prevent the creation of rogue messages, because it is virtually impossible for an accreditation process to cover every use case.
Actually that is really Step 2. Step 1 is to do whatever it takes to outlaw PIT messages.
There is only one way to fix the problem and that is to ensure that every piece of data that travels between providers is compliant. There is no short cut. Rejected messages may have carried critical data and this is not a solution, but a band aid.
ReplyDeleteIts like asking your ISP to reject web pages that are badly formed rather than demanding that they be created correctly in the first place. Sharing data requires that senders create compliant data and receivers display compliant data correctly. The money wasted, on NEHTA, and about to be wasted on the PCEHR would easily cover the costs of getting this right. There are no short cuts and any suggesting that there is is naive.
Surely you need a system that creates a proper representation of the data you think you are sending and displays what the sender intended to send you.
If that that is not the case (and its not) then senders are sending incorrect data and receivers are not seeing the correct representation of correct data. The aviation industry would be very scary if it operated like the Health IT landscape does...
Anonymous said on Jan 26, 2011 4:52.00PM
ReplyDelete"There is only one way to fix the problem and that is to ensure that every piece of data that travels between providers is compliant. There is no short cut. Rejected messages may have carried critical data and this is not a solution, but a band aid."
This show a complete lack of inderstanding of the workflow and the nature of patient related information that is sent between providers!
Many providers don't have (or perhaps even need) electronic clinical systems; significant data is related to patients that may not be in a clinical system yet (eg referrals); a lot of data is about groups of patients (eg, operating lists).
However all these information flows would benefit from appropriate secure electronic transfer - to be read and used by people, not automatically populating HL7 compliant databases.
There seems to be a bit of a chasm here between the desires of HI enthusiasts and the needs of providers!
One of the issues is that you need both a clinical and IT understanding. You must use some sort of standard to trandfer data, even if you don't realise that is what you are doing.
ReplyDeleteThe HL7 has nothing to do with the database but describes how to find information in the message. Providers without electronic tools are not going to be sending messages and all messages must comply with standards or the receiver will not be able to work out what to do with them.
If there is a workflow requirement then there is a good chance the standard covers it and if not its a target to extend the standard, but some sort of standard is required.
We do have standards for many of the things people want and whats required it to actually comply with them. Its not optional, but essential to get this show on the road!