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.
No comments:
Post a Comment