As I sit here watching Season 3 of “Stranger Things,” and initially typing this on my Tandy 102 laptop circa 1987 (pictured above), I am reminded of how far we’ve come with technology. The devices we use now need a lot of work or converter devices to connect to the ones from the 1980s. We've had to do a lot of work to get data from these systems transferred to modern ones. It hasn’t been pretty.
Thankfully I have a Windows 10 PC with a DB-9 serial port and Tera Term VT on it that allowed me to upload this file from it. I know there are more modern data transfer solutions for the Tandy 102, but just haven’t set one up yet. It’s on my ever growing to do list.
One other set of items to keep in mind is how system constraints that we do not have now factored into decisions we made back then. Back in the 1980’s, your average system used for data entry or collection ran an 8 or 16-bit processor at less than 10 Mhz and had less than 512K RAM (the Tandy has a 2.4Mhz 8085 and 32K RAM). Many of the data collection terminals were just that, dumb terminals.
Communication speeds topped out at 9600 bits per second over a serial line, approximately 400,000 if you had Appletalk, or if you were very lucky, 10 megabits to a shared Ethernet hub. The ability to do data checking itself was constrained. Lookups to validate keyed-in data against a database were not easy to do. It took a lot of effort to have a product run on more than one platform, even if that was UNIX, due to the large variety of proprietary platforms with unique constraints and the “UNIX Wars”. While there were ISAM databases, mainframe databases, dBase, and FoxPro, you had to do a lot of custom work to make your code run well on slow processors, and that time cut into validation.
Security wasn’t even a factor, as the basic encryption algorithms and processes we take for granted now, such as Transport Layer Security (TLS), Virtual Private Networks (VPN), Secure Shell (SSH), or IPSec were years away. Encryption was the domain of UNIX machines or mainframes. /etc/passwd stored password hashes. The Morris Worm (and Sendmail) showed how bad security really was in the 1980’s.
A better future
Windows 95 and Windows NT were the beginning of a better future for application development and data management. They gave us application development environments capable of building better data management tools that worked consistently across platforms and allowed connectivity to UNIX, IBM, DEC, and other platforms. Visual Studio, Powerbuilder, the Borland environments (TurboPascal/Delphi, C++ Builder), FileMaker, and the much-maligned Access helped here. Between 32-bit Windows and the rise of Linux and open standards, there was significant improvement in just application development alone. The support of TCP/IP and Ethernet in Windows 95 and NT also helped improve connectivity speeds.
The shift to relational databases, specifically Oracle, SQL Server, Sybase, DB/2, and Informix, and the use of semi-open (ODBC) standards delivered on the client/server promise. Intel produced the Pentium and Pentium Pro, which gave desktops the power of UNIX workstations that cost tens of thousands of dollars. Intel also helped Linux significantly with these new chips, as you didn’t need to buy expensive UNIX servers to run web applications.
This also enabled not only rapid development, and for non-developers to write code and develop their own systems. Before the wide use of Electronic Medical Records (EMR) outside large academic medical institutions, pathology labs, and the Veterans Administration, many doctors wrote their own EMR-type systems to improve their workflow. Revenue Cycle was doing the same thing with billing data, and Access was the tool of choice for them mainly because it made processing fixed-width files from mainframes very easy. Finance and Accounting heavily customized their accounting packages to meet their needs. Very few of these bespoke or customized systems had security worth mentioning.
Data conversion background
Before I got into security, I started out in data conversion in the 1990’s. I specialized in converting and documenting these bespoke and custom systems to standard formats and had several repeat customers. My first major project was to convert 20+ years of kidney dialysis and transplant patient data from Paradox 4.2 to SQL Server. This project took me over a year and part of it required developing numerous tests to assure the integrity of the data.
The next project was to convert five different databases from various formats, including custom Access databases, to text formats for a solid organ transplant database to support an academic medical center’s program. In this case, I also had to build numerous test cases to assure the integrity of the converted data. This customer took 18 months to complete the project due to the complexity of the data points collected for lung transplants.
The third case was converting a call center database from a Cold Fusion application to a more modern call center one. That was a complete and total mess to deal with because the developer did no validation and had thousands of calls logged. This system was a challenge because it involved fixing the database, re-homing the system, adding in security, and building the needed management reports on the fly before conversion work could begin.
While many in the IT community often look down on developers who implement fixes in production, sometimes there really is no choice. Unfortunately, sometimes you have to work with a combination of really bad tools and even worse code.
In each case, there was a significant amount of re-work and fixing of data I had to do because of applications either changing values or not properly validating inputs. I had to reconstruct data fields based on other data points. I also had little to no documentation and had to pass numerous third-party validation tests, the toughest being the one from a transplant software company, OTTR. This was over 90% of my work.
The Kimball Method, a well-known methodology for building data warehouses, estimates 90% of the work for a data warehouse project is in Extract/Transform/Load (ETL). This was proven correct multiple times. Numerous other projects, especially in Revenue Cycle, Medical Billing and Coding, and with conversions for EMR implementations (Epic and Soarian), reinforced that.
Wallpapering over core data issues
This brings us to our current situation. We have numerous databases we are attempting to use as sources for intelligent systems. We are feeding numerous databases to them that may not have had the same scrutiny over their integrity. We are building a decision-making infrastructure based on large amounts of data that we cannot verify or validate and has had numerous changes since its initial capture or input. We cannot add security on after the fact.
What we are doing to prepare for the Trusted Exchange Framework and the implementation of the 21st Century CURES Act is exactly that. We are putting Application Programming Interfaces and sophisticated cryptography on top of data and systems that have been assembled from numerous other systems and pieces over the past forty years. We are attempting to use modern means to solve long-term problems while not addressing the core processes that have brought us to this point.
Healthcare did not start out behind, it is a prisoner of not changing workflows to meet the times and having tech bound to decisions made a very long time ago. Healthcare is also very susceptible to mimicry of high performing health systems as a substitute for introspective analysis and meeting actual organizational needs. This is especially true with EMRs and supporting systems.
Structurally we’ve had a number of departments throughout health systems that have had their own sets of rules that have evolved over the years. They have done what they want in the absence of strong organizational governance. Current organizational structures, such as non-centralized medical staffs and health system corporate leadership teams acting like holding companies, continue to perpetuate the separation.
This led to situations such as rapid cloud adoption by health systems without Information Systems involvement on an app-by-app basis without a clear strategy or security foundation. This also led to design by committee on EMRs, where millions of dollars have been spent on customization to meet each individual department’s needs without addressing them as a whole, and causing significant financial impact to these organizations. Security hasn’t even been a factor, as most of the time they are not even aware of these systems, let alone the issues.
We haven’t had that coordinating force better known as the Chief Medical Information Officer (CMIO) addressing these fundamental issues until well after many of these bespoke solutions were developed or the EMRs implemented. They have to not only promote interoperability, but also address process reengineering to ensure that the systems of record are being utilized the right way and are capturing the right data. In many cases, they’ve had to fix EMRs and security with little downtime, which is the equivalent of fixing a plane in flight. Their role is underappreciated and often not acknowledged or empowered the way it should be.
Addressing the issues
We have two areas we need to address. The first is with device data acquisition and developing a trusted path. We are utilizing numerous consumer-grade and professional medical devices to feed intelligent systems to make decisions. However, we have not done many of the requisite integrity or security checks required on the devices, with the systems that store the data, or how they end up at their final destination in the electronic medical record or intelligent system. The recent number of vulnerabilities reported with the DICOM protocol currently used to transmit images from radiology modalities shows that this is still an issue.
This is an area we haven’t advanced much in since the days of Paradox front ends and dedicated serial lines. Mobile technologies have advanced greatly; however, we need to address two issues there as well. The first, and most prevalent, is the issue of getting the newer smart devices to work consistently throughout hospitals without signal loss like pagers currently do. 5G and newer Wi-Fi standards exacerbate that by using significantly higher frequencies that do not have the range of current pagers or smart devices. Secondly, we have to build better user interfaces that take actual mobile use cases into account.
The second is with process improvements. We have implemented these systems without thinking about how to redevelop or reimplement processes. This has led to the issue of data islands, because numerous customizations have given us unique data sets and unique collection methods that are not standardized or best practice, even amongst different implementations of the same Electronic Medical Record. We must continue the work on standardizing workflows and processes to allow for best practices and data collection methods.
This isn’t the 1980’s or 1990’s where you could pick up Visual Basic and write your own front end because it met your needs better. We have to get away from that mindset of customization. What we do when we allow this is to not accept that there may be a better way. We need to focus on best practices and standard work to truly allow interoperability and empower the CMIOs. We also need to avoid the tendency to build layers on top that reduce our ability to update, upgrade, or mitigate security risks through complexity.
While there has been significant talk, and numerous demonstration projects demonstrating the value of many newer technologies, there haven’t been corresponding pushes to address the trusted path or process improvements needed to make these implementations successful. Blockchain and Smart Contracts, in these cases, immortalize our decisions. Fast Health Interoperability Resources (FHIR) is just another API-based means to push data between systems without thinking about how it’s collected and stored. We just add another layer on top of the same core processes, and this lowers our expectations.
If we’re going to be implementing these newer systems to facilitate interoperability and intelligent decision making, we need to scrutinize our data and acquisition processes. We need to make sure that the workflows that we use to generate them are secured, and that we use our Electronic Medical Records systems the intended way to store data starting at the process level. We need to be thinking of securing workflows and entire systems, not just about securing devices or individual pieces.
Back in 1985, the focus was more on how technology could improve our lives. We progressed on this front until Electronic Medical Records became ubiquitous. We need to focus on model standards, model processes, and better ways to accomplish tasks. This allows us to consistently apply security standards and practices. We need to do so to interoperate and provide consistent data to intelligent systems. The end goal is to have technology continue to help improve healthcare. However, to do so, we have to ditch the 1980’s mindset and focus on a collaborative future, as it won’t until we do.