One of my staff had an interesting experience many years ago. He had an internship at a life insurance company.
The company maintained a huge array of virtualized AS400 machines that were running a number of legacy COBOL applications which described life insurance policies. The company needed to maintain all these applications for the life time of the actual policy holders. i.e. over a 60-70 year span.
The rules regarding the benefits for the policies and so on were so strictly tied to the actual software applications written in COBOL that it was more economical to keep all these applications going rather than attempt to try and convert the policies over to run within a new application.
These applications represented hundreds of millions of dollars worth of liabilities and benefits.
What does that tell us about interoperability standards?
From what I have looked at, the information in the insurance segments of HL7 is far from being a comprehensive insurance data model. The fields which are present are more about giving hints to the healthcare provider who the claims should be submitted to, rather than really giving a full picture of a patient’s actual coverage.
Given the clear challenges that the insurance companies themselves have achieving data portability of their own policies it seems unlikely that anyone could ever come up with an adequate data model to fully describe insurance data. Ironic given the HIPAA act. I guess if people change companies that they can reasonably expect changes in their coverage – but not if they are staying with the same company.
This is just one domain area that covers electronic medical records. As you drill into each area of medicine I think similar challenges arise.
So given these realities how do you make interoperability standards that can embrace all this complexity?
My thoughts are that it’s a losing battle to try and encompass everything. Instead focus on getting the ‘scaffolding’ right. Interoperability standards which can define the core-backbone that maps out information in a logical manner are doing something useful. In a sense that is what HL7 2.x insurance information already does, since it really is just reference information. It only solves one problem key to healthcare providers which is to locate who to bill and submit claims to.
Having extensible standards that allow additional information to be added is a benefit or a necessary evil. Your stance on this depends on whether you’re a glass half full or a glass half empty sort of person.
Standards should cover the broad areas and make it possible to ‘glue’ things together in a manner which makes it easy to recall information, but subtleties from the existing software will always be felt. How important those subtleties are will come down the nature and value of the information concerned.
Electronic healthcare records need to be extensible and display information ‘as is’ from a variety of systems. In the world of HL7 2.x the extension mechanism is what are called custom ‘Z segments’. The problems of Z segments will be the topic of my next blog entry…