With the push to move to electronic medical records, it is important to note the high risk for healthcare institutions to adopt them. It is also necessary to be able to gauge how EMRs will evolve over time and the challenges they will face. Interestingly enough, the DICOM standard has been going through the same pain points that EMRs will face for over 20 years and as a result provides a treasure trove of experience from which EMR development can only benefit. Medical images have already gone through this transition from analog to digital and faced greater challenges in terms of storage requirements and available technologies.
What is DICOM?
For the readers unfamiliar with DICOM, it is a standard for the transfer, storage and display of medical images. Information about the image is embedded directly into the image file ensuring that its context is never lost. From its beginnings in the 1980s, it has evolved over time and devices have progressively adopted the changes. Current medical devices need to support current and past versions of the standard in order to be able to interoperate with other devices or systems which may all speak a different version.
What has DICOM taught us?
- Publication of standards allows different vendors to exchange data in a meaningful way.
- Data capture should be analogous to taking a picture. It should retain:
- What is captured
- How it is captured
- For whom it is captured
- When it is captured
- The standard the capture adheres to
- Proprietary data fields are problematic but will be needed until standards evolve.
- Backward compatibility for standards is important, especially given that the lifecycle for medical deployments are very long.
- Both analog and digital versions will need to coexist until adoption covers all modalities and all analog images can be converted into digital format.
- Having digital versions of files improves accessibility and alters workflows.
- The amount of time needed before the standard stabilizes is long and changes with new technologies.
What should change about how EMRs are built and deployed?
There should be a focus on developing standard data sets and clinical reports. Although there is much work being done in developing general standards, like CCD, more effort is needed to develop specific implementations of it for specific reports, rather than a single solution for all. An example could be a report generated for a cardiac exercise stress test. Right now it is at the discretion of the vendor and usually not very well done. Hospitals circumvent these and produce their own formats. The result is that patients do not get a consistent view of the data results or the medical interpretation. With established standards, the specific vendor would not influence the output—their time is better spent on improving the data capture portion anyway!
As new best practices or approaches are adopted, changes to the standards can be made. Report writers would then be updated to support the new version while viewers would have to support both versions. When a vendor creates a new data capture application, they would also have to develop and update the standard so that the EMR would be able to support it.
The DICOM standard should be viewed as an example of successful application of IT in healthcare and EMRs should adopt the same approach so that 10-20 years from now it will achieve the same level of meaningful integration into hospital processes.
In these times of increased productivity, there is a push to move legacy data entry applications onto newer platforms which are better at facilitating collaboration and information sharing. One common pattern is where a legacy data entry application gets ported onto the web. Unfortunately, unless it is done right, bringing an application to the web presents users of the new system with many usability issues. Typically web applications for data entry come in the form of text fields, checkboxes and radio buttons. Users can click their answer and navigate from question to question by scrolling up or down or clicking on a button to see the next page.
This process is suited for situations where the user is entering most of the information from memory, such as with a checkout from an online store, i.e. you always know your name, shipping and billing address.
In healthcare scenarios, often users are transcribing data from a paper sheet or from another system. This situation is common when the entire healthcare process is not electronic. Data on paper will get entered by a transcriptionist or clerk in batches. In such cases, the application needs to draw upon the strengths of the user. Transcriptionists are trained typists and efficiency gains can be observed if the application is able to draw on their typing ability. It is for this reason that web applications made for data entry specialists need to make exclusive use of keyboard entry. In this way, they can keep their eyes focused on what they are entering and not have to go back and forth between the paper and the computer screen. In such a case, the order of entry is important. The program must prompt the user in the same order as the questions appear on the paper form.
In other cases, when data arrives in a more real-time fashion, then the application can make use of the mouse in order to give the user more flexibility as to the order data is entered. In these cases, the users typically have more time and are using the application at the same time as interfacing with the patient. Speed and efficiency are not the main goals of the program in this case. Typical users which fall into this category are doctors, nurses and technologists.
With the different habits of users known, take special care to optimize how data is collected even in terms of which device is being used to perform the input. Don’t make the mistake of applying usual web practices for users who are not used to using the web for their jobs. The medium of ‘the web’ needs to be adapted to the users’ habits and not the other way around.
Microsoft Excel is used routinely in medical clinics as a way of managing patient data. Is there anything so terrible about this or is it a good way of running things?
On the surface, there is not much wrong with using it. Excel can do it all: data fields, graphs/charts, calculated values, spreadsheet references, etc. It is cheap, present on nearly every computer and everyone knows how to use it in some capacity.
Digging a little deeper, however, many problems exist:
- No data input feed. Data must be re-entered even though it was probably already entered into another system. This wastes time and provides another opportunity for data entry errors.
- No data output feed. The data remains in place and provides no benefit to other systems. If anyone wants the data, they have to access the spreadsheet directly.
- Promotes data silos. Usually management is organized per clinic or department. If the data is collected and managed at one point, then it will remain as such and require much more effort when the initiative comes to integrate the data with data from other systems.
- Data inconsistency. When the same data exists in two or more different sources (or spreadsheets), effort is spent to keep all sources consistent. If data in one location changes, it needs to be updated in all other locations. Databases offer a much more flexible environment where design practices reduce data duplication and therefore facilitate data updates.
- Low security. Spreadsheets can be weakly protected with a secret password, but this is easily bypassed with programs to remove the password. Better security is offered by databases.
A database on the other hand can help alleviate these problems, but it does require a greater level of infrastructure. It mandates the need for people who know how to use and manage it. Front-ends are needed to manage the data and servers to host the database instances. It is for this reason that in many small clinics, where these things are not present, Excel is the tool of choice.
The only case where it truly wrong to use Excel is in an environment where the necessary infrastructure exists, but for whatever reason, clinic managers choose not to use it. It is in this type of context where the most amount of time is wasted given the limitations of Excel. The clinic could be managed at a much more serious level if the full functionality of the deployed databases was leveraged.
The visible side of healthcare is about clinical professionals diagnosing and treating patients. The other side of the coin is not so much about delivering healthcare, but more about pushing the limits of medical science. In other words, this is about the need to collect health data, analyze it and use it to improve medical best practice guidelines.
At every point in receiving healthcare, data is collected about you. Your name, the time of visit, the time the doctor enters the room, the time he leaves the room, medical findings, treatment details—basically anything and everything that can get recorded is recorded. This data goes into databases and can get accessed by hospital administrators, managers, medical researchers, all working to improve the quality of optimize the delivery of healthcare.
Leaving out the analysis done for hospital management and focusing just on the medical side of things, there are essentially two different kinds of data analysis: prospective and retrospective. Prospective deals with the situations where you know what you are looking for and you want to confirm it, as is the case with clinical trials. Retrospective is where you have some idea about what you’re looking for and seek to obtain justification for it by looking at historical data. This can lead to the development of new drugs or procedures for which a clinical trial would be needed. It could also be the basis for medical research such as showing how one procedure is more effective than another.
With this need for data, comes the need for data storage and management. Behind the scenes in hospitals are the databases (or data warehouses for which Oracle, IBM and Microsoft have solutions) that hold the data. Accessing the data is a completely separate process.
A company like Phase Forward, offers products to help deal with the handling of prospective studies and adherence with governmental regulations. Retrospective studies can be supported with by data governance software such as that offered by Informatica.
This aspect of healthcare is huge and translates into an enormous amount of work to get it all working smoothly. Despite being relatively hidden from the principle healthcare customer (the patient), it exists and basically exists to support everything that goes into delivering the healthcare offered.
The future of healthcare is as a commodity-based service. What this translates into is a fee-for-service model where each element of the healthcare process becomes an individual product a person can buy. For example, each of these items would be a separate service:
- Have a diagnostic test
- Need someone to interpret the results of a diagnostic test
- Have some surgery done
These can be handled by different doctors or the same; it is up to the patient/customer. It is no different from buying something like legal services. It offers the benefits of choice and more control over the course of treatment the patient receives.
As the components of care get broken down into their smallest points, each becomes a simpler process that interfaces with others. In its most abstract form, the process for healthcare delivery can be described as follows:
It is this process that allows medicine to be commoditized because each element of it can be performed anywhere, with data being fetched and saved from and to wherever it is being managed.
If this is the future, then how will software adjust to accommodate it?
Current PHR solutions like Google Health and Microsoft HealthVault are helping to empower the patient to manage his healthcare data. In the future, hospitals will push their data to these locations or others and so their software capabilities need to be upgraded. Ultimately, it offers a solution where healthcare providers will have access to all the information about a patient in order to offer a better product to the customer.