1. Healthcare IS: The Obsolete and Broken Infrastructure
The healthcare Information Infrastructure is both an obsolete and broken system. It has at least four major problems. The total system is technologically fractured between paper-based systems and computer-based; and the computer-based system is shattered among competing technologies, (for example, PC versus smart phone). The number of health-care information regulations and standards militates against a coherent information infrastructure.
The Fractured System
Any system in a technology change process will be fractured between the old and new technologies. However, the healthcare system is particularly fractured because of overburdening federal regulations for insurance, for care, and for HIPA.
Then there are the interlocking state regulations and insurance policies and procedures. All of these make creating a healthcare information infrastructure difficult and complex.
Additionally, a significant portion of the medical professionals are the opposite of tech-savvy. So they stick to paper—lots and lots of paper. Compared with electronic storage, the simple storage of paper is expensive. Then there is the time and expense of retrieving a patient’s medical records. All of these costs are absorbed in the cost of healthcare.
But there is yet another, potentially life threatening expense; the loss of records and the inaccessibility of records when patients are on travel. When people move for a new job or other reasons, the medical data contained in their records is more frequently than not lost.
When they travel and have an accident or medical problem, their medical records contained in this fractured infrastructure are normally inaccessible. The inability of onsite medical personnel to have access to a patient’s medical record can be an unnecessary death sentence for the patient.
Number of Regulations and Standards
There are other problems caused by this fractured healthcare information infrastructure. As noted, there is a large increase in office staff to manage the paper records caused by the regulations supporting the “affordable care act”.
This is in addition to the HIPA and state regulations, and insurance company’s policies and standards. Is it any wonder that doing paperwork is the single largest expense in a doctor’s office or medical center?
Non-linkage to Research
One of the most significant challenges in medical research on various diseases is tracking a disease through generations to determine if the disease is caused by environmental factors, or by a person’s generic heritage. Given a set of standards and regulations (not over regulations) an integrated healthcare information infrastructure could provide the necessary information to enable much better insight in a much shorter time, at much less expense.
Non-linkage to Technology
There is another very expensive problem caused by the highly fractured and fragmented information infrastructure. Currently and increasingly, there are many digital sensors on the medical device market. These sensors include, X-ray, MRI, and cat scan machines. There are also digital thermometers, blood pressure sensors, heart rate monitors (including Fitbit, Garmin, and Apple watches).
Additionally, they include a host of equipment for evaluating eyes, ears, blood, nervous systems and the hundreds of other evaluation sensors.
2. Customer (Patient) Centric healthcare Information Infrastructure Architecture
A goal of a customer-centric healthcare information infrastructure architecture is to enable the customer to have complete access control over his or her health data and information in an ultra secure data network (USDN) while providing a high-level access to non-personal (i.e., aggregated) data for research and development.
I recently posted a high-level architecture for such an USDN; having said that I will now the healthcare information infrastructure as an example.
Customer ID and HIPA
The first component of this USDN is the user (customer) interface. The key concept embedded in the HIPA rules and regulations is to keep access to the customer’s data to only those with a need to know. Currently, the person who gives written permission is the customer [Sidebar: I don’t like the term patient because of its implications and connotations.]
With the USDN, the user/customer would give permission to medical personnel by inserting a smart card. This card would contain biometric data. The user/customer would then use the sensor on the medical terminal to confirm that they are who they say they are. For example, put their finger on a fingerprint reader.
If the biometric information on the card matches the information given by the user/customer then the medical personnel can get to the portion of the customer’s medical record and history they need to do their job.
If a customer comes into an emergency room unconscious the medical personnel can get authorization in much the same manner. This could save the customer’s life.
In a hospital, the access to the customer’s record and history could be systematically extended to all appropriate personnel through the use of authorization or entitlement meta-data.
The Bridge/Portcullis
A second unique feature of the Ultra-Secure Data Network is the network bridge with portcullis. The bridge converts the standard Internet communications protocols (that are well known to hackers and which malware uses to attack computers) into a set of network protocols much less well known.
The portcullis allows only a limited set of formally defined data in formally defined data formats across the bridge. The portcullis has other functions that are somewhat arcane, but which are important for security. [Sidebar: A high-level description of these is found in my post on the Ultra-Secure Data Network]
Centrally Organized Geographically Distributed Datastore
The data storage software will be what is currently being call “in the cloud”. That means that the data is stored in data centers that are protected by the USDN including the bridge/portcullis. Additionally, the operating system and application software will be customized to accept only data that is in the authorized formats.
Datastore for Research
The Medical Information Infrastructure is a cornucopia of data for medical research. Currently, this data is, in the main, inaccessible to medical researchers due all of the rules and regulations for the current fractured system and to the nature of gathering data from a fractured system.
With the functions and features of using the USDN, data from the Medical Information Infrastructure could be made available to researcher without destroying the privacy of the customers of the system. In turn, this would reduce the cost of medical research significantly.
3. Building the USDN
Because of the size, scope, and complexity of the Medical Information Infrastructure it will take at least 10 years for the initial build out. I will describe the major tasks of the build out, as I envision them, currently.
Setting up the Governance of the Infrastructure
The key to the USDN is setting up the processes for defining data, meta-data, governance, and infrastructure management. Without these, the infrastructure will either be hacked immediately or be completely ineffective.
· Governance
As I see it, the governance of the infrastructure will make or break both the security and utility of the infrastructure. This governance sets the data, meta-data, and infrastructure management policies, standards, and rules for the infrastructure.
That is why it needs to be the first task; though it will run concurrently with other tasks.
As I envision it the board of governors (guiding group, whatever the name) should be made up of medical professionals, medical researchers, insurance personnel, and IT professional from business and academia. Getting that eclectic group moving in the same path will be difficult. Therefore, I think an Enterprise Architect with a Systems Engineering group will be needed.
· Data
There will need to be a process set up for defining the data that should be in the USDN, the format for communicating that data and for creating, updating, and deleting data formats and structures. Once set up this will be one of the key governance processes; changing data types and the actual data formats as technology changes.
One key to the USDN is that no unformatted data, like e-mails and e-mails with attachments will be allowed. This cuts off one prime access points for hackers.
· Meta-Data
For security purposes, the definition and delimitation of the infrastructure’s meta-data is of seminal importance. It is what enables authentication, authorization, and access to the data of the Medical Information Infrastructure. The governance body together with the Enterprise Architect and the Systems Engineering group will need to make decisions as to what is and what is not allowed, always with an eye to securing the data.
For example, the terminals connected to the internet, in turn connect to the USDN through the Bridge/Portcullis. Each of these terminals will have a specific and static Media Access Control (MAC) address. I would recommend that these terminals also have a static Internet Protocol (IP) address and other static information tied to that particular terminal. This would make is difficult to spoof the bridge/portcullis into allowing a hacker through the gateway.
Additionally, there are many other ways this static (or infrastructure management only) meta-data can be used. But they will be guided by the rules and policies set by the governance board.
· Infrastructure Management
The infrastructure management team will manage the hardware, software, and meta-data of the Medical Information Infrastructure as the prototype is rolled out and the operational version is built out. It will be under the guidance of the governance board.
Developing the Bridge/Portcullis
The design requirements for the bridge/port will come from the standards and policies set by the governance board as architected by the enterprise architect and the functional and component designs will come from the Systems Engineering team.
There are several technical innovations required for an operational USDN. I would recommend that a series of prototypes be developed using a cyclic process, like the one I developed and was patented by the Northrop Grumman Corporation. That is, design, create the prototype, test, and repeat until all of the requirements are met. I would expect that this development effort will take a minimum of one year and can be started about three to six months after the governance board begins their work which will identify the requirements for the equipment.
The first is the Bridge/Portcullis.
· Designing
Designing the bridge/portcullis can be divided into two functional designs. The first is the design of the network bridge. This should not be as much about creating a design as resurrecting a design of a network bridge from the late 1990s.
The second is the design of the portcullis. This is a wholly new functional and component design, though based on many standards.
When these functional and component designs are complete, then the entire bridge/portcullis will need additional functional integration design work.
· Prototyping
A series of prototypes will need to be constructed, in following the Technology Readiness Level (TRL) characteristics. I expect that the bridge can be prototyped at level 7 or 8 right from the start. However, the network portcullis starts as a TRL level 1 or 2. It will need to cycle through a number design, prototype, test cycles before it will be ready for integration with the bridge.
· Testing
All prototypes will be evaluated against the metrics as defined by the requirements. This means that prior to testing the systems engineering team will need to establish metrics for each requirement.
· Rollout
When all of the cycles of design and functional testing and requirement evaluation of the bridge/portcullis are completed, the unit will be replicated two or more times for use in the pilot testing effort.
Developing the User Terminal(s)
The user terminals for the Medical Information Infrastructure are an interesting combination of advanced technology being used for a single purpose terminal (a throwback to the 1960s). Some of the functions of this terminal type are discussed in my post on the USDN. One key function will be enabling automated medical sensors (X-ray, MRI, etc. machines) to report results of tests through the terminal to the Medical Information Infrastructure.
· Design
Again, the design of this terminal should start as soon as its requirements are identified (3 to 6 months. In this case, the design is really more in terms of a system integration of functions rather than the development of new technology.
· Prototyping
Constructing prototypes of the terminal should not nearly as difficult as the development of the bridge/portcullis. But again, it is likely that several prototypes will be needed to get the functions and form factor correct for the terminal.
· Testing
Likewise, testing should be relatively straightforward. The most extensive set of tests will be those associated with terminal and network security.
· Rollout
When all of the cycles of design and functional testing and requirement evaluation of the terminal is completed, the unit will be replicated several times for use in the pilot testing effort.
Datastore
The datastore, the hardware and software for storing the customer’s data, is by far the simplest of the functions/components that will need to be developed. The reason is that commercial off the shelf hardware and software is available.
· Design
In this case the challenge is to write custom code and define the parameters of standard database software and the operating system such that the data is secure from hacks inside individuals (the technical staff) and to provide the access for the various functions of the infrastructure. For example, giving access to researchers to summarized or anonymous data would be one such function.
This development exercise would use a cyclic process, like the one I developed and Northrop Grumman patented.
· Prototyping and Testing
Even while a software service is being coded it will be evaluated on a daily basis and formally tested at least once a month. Frequently, the testing will not only reveal bugs and inconsistencies, but also additional governing board requirements and technical risks.
· Rollout
As opposed to the bridge/portcullis and terminal, I expect that the datastore appliance (the combination of hardware and software) will be rolled out as an Initial Operating Capability (IOC) with a minimum number of data structures and software functions.
Additionally, I expect that one a one to three month cycle, new versions of the software will be integrated into the appliance.
Pilot Testing and Updating
Once the governance board has decided that enough of the bugs, defects, and other “gotchas” have been worked out of the system (likely after about one and a half to two years), the infrastructure will need to be acceptance tested. For this type of system pilot testing is the only procedure guaranteed to clearly demonstrate all of defects in the total system from the various users’/stakeholders’ perspectives.
Ideally, this would be a progressive slow roll out, first to a single site, then to three sites, then to 10 to 12 sites with at least 3 data centers. Ideally, this piloting phase will take one to two years.
At the same time there should be a significant increase in the types of data the infrastructure can store and the number of functions the infrastructure can perform for the various stakeholders.
Build out of the Infrastructure
Within six months of the start of pilot testing, the build out of the infrastructure can begin with user/stakeholder education about the infrastructure. These educational activities will prepare the medical and medical IT professionals to deal with the coming changes in a more orderly manner.
As the pilot testing is coming to an end, hardware and software companies should be invited to start building products to the infrastructure’s specifications. These would be sent to a test environment for certification as meeting all of the specifications.
These competing products could then be sold to the medical community as the infrastructure is built out across the nation.
4. Issues
I would forecast that creating the Medical Information Infrastructure will reduce the total medical bill paid by customers, insurance companies (including governments) by 10 to 30 percent while producing much better outcomes. This is a significant reduction in cost (hundreds of billions of dollars per year).
However, there are powerful groups that will oppose the infrastructure’s creation. Some of their arguments will be economic and some emotional (in terms of politics or organizational culture).
Implementation Costs
Many in the current medical establishment point that the implementation of this system will be very expensive. It will; there is no doubt of that. It may run into $100 billion over ten years, but it will likely save more than $10 trillion over that same period. That seems like a good investment for the country. With the added bonus that it will save lives.
From a hospital or insurance company’s CFO perspective, this will turn into a gigantic expense for which there will be no immediate ROI. [Sidebar: This turns “short-term cost conscious” CFO type financial engineers nuts—I know.] Again, they are correct. But there will be a significant ROI long-term.
Politics/Cultural Issues
There are also many political/culture issues
· The Affordable Care Act, Medicare/Medicaid, HIPA
[Sidebar: The US Constitution specifically states that governmental healthcare, like other social entitlements are within the purview of the states, not the federal government; an attitude that my ultra-left leaning “social responsible” friends find distressing. However, since we’ve already entered this financial black hole that lead to dystopia, I think we need to find a way out of it or at least to ameliorate many of its worst effects.]
These federal laws mandate a great many enforcement rules and regulations. These rules and regulations will be unnecessary with the Medical Information Infrastructure. However, many federal and state bureaucrats will have to find other employment if they are removed. So, politically they will lobby for most of them to remain. This will cause a great deal of process friction and greatly reduce the benefits of the infrastructure.
· Pilot Testing
[Sidebar: “The first instance of a superior principle is always inferior to a mature instance of an inferior principle”.]
Critics of the Medical Information Infrastructure will have a field day with its pilot testing. Like many complex military systems, (three being the B-52, the M-1A2, and the CVN 78) and like many versions of software in beta testing, the system will have many hiccups and gotchas when first brought up in a pilot. Even if the program, describes above, is followed there will be technical defects. And like the critics of other complex systems, there will be many that will say the Medical Information Infrastructure will never live up to its hype or its promise. In the short term they will be correct, but wrong in the long term
[Sidebar: The Gartner Group calls this the hype-cycle, I call it the path that the way the future becomes the now.]
· Medical Culture
There are three cultural issues associated with implementing the Medical Information Infrastructure. The first is the current medical culture.
The Medical Information Infrastructure is being proposed as part of the conversion of the medical information system from the Age of Print to the Age of the Computer (as I discussed in a previous post).
As such, people brought up in the age of print have much greater difficulty in dealing with this type of change. That is true for medical personnel as well as everyone else. Consequently, they will resist any automated system.
Even in medical facilities that have automated the records management this change will be difficult. It’s like learning how to use a tablet after only using a PC.
· Insurance Culture
Insurance is the transference of the consequences of a risk (an unknown) from the customer to organization insuring. This comes at a price, the cost of insurance.
The cost of insurance is based on the probability that something bad will happen. The probability is based on statistics of how often the bad thing happens within a population. That, in turn is based on data—data that would be stored in the Medical Information Infrastructure instead of now, in a huge collection of digital and paper files spread across the country.
This means that there would much less cost in gathering and maintaining this information, but it also means that the culture of insurance selling, and adjusting would change. And as with the medical professional, cultures resist change.
· Customer Acceptance
One of the major challenges will be acceptance by the customer base. In the pilot phase, customers, not fully into the computing culture will be very anxious about the processes, where his or her records are stored, and why the change is necessary.
Additionally, the customers will be anxious about the necessary changes in law to enable this system to function effectively and cost efficiently. This stress will be hyped in the media and transmitted to congress. There is no way to stop it, but education/marketing will be able to ameliorate it to some extent.
Meeting the Issues
Meeting these cultural issues will require significant education, training, and marketing to create initial grudging acceptance.
According to Microsoft, “In today’s corporate environment, enterprise applications are complex, scalable, distributed, component-based, and mission-critical.”
