FAQs for Healthcare ITThe work of exchanging medical records with another provider in an electronic format is a very challenging one. We will be interviewing Mr. Galen Mulrooney, VP of J P Systems, to learn why this is a very difficult task. He is a consultant who specializes in the design of enterprise healthcare systems. He will address the importance of engaging Healthcare IT Standards Development Organizations.
- What makes creating and maintaining electronic healthcare records so difficult for large organizations?
- What are some examples of the most common problems that need to be solved?
- How does an architect address data privacy issues?
- It is not hard to understand how patients can suffer from the right information not being in the right place at the right time. But what is Service Oriented Architecture (SOA) and how can it help us?
- What is meant by interoperability?
- How do data architects help solve IT problems?
- What is a terminology?
- Why is exchanging healthcare information so difficult?
- Who should be responsible for defining and enforcing these standards?
- How can large organizations control change when they implement new standardized systems to ensure a smooth transition?
- What has J P Systems done recently in the Healthcare IT arena?
- What is the most difficult challenge facing those who want to implement enterprise wide eHealth solutions?
Many older patient records exist in the form of handwritten documents describing a variety of patient symptoms, diagnoses, test results and observations. These records have been created by many different healthcare providers over the years. As a result, the data is not uniform and is hard to enter into a standard electronic format recognizable and usable by everyone. This makes it hard to enter, code and store coded patient fields. If one wants to send clinical data to an outside organization, the problem becomes even more complicated as the codes and terms the two organizations use differ widely. Hence medical terminology is an important area of study for healthcare IT.
Healthcare is often derided as the last industry to take full advantage of information technologies. Unlike banking, where universal functional concepts such as credits and debits are widely accepted, the healthcare industry is still working to establish standardized data transactions and the coded values inside the transactions. Standardized data transactions opens the door to interoperability. Examples of medical transactions would be sending a CAT scan test result to a doctor's office or making an appointment for a doctor's office.
Banking transactions are comparatively simple to those of, for example, laboratory test panel results. Like healthcare transactions, banking transactions must by their very nature be secure. But healthcare lab tests can vary from hospital to hospital, even for those tests called by the same name.
What are some examples of the most common problems that need to be solved?BACK TO TOP
Besides differences in terminologies and coded values, there are many problematic scenarios. Sometimes paper records are lost and the patient has to retake laboratory tests. Or perhaps a patient is unconscious in a medical emergency and the emergency room might not know their name, current medications, allergies, or blood type. Also, when a patient is treated in several medical facilities, the historical record of what was done in one facility ( a doctors' office) may not available at another facility where they are now being treated, like a hospital. If you have ever been annoyed at having to fill out a long hospital registration form, you are experiencing the lack of interoperability. Later, if a patient is seeing many doctors, copies of hospital test results may not be sent to all doctors.
If a patient is released to a nursing home from a hospital, the prescriptions, diet, and history known at the previous facilities do not follow the patient to the current nursing home. The patient has to suffer without any medications at all until they can see another doctor at the nursing home which may take more than a day. The nursing home nurses can not authorize prescriptions even if the patient was taking them at home before entering the hospital. In all of these scenarios, the needed information is not getting to the right place at the right time.
How does an architect address data privacy issues?BACK TO TOP
Security and privacy are important in healthcare transactions, but the recognition of security and privacy issues have only recently become apparent. Privacy laws recently enacted in various countries have the healthcare IT industry scrambling to comply, as the citizenry have become increasingly alarmed about issues such as identity theft.
Various initiatives undertaken by National Governments such as the UK National Health Service’s Connecting for Health and Canada Health Infoway have uncovered the unpleasant reality that the challenges faced by the healthcare industry are larger than any single government can solve by themselves. The problem is not simply a matter of lack of will. Solving the issues plaguing our industry requires doctors, nurses, pharmacists and other skilled clinicians to take time away from serving patients to haggle out a consensus of how medical information should be structured in order for it to be exchanged. This is a large investment that is difficult for any one organization (even a National Program) to sustain for very long. Happily this situation has fostered increasing cooperation among government entities as well as large private organizations (such as Kaiser Permanente in the United States).
It is not hard to understand how patients can suffer from the right information not being in the right place at the right time. But what is Service Oriented Architecture (SOA) and how can it help us?
For more on SOA BACK TO TOP
SOA can help make more detailed records available faster. The goal is that critical information is available instantly in an integrated infrastructure. Defining SOA is not an easy task as the phrase means different things to different people. It is easiest to first define the term service-oriented.
When a piece of software is service oriented, it operates in an encapsulated environment. It makes few assumptions about who it is talking to. At a low level, a service oriented analysis starts out the same way as a functional analysis, which is the process of figuring out what real world functions a software system needs to perform. For instance you must create, edit and delete patient data. You also need to generate reports on the patients. These functions are understandable to a computer user, such as schedule a patient appointment, request test results from a lab, and send a claim to an insurance company. These functions are the business processes of an organization. Once you documented the business processes, one can design the software which performs these functions. In the 1970s and 1980s, this analysis resulted in large stand alone legacy systems which grew over time.
Later, when one needed a legacy system to talk to another legacy system, the problems began, especially because the personnel who wrote these legacy systems had been lost. It now required too much time and money to create these interfaces. Or if you wanted to isolate one function of a computer program, it was found that each part was so interdependent on other parts that it could not be pulled out for new uses.
The SOA approach is to keep the business functions and their logic in one layer and the computer software in another layer. In addition, in the software layer, the trick is to keep the computer programs from having to know much at all about each other. This new lack of concern of who they interface to and how, creates encapsulation, which turns out to be quite precious. Once you have encapsulation, it's not just a function call, but a generic service that anyone anywhere can use! Hence the core of the meaning of service oriented is that we have subroutines that anyone can call, not just other subroutines in our software application but in any software application any where with the same philosophy.
The way to achieve encapsulation is to use objects and XML. Instead of taking it for granted that a function is called with the data (the parameters) in a fixed order with exactly seven pieces of information, SOA architecture says lets put a label with each parameter so that everyone knows what the data contents mean. A function call that used to be:
CALL Create_Pat_Appt("109384679", "Jones", "Pat", "M", "29", "04/06/05", "05/30/06")
now is changed into a service call using XML:
Create_Patient_Appointment_Service(Patient_ID, '<appt_date "05/30/06> <last_name "Jones"> <First_name "Pat"> <sex M><age 29> <DOB "04/06/05">')
So now anybody and anything, a person or a computer, can look at the service call and know the semantic meaning of the data. When you see the "M" in the first function call you don't know whether"M" is for male or for married, or something else. In the second call, we know that the M is for the sex of the patient. In effect International Standards Organizations like HL7 and OMG are standardizing label names for the whole world. By agreeing on the exact labels for each piece of information they are establishing semantic standards. So XML, (which very simply put is enclosing a text label and a piece of data in angle brackets), plays a crucial role in one system being able to talk to another. XML is very simple and very useful. The less mystery involved in one system sending data to another the better.
The first call is a tightly coupled fine grained function call. The second call is what is referred to as a loosely coupled coarse grained function call. In the first example, if any data changes, you need to recompile it, stop the running application, and copy the new executable to the right place. In the second call, no recompiling is needed when the data changes (the patient ID will always be needed), as the changes are all inside the XML string.
In the 1990's when the Internet became available, organizations were motivated to save money by moving as many corporate functions as possible on to the web. So the push began to move as many functions as as possible to the web. SOA unfortunately became synonymous only with web services. Instead of calling the doctor's receptionist to make an appointment, now patients want to go to the doctor's web site and select their own appointment time and see their account information. So people ended up creating separate software systems to perform the new functions the users were demanding. That leaves the old legacy systems stranded in a very different world as a back end.
SOA is much more than just web services. Unfortunately in order for a comprehensive SOA architecture to become a reality, a huge amount of research into all the business processes is needed. Accomplishing one task, like getting a check from an insurance company, may require a series of end to end business processes. Often users do not know what happens outside their own office or they have not been at an office long enough to know why they do what they do. So SOA efforts began to bog down. The cry for code reusability began. Let's reuse the legacy system programs, since we do not want to rewrite them because it costs too much. Besides the legacy systems were tested and reliable. Software systems which had accurate functional analyses done, (that had not become outdated), could often be teased apart and reused. It all depended on exactly how the software programs were written. Thus one could write a program to receive XML calls from a web site, analyze them and make the appropriate legacy function calls. Voila! A new web service calls existing old software. This pseudo SOA results in more web services done faster and cheaper. Of course it is much easier to have a true clean SOA architecture when starting from scratch than when starting with a variety of 20 year old software packages.
What is meant by interoperability?BACK TO TOP
The ability of all providers who are involved with a patient's care being able to store, view and share information easily is called interoperability. Ideally a doctor who has never seen you before should be able to go to a secure central storage place and request your medical history and insurance information 15 minutes before your appointment. But a lot of cooperation is needed for this to be achieved. Where does this ability come from? Initially it comes from being able to separate your business processes from your technical implementation. This double layer of architecture is key here for providers to be able to request and receive secure data.
On one level there are business functions that a medical office performs like scheduling appointments, interfacing with labs, billing insurance companies, and requesting a patient's medical history. Below this are the computer functions that facilitate the completion of these tasks. For instance an office probably has a patient/insurance company billing package. An office may have a web site where patients can go to see a doctor's schedule and make an appointment for an office visit. Or an office may store a patient's chart and progress notes in another computer software package.
Right now doctor's offices are still faxing lab test results when they receive a manually signed letter from a patient authorizing the release. In the future when doctors, patients, insurance companies, and labs are connected and interoperability is a reality, a patient will be able to securely log in to their own Internet site, pay the balance due on their lab test, send a secure digitally signed email release request to the lab, and cause the test data to be released and sent to the desired doctors. The receiving doctor's computer recognizes the nature of the lab test data message and properly stores it where needed. Or the patient could simply make the results available to a list of trusted providers. Each patient could develop a list of their own trusted healthcare providers just as we now build our own lists of trusted email addresses in an email program.
How do data architects help solve IT problems?BACK TO TOP
There are four basic methodologies used to implement electronic health care records: 1. Content Modeling, 2. a UML data dictionary, 3. Messaging, and 4. the development of Terminologies. Each of these four areas is a large subject in itself.
Security and privacy are also important in healthcare transactions, but the recognition of security and privacy issues has only recently become apparent. Privacy laws recently enacted in various countries have the healthcare IT industry scrambling to comply, as the citizenry have become increasingly alarmed about issues such as identity theft, etc.
The healthcare industry has therefore been increasingly coalescing around standardization efforts such as Health Level Seven (HL7), openEHR and SNOMED International. The definition and standardization of Metadata, which is the type of data that describes the nature of the clinical data, is of the utmost importance in interoperability so that everyone can talk to everyone else.
What is a terminology?BACK TO TOP
A terminology is the vocabulary used by the health care providers to describe medical conditions, treatments, diagnostic tests, or drugs. In short, it is a list of any medical words or phrases used. While each industry has its own vocabulary or jargon – typically numbering in the hundreds of terms, the SNOMED International standard called SNOMED (Structured Vocabulary for Medicine) currently contains over 900,000 terms and is growing rapidly. These terms are grouped together in vast hierarchical data structures by concept. One example of a concept would be a kidney stone which has various terms describing it such as renal calculus, nephrolith, renal stone, etc. These SNOMED standards are improved and revised several times a year. Changes at a concept level may cause a cascading effect of thousands of changes at the other lower levels.
When a computer programmer wants to build a reference table to create a code for a blood type, for example, how do you store the blood type in the table? Lets say he decides to store in the database the number 1 meaning "O+", 2 meaning "O-", and 3 meaning "A+". Then what about the other dozen blood type systems out there such as MN, etc.? We need to first define all the blood systems and all their possible values. The actual values stored in the data files are called VUIDS. A computer programmer often does not know the possible values so they have to talk to a hematologist to get the answers. That takes time and money. That's why international data standards are needed, so every one uses the same code for the same thing and doesn't have to reinvent the wheel.
Why is exchanging healthcare information so difficult?BACK TO TOP
There are hundreds of software packages which store and process medical information. They don't code or store data in their databases in the same way. For example, when a computer programmer wants to automate sending a medical record or a test result to someone in a different organization, they have to translate how their data, which is stored in a file as ASCII text, to a coded number the receiving system understands. Maybe the sender uses the text "O+" in their database to represent the O+ blood type. But the receiver uses the numeric code 234 to mean blood type O+. The lack of standardized values is is a BIG problem. Everyone has different reference data. That is like everyone in one city using a different English dictionary from the people in the next city 30 miles away.
Unless you do a detailed exhaustive study of how to map your enterprises' data to the receiver's data, you can't exchange that data. You can send them data, but their system sees a meaningless number instead of text. For example, assuming the receiver knows a blood type is coming, when it looks at the letter "O" which is coded in ASCII, it sees the number 79. A plus sign, +, in ASCII is the number 43. The numbers 79 and 43 are probably total garbage to the receiver as a code for blood type. If it happens to be a valid blood type by sheer chance at all, we can assume is is the wrong one. It is not the 234 it wants to see in order to understand the message accurately data. So as I am sure you do not want to receive a blood transfusion of the wrong type, there is no room for error here. The data which is sent and the data which is received MUST be perfectly reliable and perfectly understandable.
It doesn't sound so bad until you think of the hundreds of thousands of terms and values involved in blood grouping alone. You may have heard of the ABO system and the Rh system (+-). But there are dozens of other blood groups as well (Mary Nancy, etc.). So sending messages and exchanging data becomes problematic even for just this one piece of information. Think of all the other pieces of data needed to make up one medical record and the enormity of the problem starts to come into focus. Not only the coded values but the format of the message need to be recognizable and usable by the recipient. This is an example of a problem that the standards organization HL7 is working on.
Who should be responsible for defining and enforcing these standards?BACK TO TOP
With any given organization, a CIO and their software architects who see the big picture along with a management team who understands the inherent problems and supports adherence to standards should call the shots. The results from standards efforts are not always easily measurable or visible. But the work is crucial none the less.
How can large organizations control change when they implement new standardized systems to ensure a smooth transition?BACK TO TOP
It is crucial that managers and high level ministers understand the problems inherent in healthcare IT. Often management who do not understand the importance of a top down all encompassing SOA architecture will not budget sufficient funds to make interoperability a reality. It takes a lot of work to do the end to end business process analysis to lay the foundation for a SOA. Then change must be managed so that not only the the IT processes are coordinated but also the business processes, the personnel who use them, and the facilities and hardware are all in sync with the changes.
What has J P Systems done recently in the Healthcare IT arena?BACK TO TOP
Our company, J P Systems, Inc., has been consulting in the healthcare IT industry for over 17 years, primarily in the United States. We helped the U.S. Dept of Veteran Affairs Veterans Health Administration (VHA) to model their terminology data, matched several domains of local terms to international and national standard terminologies, and tested a utility for working with terminologies. In March of 2018 we release a brand new standard drug terminology called MED-RT. It will replace the NDF-RT. Training videos for using this new terminology have been produced and are on our YouTube channel.
See our Projects page for more information.
Our experience has taught us the importance of engagement with the Healthcare IT Standards Development Organizations (SDOs). In the United States, recent regulations are forcing the SDOs to “harmonize” their standards where they overlap; this was initially met with some resistance and a bit of confusion as the overall strategy was sorted out. Nevertheless, the previously-competing SDOs are now actively cooperating to develop a set of complementary standards.
What is the most difficult challenge facing those who want to implement enterprise wide eHealth solutions?BACK TO TOP
Arguably the most difficult nut to crack is terminology. But recent events are showing great promise. SNOMED, which is among the most sophisticated of medical terminologies, used to be a proprietary standard. Users had to pay a license fee to use it (more likely, a software vendor paid the fee and passed the cost onto its customers). This was a major impediment to SNOMED’s adoption. And yet, developing and maintaining such a terminology standard is very expensive proposition – sooner or later someone must foot the bill if the standard is going to be robust enough to be useful. This issue was solved when SNOMED’s owners, the College of American Pathologists (CAP), decided to create the International Health Terminology Standards Development Organization (IHTSDO) and transfer the intellectual property rights of SNOMED to IHTSDO. IHTSDO licensed the right to use SNOMED to national governments such that each government paid an annual license fee to IHTSDO. This allows any citizen of that country to use the terminology free of charge. This approach removes the burden of licensing fees that have been hindering the uptake of standardized terminologies, while still providing the funding needed to support the on going efforts of the clinicians involved in building the terminology system. IHTSDO renamed itself to SNOMED International.