Electronic Health Records Datasets From an MPI to Personal Records

Electronic Health
Records Datasets
From an MPI to personalrecords
Medical information is managed and stored by an
array of people, organizations, and databases.
S L Fritz Healthcare LLC
5/6/2010

Data Residency for EHR systems
1 © 2012 S L FritzConsulting,LLC
Contents
Patient Documents ........................................................................................................................... 3
Provider documents ......................................................................................................................... 5
Data Residency for the Enterprise ................................................................................................. 8
Future Documents and Data .........................................................................................................11
Data Residency Horizon ................................................................................................................17

By Steven L Fritz
The places where data resides, stored, once a provider enters information, depends largely on the
applications configuration and to a lesser degree the instructions of the middleware – the Extract
Transform Load (ETL) system.
All applications have a proprietary database where they put all information they originate or have
ownership of. The app has to know about the contents and structure of its own data. By
extension, the app can be instructed to distribute or pole data resident in other databases. In
either case, data finds it way out of the apps realm and into another.
Both the source and target need to be understood as well as the transport systems.
Patients
Doctors charts and printed materials
Workstations, PDA’s, Scanners and remote computers (data entry points)
LANs, WANs, Wireless, and VPN transports
Servers
Web
App
Clusters and recovery systems
ETL, HL7, EDI, BI, DW
Print Servers
Storage
Primary including Local, NAS, Cloud
Mirrored and Stripped
Backup including data, replication, incremental, and image
Transaction packaging and redundant databases
Archival
Long term storage and compression
Figure 1 - Information Sources, Targets, Transports

Patient Documents
 The beginning of the data ownership of medical information begins with the patient and extends
into the doctor’s office.
 If we zoom in on the data interaction of the patient and the doctor we’ll see the current
ownership and availability of data.
I’m a new patient and I arrive at Dr. Smith’s office with prior medical records in tow.
Alternately my prior doctor sends the records on my behalf. My provider owns the access
responsibility of documents in their possession – diagnoses, treatment plans, observations, etc.
Conversely I’m responsible for documents in my possession - orders, prescriptions, medical
records copies, insurance materials, lab results, bills, information or educational information, etc.
Let’s explore how this information does exist today and how it should exist in the distant future.
First we need to get through the present and the near future. We end up with four points in time.
There is the Past (p), the Present (P or P’), the Near Future (NF), and the Distant Future (DF).
All IT initiatives underway today are engaged in taking us from the past to the near future. If
you’re shooting for the present, you’re wasting your time. Where I invest a good deal of energy
is architecting a system for the near future while keeping my eyes on the distant future.
Example; utilizing standard HL7 constructs are preferred over highly customized EDI structures.
This helps with scalability, application migration, and future resource skill set availability in the
market place.
Figure 2 - Patient to Provider Information Exchange

Figure 3 - The Paper Record
So, in a pre EMR environment, as shown above, data, information, and knowledge is entrusted in
paper and direct personal knowledge. Use of this information is limited to direct interpretation
of the documents when developing a healthcare plan by the provider. The key word is limited.
Limited by the availability of new technology processes and constructs, not by individual
medical intelligence. My doctor has always been smart. More tools yield better care. Give me
that for the time being.
The near future is to move the medical records for physical form (at a single repository – the
ubiquitous color coded manila folders in your doctor’s office) to an electronic (digital) form. If
we do only this we have provided greater security, privacy, accessibility, and portability. If we
add the computer’s ability to look at norms for our conditions and remedies, the provider has a
great tool.
The distant future will provide the foundation, framework, for me, the patient, to take ownership
of my data, in some electronic form. Let’s not go to chips in my head but rather something like a
smart card or thumb drive, or some sort of personal storage device. Secure, indestructible,
understandable, and useable by another healthcare profession of my choosing. Let’s think
worldwide while we’re architecting the standards. Better yet let’s move the data to the cloud.
Some computer, somewhere, accessible by the chosen. This includes my data and my doctor’s
data. Now that I think about it, this could become one in the same.

As we add in the other technology components of the picture, the near and distant future will
begin to take shape. As I look at the diagram, my healthcare provider and I appear closer.
That’s a good thing.
Provider documents
The next in line of the data ownership of medical information is your health care provider. This
includes the staff at the clinic
or hospital. They make
appointments, collect
payments, enter notes,
immunization statistics, etc.
If we look closely at the data
utilization of the provider,
we’ll see the current
ownership and availability of
data. As you’d expect, all of
the medical and clerical
information about the patient
is available to the provider
and their staff. Everything
from insurance to diagnosis
to prescriptions to treatment
plans.
Figure 4 – The Cloud Record
Figure 5 - Health Records in the Practice

Figure 6 - Multiple Data Sources and Input Technologies
The use of technology ranges from a standard desktop computer that is ubiquitous in a modern
exam room to high resolution scanners to populate electronic records from hand written
materials and pre-EMR archival documents. In the past (p), as mentioned before, the use of paper
records were the predominate resource. In a fully implemented EMR environment these
materials are actually a choke point. You need to have the documents in your hand which means
only your hand. In the near future, everyone who has permission to view your records can do so.
A consultant 1000 miles away. Your doctor doing charting from home using a secure line. A
help desk nurse taking your call in the middle of the night.
For the sake of this discussion, let’s separate the origins of medical information from the use and
dissemination of the data. My main reason is that a doctor’s office, big or small, is in the
business of collection enough medical information to diagnose and treat its patients. This does
not necessarily include backing up data, setting up data flows going to insurance companies, or
organizing electronic prescription interfaces with the Walgreens down the street. Think front
office and back office.
So, as the primary originator of data, the focus becomes the input device and the type of data
being collected. The prize here is to collect searchable data. Scanning an old handwritten note is
good to preserve the document but no good to analyze what it says. The better technologies that
can be used to help in
this endeavor, the better
the usability of the data,
the better patient care.
Putting computers in the
exam rooms was a great
leap forward. Use of
voice recognition
software and digital
microphones help with
physicians who don’t
have a lot of keyboard
time. Linking
emergency room
information collected
for pulse,
temperature,
and blood
pressure added automatically to the medical records is very helpful for quality and speed.
Providing caregivers smart phones to make quick decisions help everyone stay informed while
on the move.
Unlike the paper world, the transport of information within the medical office or hospital, across
wires or through the air is vulnerable. We don’t even have to open the attack scenario for there to
be a privacy problem. Leaving an exam room with the previous patients’ information open and
visible is a problem. Send an electronic prescription to the pharmacy needs a bullet proof

Figure 7 - Movement to the Cloud
transport that gets it right every time. Using computers in radiology and attaching an image to
the right patient is critical.
No matter where the data is coming from, there needs to be an electronic means to collect it and
store it in the EMR files.
The distant future provides for any number of collection and storage options with as much
security and privacy as humanly possible. Keeping portability in mine each step of the way will
provide for as patient taking their
records to whomever they wish
to for future care without any
lapses or miscommunication of
data. The Health Insurance
Portability and Accountability
Act (HIPAA) was enacted by the
U.S. Congress in 1996. It must
stay pace with evolving
technology landscape. The year
2016 will not look anything like
1996.
When my doctor orders a lab
test, keeping a tight, closed loop
on the data is enormously
important. Physical security of
these electronic and paper
records belongs squarely with
the medical office I visit. Storage
of the actual bits and bytes may
fall to a data center located
somewhere on planet earth. My
doctor only need to ensure the
transport of my records in and
out of this center is rock solid.
For those times when the EMR is unavailable, printing of or access to critical medical
information is needed. Storing EMR files locally or on paper puts us back in the past with a 21st
century twist. Holding the records of next week’s scheduled patients must be hardened with
encryption of some sort. Last thing we want is for some person stealing a computer from a clinic
loaded with all sorts of private data. Secure the technology. Secure the transportation in-house.
Secure the import and export of information to entities outside of the four walls of the facility.
Next we’ll travel to the back-end systems that store and organize everybody’s medical records.
We will explore how my medical information helps me, the provider, and the multitude of
industries in the background.

Data Residencyfor the Enterprise
The end of the line for the medical records collected by your doctor is the enterprise database.
The eventual storage of your medical information. Small physician offices may have a footprint
as small as a minimally configured server. No matter how you look at it, there is a collection of
medical information held for the convenience of the application that assists in the clinical
practice. If we look at my original landscape for an EMR, it ends up looking like the following
diagram. All of the big-practice equipment is consolidated into fewer boxes, in this example,
one.
The use of technology in a small office only requires one computer to run the application, store
the data, and communicate specific data to insurance companies for claims and payment
purposes.
In a larger enterprise, up to the biggest, you do need all of the other systems (servers) partly to
spread the work load, and partly to help alleviate a single point of failure causing system wide
outages.
Figure 8 - The Enterprise Application at the Data Center

Let’s break down the EMR information, as mentioned previously, into the raw information
collected and edited by the care giver (input), and the data placed into the system for back office
functions like claims and insurance (output). Both are electronic (digital) versions of your
healthcare information. A third type of data is the physical printing of any of your medical
information – prescriptions, lab orders, referrals, etc. (print).
When we get to the details of how this information is used, the separation will be clearer.
If my doctor was able to provide every medical service I needed without engaging any outside
organizations, all of my medical information would reside within their walls, and subsequently
private, secure, and complete. Since this is not true, even in tightly coupled HMOs, there will
always be a need to spread information about me to outsiders. This is especially true when the
provider (doctor, care giver) is not the insurer (policy and premium management organization).
Most clinics do not house pharmacy departments. This requires some level of communication to
your drug store. A number of clinics do not have in-house laboratory departments. This requires
some level of communication to the lab in the form of an order, and from the lab in the form of
results. Many organizations are not both the insurer and provider. This requires some level of
Figure 9 - Medical Records Transactions In and Out

Figure 11 - Venn diagram of the Three Pillars of EMR Data
communications to and from the insurance company. All these examples are related directly to
you as a patient.
In the illustration above, from the center to the right, are examples of the external interfaces
required to round out your medical services. Services provided my organizations other than your
primary physical. The original data, the transportation of that data out, the target system, and
round trip, all need to be kept secure, private, identifiable (to you and only you), and accurate.
Also in the illustration above, from the center to the left, are the business and accounting aspects
of your records. Information on your insurance company, your dependents, and your amount
owed make up this portion of your Master Patient Index (MPI) file.
Care on the right and accounting on the left. Let’s add in two other important data residency
components. First, your healthcare provider has a business relationship with your insurer. This
usually encompasses payer contract data - what your physician gets paid for providing a specific
service or performing a procedure. Second is operational data. The types of care being provided
by a clinic – immunizations, worker related injuries, and the like. This provides tools to the
management on
staffing, supplies, and
reporting to regulatory
entities. Clinical
information may be
collected by mining
individual records but
in an anonymous
fashion. The use of
reporting tools within
the main application
or the implementation
of business
intelligence systems
accomplish the data
mining task.
All medical
information should be
valued and protected.
Information on how
many patients
received immunizations for the flu is worth protecting but since it does not implicate any
individual patient, it is in a different category therefore worthy of different treatment.
Finally we’ll look at what all this data and the communication pipes it travels on in the past,
Present, Near Future, and Distant Future. Having a roadmap help to guide the conversation, and
the architectural framework needed.

Future Documents and Data
So far we’ve looked at the information the patient provides and brings to the physician. We’ve
looked at the way in which the doctor creates information that is added to the master patient
index (MPI), the whole of the patient’s medical database. Lastly we looked at how the MPI is
blended with other enterprise or practice information to provide the foundation for your provider
to give you quality of care using this pool of information / data.
This view looks into the future both near and distant. To get the best value out of the current
technology we should be guided by our vision of the distant future. If we divorce ourselves from
the technology dialog and focus on the expected value to us, the patients, we’ll be positioned to
architect the information horizon we want and need.
As a patient I want and need;
1. The ability to collect medical information needed for discussions and decisions that impact
treatment and health plans, using my currently elected provider (the collection of doctors, nurses,
practitioners, and need-to-know support staff).
2. The ability to continue my care even when my primary physician is away on vacation, leave,
busy, retired, and the like.
3. The ability to share the aforementioned medical information with other professionals when
specialist or second opinions are desired. This should include only the necessity information, not
everything about me.
4. The ability to utilize foreign or emergency services and have my base medical records be
available, and, to have that external service to be properly recorded in my primary MPI.
5. The ability to move the aforementioned medical information to a newly elected healthcare
provider - change doctors. Maintain a proper continuity of care.
6. The ability to keep all of this information secure, private, and correct.
Number One
There needs to be a centralized collection of electronic medical records that is used to provide
the patient care. Simple and hopefully easy to accomplish. The future will dictate the media but
for now I’ll pick a form for illustration purposes. I have a smart card in my wallet which holds
everything about my medical history. I take my Health Records Card (HRC) to my doctor’s
office where they are granted permission to copy it into their own EMR system. Let’s call this
the Provider Records System (PRS). As data is created and collected, the PRS will be updated.
At some prearranged schedule or event, my HRC will be refreshed so my private copy is kept
up-to-date.

Figure 12 - Provider Centric EMR Storage and Ownership
The updated perspective of
the patient’s relationship
with his own EMR data is
shown below. This satisfies
objective 1. Somewhere on
the technology horizon, I
might be able to put my
smart card into my home
computer and see all of my
own history. There may be
portions that are kept from
me, the patient, but you get
the idea. Everything in one
place.
Number Two
Expanding on the diagram
above will illustrate point
two. The main authority
with permission to the
doctors PRS, is the
physician who provided me
direct health services. To
allow for others in the
medical office to give me
services we’ll need to
expand on the alternative
providers, but to providers
within the same group. This
could be a partner in your clinic, or another clinic down the street owned by the same practice.
Two, three, or many clinics under one operating umbrella.
Figure 13 - Patient Centric EMR Storage and Ownership

Figure 15 - Health Records Card Media
If a group of doctors operate two clinics, one in San Francisco and another in San Jose, they
would all populate and use a singular MPI repository – an Enterprise MPI. There is no technical
distinction between an MPI and an Enterprise MPI. It only draws a barrier between one
enterprise and another. In the illustration above, each physician has permission to access their
pool of patient data, and as granted, permission to manage other provider’s patients. This
permission can be temporary or durable depending on how the systems are set up. Another
doctor in the same office and another in the office down the street are given permission to
manage patient information. Objective 2 is accomplished with a segregate assignment without
dispersing or diluting the singular repository of the patient’s data.
Number Three
Sharing a patient’s EMR data with
people outside of the immediate
enterprise is rooted on the voice and
printed materials of the primary
physician. No electronic
mechanism (other than pre-screened
fax machines) exist to transport
diagnostic or treatment information
from one physician to another.
Some technical platform needs to be
building to provide for external
(foreign) physicians to enter electronic medical records information which eventually takes
residency in the MPI. This should include any collaborating information sources like images, lab
results, and provider treatment and visit notes.
Figure 14 - Multi Provider Data Exchange Methods

The media can take the form of links to data that resides on the individual providers EMR system
(assuming secure transports and timely accessible), or as information that resides directly in the
patients MPI just as if the primary physician has entered it themselves. If the latter, keeping the
two synchronized is not as important because one must be promotes to the position of ‘Data of
Record’ status. This represents the one authoritative record.
In the distant future, an exchange needs to be built to provide for the transportation of an HRC-
light packet. Enough data to enable the alternate physician to provide the requested services
including the return trip requirements. If the data is kept secure then the transport does not
matter (email, secure server, cloud, interface, VPN). If the transport is kept secure then the data
does not matter. I recommend both.
Number Four
The ability to utilize foreign or emergency services and have my base medical records be
available, and, to have that external service to be properly recorded in my primary MPI.
Key to the near future is the ability to give the patient their own electronic medical records via
the HRC. The alternative is to have access via old technologies to share conversations between
providers. This is impractical considering these are mainly non-scheduled visit. No advance
warning or preparation. The distant future should provide for an exchange where the data is
available to be pulled on demand. As mentioned earlier, the treatment and notes need to be
pushed back into the patients MPI. Security is the pivotal success factor for both the health
record card in the hands of the individual, and for the package of similar data that travels through
Figure 16 - Health Records, Patient, Multiple Providers, and the Cloud

the cloud. Objective 4 is accomplished on paper. The job is to build the systems and
technologies needed to enable it.
Number Five
Moving from one provider to another is a very common event in the United States. There are a
number of reasons why a person would change doctors. Considering the linkage between
employment and healthcare insurance coverage, we will continue to require a smooth, complete,
secure, and accurate movement of the contents of the MPI.
The solution is the same for a permanent migration of the data as it is with a temporary use of the
data. The near future is the first stop. The distant future should be close behind – 2 years.
Number Six
Finally is the requirement to
keep the information secure,
accurate, accessible, and
private.
When the information is held
wholly within the wall of my
provider, access is sufficient
to keep my records secure.
When that data moves to a
semi-private platform such
as is required when I visit
healthcare outside of the
network. This could be as
simple as prescriptions going
to the local drug store. It can be as complex as a review of an MPI by a consulting radiologist.
Three layers of protection can be employed. First is encryption. Scrambling the data unless a
cipher is knows. Second is the transportation that will move the EMR data. Virtual Private
Networks (VPN’s) are a common and effective tool. Third is encoding. The removal of any
information that would identify the individual patient in question. The use of Medical Record
Numbers (MRN’s) may not be sufficient as this information is too readily discovered. Some
secondary coding is required, similar to the coding implemented for people seeking AIDS
testing.
There is nothing that prevents the use of all three simultaneously. I recommend it if performance
is not adversely impacted.
When the data is housed, even for a short period of time, on a public platform, protection is most
needed. What I mean by public is the placement of the data on the outside of the enterprises
Figure 17 - Health Records Transfers; Provider to Provider

firewall. There are any number of commercial solutions like those used by the credit card
industry.
Access and audit logs can be implemented at every level of access – additions, modifications,
edits, and deletion. Deletion is actually a flag indicating the data is no longer part of normal
review of the file. The data is not actually deleted to provide for loss recovery and resurrection.
Encrypt the data, control access via passwords, network security certificates and authentications,
coding, and good old fashion physical security.
Summary
1) Transformation from current to future;
i) Move EMR data to portable devices:
(a) Secure, accurate, complete – Health Record Card HRC
(b) Create synchronization systems to ensure timely updates between HRC and
PRS
(c) The cloud could be used but security is paramount
2) Creation of new solutions;
i) Build a MPI – EMR exchange infrastructure using encryption and coding:
(a) In the form of on-line, linkable, pull systems - I come and pull data off
{Good} …or…
(b) In the form of on-line push systems - I push data to your secure system
{Better} …or…
(c) In the form of clearing houses where data is placed there for: Designated
users, periods of time, with return reply required {Best}
ii) Build extensions to records interfaces to accommodate transactions based vendors
(a) Electronic prescriptions from the provider to the pharmacy, and back
(b) Electronic lab orders from the provider to the lab, and back
(c) Electronic referrals to external healthcare providers, and back
(d) Electronic orders to durable medical equipment suppliers, w/supplies, and
back
(e) Electronic notifications to governmental, reporting, and regulatory agencies,
and back

Figure 19 - EHR Data Possession
Data ResidencyHorizon
To close the loop on where and how data is stored for EMR systems, we’ll revisit the beginning
illustration, and morph it to what the technology horizon will look like. A reachable horizon
within the coming ten years.
When I partitioned up the first data illustration, we saw that there are three distinct owners. The
Patient, the Physician, and the Enterprise. Let me rotate the diagram and illustrate it as layers of
clouds. The movement from one cloud layer to another is managed by the technology and
security parameters. The population of the
EMR data is managed by the EMR application.
If we morph one more time concerning the
EMR application, the program that collects and
displays the appropriate data, we can eliminate
it by putting it in the cloud as well. Web based
application build on a .NET framework
(browser based) provides everything required.
A browser based application is available for
me, as the patient, to see my ‘charts’ and add
notes as I see fit. As a parent I would hold
responsibility to safeguard my children’s data.
My doctor has a more powerfully configured
browser based application. His partners within
his network have another. Lastly the healthcare
provider community at large has yet another
Figure 18 - Data Ownership; Patient, Provider, Enterprise

browser based application to view and/or manage the data.
The final question left to answer is where does the formal record of my health live? It resides at
my physician’s office where is has always been. The difference is the availability of technologies
to make copies and transport that data to where it is required to give me the quality of care I
desire. If my Health Record Card gets destroyed, I only need to visit my local clinic and get a
new one. If I change doctors, I only need request the transportation of my data to my physician’s
office. If a consulting physician needs my records, he only needs to dip into or get sent my data.
The data residency eventually ends up in the cloud. The application resides next to it in the
cloud.

Table of Figures
Figure 1 - Information Sources, Targets, Transports..............................................................................2
Figure 2 - Patient to Provider Information Exchange.............................................................................3
Figure 3 - The Paper Record ................................................................................................................4
Figure 4 – The Cloud Record................................................................................................................5
Figure 5 - Health Recordsin the Practice..............................................................................................5
Figure 6 - Multiple Data Sources and Input Technologies ......................................................................6
Figure 7 - Movement to the Cloud.......................................................................................................7
Figure 8 - The Enterprise Application at the Data Center.......................................................................8
Figure 9 - Medical Records Transactions In and Out..............................................................................9
Figure 10 - The Constellation of Medical Informationfor a Patient ........................................................9
Figure 11 - Venn diagram of the Three Pillars of EMR Data..................................................................10
Figure 12 - Provider Centric EMR Storage and Ownership ...................................................................12
Figure 13 - Patient Centric EMR Storage and Ownership.....................................................................12
Figure 14 - Multi Provider Data Exchange Methods.............................................................................13
Figure 15 - Health Records Card Media..............................................................................................13
Figure 16 - Health Records, Patient, Multiple Providers, and the Cloud................................................14
Figure 17 - Health Records Transfers; Provider to Provider..................................................................15
Figure 18 - Data Ownership;Patient, Provider, Enterprise...................................................................17
Figure 19 - EHR Data Possession........................................................................................................17

Electronic Health Records Datasets From an MPI to Personal Records

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (7)

Semelhante a Electronic Health Records Datasets From an MPI to Personal Records

Semelhante a Electronic Health Records Datasets From an MPI to Personal Records (20)

Mais de Steven Fritz

Mais de Steven Fritz (8)

Último

Último (20)

Electronic Health Records Datasets From an MPI to Personal Records