ud514 »

Supplemental Material for HIT

Mark has gone to great lengths to fill the instructor's notes on many of the videos with supplemental material. Please pay close attention to those. Some general resources can be found below.

Lesson 0

Video Transcript

Welcome. This course is about health informatics — the applications of information technology to healthcare delivery. This is distinct from bioinformatics, a related field with which it is often confused, that is about building computational models and using other approaches to analyze and understand the complex intracellular biochemical mechanisms within most of our cells. The term biomedical informatics is often used to denote the merger of these two fields into one training and/or research program. As you’ll learn, even though healthcare delivery is a very data dependent activity, here in the US it has long resisted adopting the information technologies that are in common use in other industries. Partially as a result, the US has many problems delivering efficient, high quality care. Many feel that the solutions, at least in part, are through the widespread adoption and proper use of the information technologies we’ll discuss.

There are 10 lessons in the course and they correspond with the 10 chapters in the text.  We’ve split lesson 5 into two sections because of its length.  While the material is not technically difficult there is quite a lot of it.  More, in fact, than can be covered in the lectures so reading the text and other suggested materials is key to success.  Lessons 1-2 provide background on US health care delivery and the role the federal government is playing to foster adoption of information technology. Lessons 3-5 cover the core technologies that all contemporary health informatics systems and tools rely on. Lessons 6-8 show how health informatics is being used in real world applications from electronic records for providers and patients to managing the health of large populations of patients over an entire region or state to understanding and improving public health. Lessons 9-10 show how data can be aggregated from these systems and analyzed to gain new knowledge and even improve the health delivery system that generated the data. During this course we’ll hear from experts in various segments of the field who should help you see how the knowledge and concepts you’re learning about are actually being applied. Along the way you’ll be able to test your knowledge with frequent quizzing, so I want you to get used to the interaction formats. Try out an easy question to start with, QUESTION: Which of these fields involves the use of computing: a) Health Informatics b) Bioinformatics c) Both d) Neither. ANSWER: The correct answer is c) Both, they both use computing but in different ways for different purposes although these are merging as genomic data is increasingly being incorporated into medical records and practice in order to personalize care so that may not be as true in the future as it is today.

As we’ve said, healthcare Informatics serves healthcare delivery — the translation of medical knowledge into the care of actual patients. The key components of health informatics are: electronic medical records created and used by licensed professionals; patient-generated personal health records and a technology called health information exchange which can be used to share information among providers caring for the same patient; to aggregate information to create a more comprehensive and holistic electronic health record; to manage patient populations and the public health at large; and to support research of various kinds. Accomplishing this data exchange demands technologies to assure privacy and security of health data, as required by law, and other technologies to define standards so that data from diverse sources can be meaningfully combined.

In the next lesson we’ll meet Marla, a fictional character who will help me explain health care delivery and health informatics and how they interact.

You can use the course forum to interact with other students and get clarification on any points from the videos or text. It can also be a place to help find answers to questions you find difficult or where you can help others who are having trouble. As a practice example, look for a link to the forum under the Discussion heading on this page to get the answer to the following.

Each lesson in this course corresponds to a chapter from my textbook Contemporary Health Informatics. A link to purchase it at a discount is in the instructor’s notes. … I also strongly suggest you subscribe to iHealthBeat, a free, daily e-newsletter published by the California Health Foundation. Just reviewing it each day will give you a good understanding of what’s happening in healthcare and health informatics. There are also some other suggested blogs and newsletters I recommend you refer or subscribe to in order to enrich your learning experience. You can find this information in the text or in the Instructor’s Notes on this page, and it will also be collected in the course materials page. Now, let’s get started with Health IT.

Key Concepts/Vocabulary

● Healthcare ● Health Informatics ● Bioinformatics ● Discussion Forum, Instructor’s Notes, and Quizzes

Lesson 1

Video Transcript (Lessons 0 and 1)

In this lesson we’ll explore the unique characteristics of the US healthcare system with a particular emphasis on the mis-match between what its good at and its structural issues that contribute to poor management of chronic disease, the problems that account for most healthcare costs. You’ve previously met Marla, the chronic disease patient who will help us explore this. Now let’s learn more about her.

[Series of videos about Marla]

By now you should have a clear picture of the key differences between chronic and acute diseases. Unlike acute medical problems, chronic diseases are more often caused by behavior, generally can’t be cured and, particularly if not well managed, can cause other chronic diseases and complications that are difficult and expensive to treat. Now we’ll turn again with Marla’s help to what, for our purposes, is probably the key issue with respect to chronic disease — though they are very common, our healthcare system is not well designed to manage them.

[Series of videos about Marla]

So, now you understand a bit about the alternate models of care delivery, but you may be asking why this matters so much. For the answers to that we return again to Marla to explore some of the serious problems facing US healthcare. This will also set the stage for understanding the key role that health IT may play in improving our healthcare system.

[Series of videos about Marla]

So, with Marla’s help, we’ve covered some of the key problems in US healthcare and some of the principal arguments for the increased use of health IT: a.  Most healthcare is concerned with the management of chronic diseases b.  Proper management requires a highly coordinated, more continuous approach to care that welds together many providers into a seamless delivery system c.  At the center of such a patient-centered system of care is the Primary Care Physician whose role is knowing everything about their patients so they can coordinate their care d.  In practice this is very difficult to achieve because of the shortage of PCP’s here in the US and the large number of providers who are involved, particularly in the care of patients like Marla who have multiple chronic disease e.  Coordinating this requires electronic records, ideally for the providers and patients, and the seamless exchange of the information in them f.  That same information can be used to manage the health of populations of patients or the public at large g.  It can also be used for research to gain new medical knowledge and even learn how we can improve healthcare delivery

There are historical reasons why our healthcare system is the way it is and why we’ve been so slow to adopt health IT. For more on that and more details on the US healthcare system refer to Chapter 1 in the text. Now that we have the background to understand why fixing healthcare is a national priority, we’ll look at what the US federal government is doing to foster the adoption of health IT and create new financial incentives to encourage more use of patient-centered care.

Key Concepts/Vocabulary

● Rescue Care ● Acute disease ● Chronic disease ● Organisation for Economic Co-operation and Development (OECD) ● Health Maintenance Organizations (HMOs)


Lesson 2

Video Transcript

In Lesson 1 we introduced the disconnect between what is required to successfully manage the chronic diseases that drive most healthcare costs and the structure of the US healthcare system. We also suggested that health IT could be a key tool for restructuring healthcare delivery to help address these issues. We’ll review that in this lesson before turning to the policies the US federal government has adopted in recent years to encourage adoption of health information technology and new models of patient-centered care.

From an engineering perspective chronic disease care presents a data logistics problem. Here’s a more dramatic “network depiction” of the complex, highly specialist driven care of the chronic disease patients in the typical Primary Care Physician’s practice. As you k.now, the average patient with multiple chronic diseases — the 20% of Medicare patients that drive half of the costs — is seen each year by 14 providers who are mostly specialists, as shown here. In aggregate, all the multiple chronic disease patients in a typical PCP’s practice are seen by 86 providers, again mostly specialists. Keep in mind that each of those specialists mostly focuses only on the particular organ or body system they have special knowledge of and are trained to treat.  In total, the average PCP is involved with over 200 other providers.

This situation is reminiscent of the network of specialized suppliers to a manufacturing company. One makes seats, but not radiators while another makes dashboards, but not tires. But, somehow, it all needs to come together seamlessly to produce a great car. Those industries long ago recognized the need for automation to help coordinate their supplier network starting with the automobile industry in the 1980’s. Until very recently — and this only started to change as a result of the federal programs we’ll discuss in this lesson — the healthcare industry tried to operate its complex care network using paper records and fax machines.

Again, quickly reviewing because this is so key to what follows, US healthcare is highly uncoordinated because so many specialized physicians are involved in the care of patients with multiple chronic diseases. One reason is that we have a much smaller percentage — around 12% --of primary care physicians than other countries. Note that in these countries its around 50%.  The resulting problems are not theoretical. Chronic disease patients report more often being seen with incomplete or missing records the more providers they see.

Recall that the typical multiple chronic disease patient, like Marla, fills around 50 prescriptions per year because, for most chronic diseases, medications are the main therapy. Misuse of medications, including in particular duplicates because of poor care coordination, is a major problem that accounts for nearly a third of all hospitalizations.  Surveys by the Commonwealth Fund in 2008 and 2011 show progress but many patients from all countries (28% in the US) report that no provider has reviewed their medications with them in the past year. Such a review could help ensure that patients are taking only the medications they need and are taking them properly. One reason for the absence of review is that physicians may not even know the medications that other physicians have prescribed for a patient like Marla. We’ll return to it later on but this process, called medication reconciliation, is a clear opportunity for health IT once the underlying records are digita. Here is a screenshot from an actual commercial HIT system showing the medications in this physician’s EMR on the right and those out in other EMRs on the left.  The patient is taking this medication [point to it]but it isn’t in this physician’s record.

As we’ll see later on, electronic prescribing (e-Prescribing) is a key requirement of the new federal adoption programs. Because electronic prescriptions are clear and legible and an EMR can often spot potential problems as prescriptions are written, e-Prescribing has been shown to dramatically reduce medication errors within a year of being adopted. As you can see here they declined from 42.5 per 100 prescriptions to 6.6. Someday soon, hopefully, each provider will have a full medication record including whether patients are filling their prescriptions and then refilling them at the proper interval - both are currently major problems. Currently patient privacy concerns, a topic we’ll discuss in Lesson 4, are an impediment to routinely and automatically providing this information.

Since these problems have been around for a long time why are we only now getting around to solving them? One reason is the increasing incidence of chronic disease for least the two reasons shown here. People are living longer as we can see by comparing the green bars from 1999-2000 with the blue bars from only 10 years later.  Chronic disease rates increase with age. Moreover, in large part due to behavioral issues such as increasing obesity, the rates of chronic disease have increased significantly over this same relatively short period of time.

This lesson is about the policies and programs the US federal government has created to encourage the adoption of electronic records and other health IT tools and to provide incentives for their use in ways that will improve the quality and efficiency of care.  Healthcare providers have had a financial incentive to do all available tests and procedures once someone is sick and have had little or no incentive to keep their patients well. Until recently there was no incentive — except for special situations like HMOs that we discussed in Lesson 1 — to invest money in HIT systems that might actual reduce income by helping avoid unnecessary or duplicative tests and procedure. These incentives are often referred to as “pay-for-performance” or PFP. In the typical PFP system providers are rewarded for doing the tests and procedures that scientific evidence suggests are beneficial for either managing or preventing chronic disease. For diabetes, this might be an annual blood test called HbA1c that we’ll discuss later. It might also be screening their patients for obesity and smoking and counseling them to lose weight or quit.

An advanced PFP system rewards providers who are able to produce higher care quality at a lower cost. There is evidence that these programs can work. Here are key results of the Physician Group Practice or PGP demonstration, a well-known Medicare pilot in 10 practices. All of the groups achieved improvements in 25 of 27 quality metrics for the key diseases shown here. Four practices earned a bonus for outstanding performance.

Marshfield Clinic earned half of the total bonus and, in explaining how they did it, their CEO cited “a well-developed electronic health record” and went on to describe how it reduced unnecessary duplication of services by making information available to all provider caring for each patient.

Accountable Care Organizations are a key feature of the new Affordable Care Act whose design is in part derived from the PGP demo.  There are currently a few hundred ACOs being formed or in operation. 32 select Pioneer ACOs are piloting an even more advanced approach. Like the Marshfield Clinic, Pioneer ACOs must use advanced health IT to manage entire populations of chronic disease patients in a coordinated manner, to exchange data, to report on results, to engage patients and to coordinate care.

In 2004, in his State of the Union Address, President George W Bush made universal adoption of electronic records a 10 year national goal. He tasked a new Office of the National Coordinator for Health IT with achieving the goal. In 2009, the Obama administration’s Health Information Technology for Economic and Clinical Health (HITECH) act provided funding of from $20 - $30 billion (the exact amount depends on adoption levels) to reimburse hospitals and eligible providers for adopting an electronic health record system. Providers are eligible based on the amount of Medicare or Medicaid patients they manage.

The adoption program has three co-dependent components: EHR Certification, Meaningful Use, and Incentive Payments. We’ll spend the rest of this lesson understanding these in more detail. (1) EHR certification defines the minimal acceptable requirements for an EHR that, if used according to the requirements of Meaningful Use, would qualify an eligible provider for incentive payments. (2) Meaningful Use defines how eligible providers must use their certified EHR to be eligible to receive incentive payments. (3) Incentive payments from either Medicare or Medicaid compensate hospitals and eligible providers for implementing a certified EHR and achieving Meaningful Use.

Requirements for commercial EHR systems is an important development. For decades the grand challenge for health IT here in the US has been interoperability — the ability of the hundreds of commercial EMR products and tools to exchange and meaningfully share data. Even with universal adoption, without this, we can’t coordinated care among the many providers who care for the same patients. The EHR Certification process supports a basic interoperability capability.  Systems must record key demographic and clinical data, provide tools to measure and improve care quality, and protect data confidentiality, integrity and availability. We’ll now look at each of these in some detail.

Here’s a list of the kinds of data that must be collected. The reasons for some of these should be clear from our prior discussions.  Keep this list in mind as we later discuss Meaningful Use, the EHR usage requirements placed on eligible providers.

Just recording data isn’t sufficient. Certified EHRs must provide tools to use that data to improve care quality through functions like these. We earlier discussed the key role medications play in managing chronic disease and the many problems they currently create so note that the first four requirements relate directly to improved medication management. Also, note that the EHR must be able to calculate and report quality measures. Remember that as we discuss the key role that quality measures play in determining Meaningful Use.

Finally, none of this can be done legally or would be accepted unless EHRs can insure privacy so that patient data is accessible only to people to whom the patient grants access; they must also provide security from unauthorized access.  Other systems for information exchange must provide a means to establish trust — to know that the persons or entities with whom information is being exchanged are who they claim to be. The technologies to help meet these challenges will be the topic of Lesson 4.

Vendors become certified through a formal testing process developed by the National Institute of Standards and Technology (NIST) and administered by one of several companies. We’ll now take a closer look at that using one of the required items for data collection. You should recall that a certified EHR must “maintain a current problem list” but what does that mean? Medical problems are usually coded in a global data standard called the International Classification of Disease (ICD). A vendor can demonstrate that they meet this criteria by showing that their EHR can store test ICD codes and supplement them with problem status and the date diagnosed. The testing would include asking the vendor to change a problem’s status, for example from active to resolved, and demonstrating that this change is posted and displayed at appropriate places throughout their EHR.

Quality Reporting is a particularly interesting and challenging area generally done through Process and Outcome measures. While Outcome measures are usually preferable we often don’t have practical ones available. HbA1c, a test done on a blood sample can serve both as a process and an outcome measure for diabetes care. Hemoglobin, the red stuff in your blood cells, is the oxygen carrying molecule. The level of its A1c variant tracks with the amount of glucose, the molecular that is not properly regulated in diabetes, entering the red blood cells. The more glucose, the higher the A1c level but this increase occurs over time so HbA1c is proportional to the average blood glucose level over the prior couple of months. This is great since the goal of diabetes therapy is to keep that same average glucose level within normal ranges over time. As you can see here, the blood glucose level is volatile based on food that is eaten, exercise and other factors. However, it may go up and down but here the HbA1c level is remains at 7.0 indicating good control. In fact, good control is defined as a HbA1c level under 9 by many organizations but the highly regarded Mayo Clinic uses 7 as its benchmark.

The other two components of HITECH are Meaningful Use and Incentive Payments.  First, a basic overview of electronic medical records. Physicians are in the data business. They collect data, make treatment decisions based on it and follow patients through data in order to make treatment adjustments as needed. They collect subjective information from the patient including their chief complaint, their medical history and the history of the problem that brought them to the doctor including any symptoms they have observed. Physicians collect objective data by doing a physical exam and ordering images, laboratory tests or other diagnostic procedures. The resulting data may be free text, structured data such as ICD codes, continuous waveforms such as an electrocardiogram, images, sound recordings or even videos.  Moreover, data from chronic disease patients is increasingly coming from Smartphones or physiologic measurement devices to track their own health from home. Storing and presenting this rich data set is an EMR design challenge. Many EMRs simply mimic the organization of the paper chart even simulating the tabs that divide the sections where these data types are stored. Despite its key role in medicine, physicians have historically focused far more on collecting the right data than they have on recording it completely, accurately and legibly. As we’ve seen, in a fragmented system of care where many physicians treat aspects of a single patient’s care, this can lead to duplicate testing or even errors. Here’s a particularly dramatic example.

Meaningful Use is a very important and highly visible, even controversial at times, program divided into three stages that phase in over a period of years. Stage 1 is about Data Capture and Sharing, which depends on EHR Certification; Stage 2 adds Advanced Clinical Processes and is similar but more ambitious and sophisticated than Stage 1; Stage 3 aims for Improved Outcomes, which depends on more advanced EMR functionality such as clinical decision support to guide providers and tools to assist patients. Stage 3 is ambitious has recently been pushed out to at least 2017. A majority of providers and hospitals participating in Meaningful Use have achieved Stage 1 and are now focused on Stage 2, which only a small percentage have achieved at present.

We earlier discussed quality measures and now you’ll see why. Providers demonstrate that they have achieved MU Stage 1 by submitting measures in three categories: Core measures, Menu set measures, and Clinical quality measures. There are 15 mandatory core measures. Providers must also submit 5 of 10 “menu set” measures as well as six clinical quality measures. Three of these are mandatory and providers can select the other 3 from a list of 41. The core measures are divided into the four groups shown here: 1. Improve quality, safety, and efficiency, and reduce health disparities; 2.Engage patients and families; 3. Improve care coordination; and 4. privacy and security.

Menu set measures are similarly grouped, as shown here. As with the core measures, you should easily be able to see a close alignment with the coordinated management of chronic diseases along with other key priorities such as ensuring privacy and security and improved population and public health. The three mandatory clinical quality measures are screening for weight, screening for and diagnosing hypertension and preventive care and screening for smoking — all also closely related to chronic disease.

Stage 2 is similar to Stage 1 but raises the bar both quantitatively and qualitatively. It also introduces some striking requirements with respect to patient’s participation in their care. Here we see the bar going up using e-Prescribing as an example. Note the quantitative increase from 40 to 50% of e-prescriptions and the qualitative addition of checking the medication against a formulary — a list of medications usually reviewed by experts and felt to be cost effective treatments for their target condition.

I feel that no aspect of MU Stage 2 is more interesting and potentially impactful to the management of chronic disease than the requirement that “more than 5 percent of all unique patients seen by the EP during the EHR reporting period (or their authorized representatives) View, Download, or Transmit to a third party their health information”. This is referred to as VDT and ONC has released specific guidance as to what electronic patient summaries should be made available to patients under various care scenarios as described here. The first one is Transitions of Care where, for example, a patient goes from a hospital to a nursing home or back to their home.  Errors often occur at these transition points because information is not passed on completely and accurately. In Lesson 5 we’ll look in detail at the electronic clinical summary specified at transitions of care. You may wonder why providers are measured on activities actually done by their patients. Research shows that patients are far more likely to embrace electronic self care tools if their provider encourages them to do it and even provides some help in getting started. As a result of VDT many more provider practices will be offering encouragement and even the needed tools integrated with their EHR. We will return to VDT in Lesson 7 when we discuss these patient-facing tools.  Later, you’ll also obtain and use Marla’s clinical summary record in some activities.

Beyond these programs there is a clear need to change incentives that can be divided into at least three components. The first is reimbursement for the expense of the system and the second is some ongoing financial incentive to use the system properly. The Medicare and Medicaid Incentive Payments programs were designed to do the first. The Medicare payment program may do the second through penalties for providers and hospitals who don’t achieve meaningful use. It is also possible that private health insurance companies may start funneling patients to providers who have achieved meaningful use and the prospect of that is another incentive. The third needed incentive is changing reimbursement to some form of pay-for-performance, to further reward providers for improving care efficiency and quality.

The Medicare and Medicaid Incentive Payments are based on achieving the stages of Meaningful Use. The a mount providers can earn is tied to the number of Medicare patients in their practice. 30% of a practice must be in the Medicaid program 30% to qualify except for pediatricians where the threshold is 20%. The details for Medicare are shown here and you can review them if you are interested. The earlier a provider starts the more they can earn. Not shown here are the reductions in Medicare payments for providers that haven't achieved Meaningful Use by 2015. There are no penalties under the Medicaid program.

These programs have succeeded to a greater degree than many observers (including your instructor) thought possible.  As of March, 2014 more than 371,000 eligible hospitals and professionals received incentive payments for achieving at least Stage 1. This is over 90 of some 5,000 eligible hospitals and nearly 70% of the estimated 527,200 eligible professionals.

Here you see the composition of those adopters As you might expect, younger providers are more likely to adopt but the difference isn’t striking. What is striking (and has been in all prior studies) is the difficulty smaller practices have in adopting, presumably due to lack of financial as well as technical resources since many of these are in rural, poor, underserved areas. ONC funded a special Regional Extension Center program to provide special help to these providers.  Note that practice ownership can also be a significant factor.

Once they adopt, substantial majorities of providers report administrative, financial and, most importantly, clinical benefits.  Around 70% of non-surgical specialists report improved clinical communication — a key result given what you’ve learned about our fragmented approach to managing chronic disease. Another recent survey reports that, despite shortcomings in their current EHR, less than 20% of providers would revert to paper if that option was available.

Time to take a deep breath! We’ve covered a lot of territory in this lesson. We’ve learned about the core rationales for HIT adoption and deepened our understanding of the link between it and success in managing chronic disease. We’ve even seen evidence linking this success to HIT that has resulted in the federal policies to encourage adoption that occupied most of this lesson. We’ve learned that those policies are divided into three linked efforts to: 1) assure that EHRs have key capabilities; 2) that they are used in a manner that is believed will lead to improved care coordination and, ultimately, to improved outcomes; and that 3) financial incentives are there to reimburse providers and hospitals for the cost of these systems and to provide ongoing incentives to use them properly. We’ve seen that adoption levels are quite high but that survey data reveals some dissatisfaction with current EHR systems. We’ll look more deeply into why that is the case in Lesson 6 as we begin to look at real world applications of health IT in the second half of the course.

Next we delve into the technologies that power real world HIT systems. You’ve now heard of one of them — data standards — when we looked at ICD codes and their role in EHR certification. You’ve also heard hints of the importance of the other two — technologies for assuring privacy, security and trust and for supporting health information exchange. We now begin a three lesson sequence in which we’ll cover these in the reverse order to which I’ve just introduced them — beginning with health information exchange.

Key Concepts/Vocabulary

● “Pay-for-performance” ● Office of the National Coordinator for Health IT (ONC) ● EHR certification ● Meaningful Use and Its Three Stages ● Incentive payments for Medicare/Medicaid Providers ● Process and Outcome Quality Measures ● Secondary Use of Clinical Data




Lesson 3

Video Transcript

We know that the coordination of care among the many providers who care for chronic disease patients like Marla is of paramount importance in improving the quality and efficiency of healthcare. In the age of the Internet where we’re all used to information anytime and anyplace you would probably think that, once health care records are digital, exchanging them would be easy. The reality is quite different and health information exchange is another topic that illustrates the often skewed incentives within our complex healthcare system.

Beyond care coordination, health information exchange is a key tool for population health, it can become a platform for patient engagement, and it is can also be used for data aggregation for public health & other secondary uses.

Interoperability remains a major technical issue because of the multiplicity of EMRs in use here in the US. There are hundreds of certified EHRs and, although a dozen or so represent around 75% of all installations, the rest are spread among many vendors as you can see from this graphic from ONC’s dashboard, a place I recommend you visit. These systems were not designed to record data in a standard fashion or to share data with other systems, they are not interoperable. EHR certification creates a very minimal degree of interoperability. As we’ll see later on, building technologies to facilitate more extensive data sharing among them is a major focus of contemporary health IT.

A related challenge is accurate patient identification across providers and health systems. Countries like France solve this problem by issuing a special health smartcard. Here in the US a national identity number or card is a controversial political issue that is unlikely to be resolved anytime soon. So, absent one, knowing if John Smith at hospital A is the same patient as John A Smith at hospital B can be hard. Cross enterprise HIE depends on Master Patient Indexes that use sophisticated matching algorithms designed to solve this problem as accurately as possible.

Another challenge is figuring out where a specific patient’s clinical data is stored. Marla, our multiple chronic disease patient seeing many different specialists would have parts of her record scattered across many EMRs. Suppose one of them or a PCP, should she get one, want an integrated view of her care, where do you go to get the information? Special Document Locator Systems at some HIEs facilitate this type of query by indexing where a patient’s images, lab tests and other important clinical information is stored. The new Meaningful Use Stage 2 VDT requirements mean that Marla might create her own integrated record by obtaining electronic summaries from each of her providers.

HIEs are classified in different ways:: Scope (what is the geographic area they cover?), Status (Where is each HIE in the process from an idea to full functionality?), Architecture (How are the systems that support the exchange organized?), and Functionality (Of all the things that are possible, what does each HIE do?).

HIEs scope can vary substantially. An HIE can serve a single healthcare enterprise that may consist of more than one hospital, many physician practices and other entities such as a nursing home or rehabilitation facility.  These entities may have electronic medical records from different vendors so interoperability can be an issue even within a single health system. Some health systems extend their HIE to practices that refer patients to them in an effort to make that easier and thereby attract more referrals. This is often called a Service Area HIE. In an effort to better position in the health system to contract under arrangements like an ACO, it is increasingly common for them to actually acquire these outlying medical practices in which case they would definitely want them included in the enterprise HIE.

There is a clear business case for HIE in a healthcare enterprise — make it easy for physicians to refer patients to the enterprise and more convenient for patients to get all their care within it. In most business activities we assume “bigger is better” and more sustainable. With HIE the business case typically gets weaker once it expands beyond a health enterprise. As a result, for the most part, regional, statewide and nationwide HIE remains an economic as well as a technical challenge.

The second HIE classification is Status. eHealth Initiative (eHI) is a broadly based, collaborative, not-for-profit organization focused on improving healthcare quality and efficiency, including support of HIE where it tracks the status of implementations across the country.

eHI identifies the seven stages of HIE maturity shown here .(Start-up, Getting organized, Planning, Piloting, Operational, Sustainable, Innovating). Note the rapid shift toward more mature HIE’s, a positive sign of progress.

The third HIE classification is architecture. The main types are Centralized HIEs which involve a master repository of patient data; Federated HIEs where all patient data remains where it was recorded and Hybrid HIEs where clinical data is either stored locally with centralized services to help locate it or, in an alternate approach, there are “data lockers” where any centrally stored clinical data is segregated by institution and each contributing institution controls access to their data.

The Office of the National Coordinator for HIT defines a fourth way of classifying HIEs — their function. The first category is Directed Exchange used to send and receive information between providers for care coordination. Later Marla will return to help us see how this works. The second is Query-based HIE: This is data aggregation among providers. The third is Consumer-mediated: data aggregation by patients, a key concept in MU Stage 2 VDT.

The premier US example of a large scale (statewide), centralized HIE is the Indiana Health Information Exchange (IHIE). Its Indiana Network for Patient Care — a single, virtual, community-wide health record — delivers more than a million transactions per day from a data warehouse that contains five billion pieces of clinical data for some 10 million patients. Docs4Docs provides a web portal to make it easy for physicians to obtain documents like lab test results or reports on images they’ve ordered. Quality Health First is a population-based quality reporting system we’ll look at in Lesson 8. ImageZone is an image repository that allows physicians to see any image done on a patient anywhere in the exchange area from their office computer. ACO Services is the newest offering that provides tailored management tools for that environment.

Providing these services means aggregating data from many sources that are not inherently interoperable. The key component of this diagram is Data Governance, a sophisticated engine that bridges differences in data syntax and semantics across these sources to create a single database in a standardized format as though everyone was using the same electronic record system.

This screenshot from INPC illustrates that. A single patient’s data from diverse sources is presented to a provider as though it all came from a single record. It is even formatted similarly to a typical EMR. Indiana Network for Patient Care.

Other than HIEs operated by large organizations such as the Kaiser HMO or the VA health system, I couldn’t provide another example of centralized HIE at the scope and sophistication of IHIE. Why has Indiana been able to do it? A big part of the answer is the Regenstrief Foundation that supported the development of the technology and the HIE over a period of many years. Without that unusual support we might not have an IHIE to be proud of and point to.

There are a number of commercial technologies for centralized HIE. In addition, the federal government sponsored the development of CONNECT, an open source solution for centralized (or other models) of HIE. CONNECT is a very robust, complex system that uses web services to facilitate connectivity with other systems. Its architecture is modular with some elements (as indicated by the colors) being required, some being optional and others being customizable. It is also a gateway to the proposed National HIE, as shown here.

CONNECT adoption is not widespread but has been growing. You can get more information on that by visiting the CONNECT web site. Many adopters are federally supported health systems or activities such as the CDC, VA or DOD. Others are state HIEs or private entities such as the Marshfield Clinic we mentioned in Lesson 2 as the major success story from the PGP demo project.

In federated exchange all patient data typically stays at the source, facilitating provider participation but creating technical challenges. Beginning in 2010 work began on defining an HIE approach for this environment using secure email over the public Internet. The original “use case” — the scenarios around with HIT systems are developed — was replacing the fax machine as the way two physicians commonly share data. We’ll now go with Marla to her visit to Dr. Johnson to see how that might work.

You should recall that Marla has had Diabetes for 15 years and is now showing early signs of lung disease because of her smoking. Today she’s visiting Dr. Johnson, the endocrinologist who manages her Diabetes. Dr. Johnson examines her and checkes her HbA1C level and her blood sugar. He reports that her diabetes is well controlled but, when listening to her lungs, he is concerned and tells Marla he wants to send her to a pulmonary specialist, Dr. Jones, for a more careful evaluation.

As they are talking, Marla notices that Dr. Johnson is recording what they say on a new tablet computer and asks about it. He explains that he recently installed an electronic medical record system as part of a federal program. He goes on to explain that he’ll be able to use it to send an electronic record of her care to Dr. Jones so she will have it well before Marla’s scheduled visit. Marla is impressed! She doesn’t want to remind Dr. Johnson but she remembers that when she first visited him he didn’t have her records and she ended up having some blood tests she had already had in a prior visit to one of her other doctors. Marla doesn’t like needles so she’s glad this won’t happen again!

To send Marla’s record to Dr. Jones, Dr. Johnson uses the Direct service provided by their state HIE. This simplified and somewhat futuristic diagram explains how that could work. Marla’s record has a Share button. That’s not quite yet available but some EMR vendors are working on integrating Direct into their workflow so it may appear in the future. Dr. Johnson clicks it and selects Dr. Jones from a list of his usual referrals.  If needed he can lookup a new physician in a directory provided by the Direct server called a Health ISP or HISP. Here, for simplicity, we’re assuming he and Dr. Jones are using the same HISP. Before physicians are listed their identities and qualifications are verified and they are assigned a special Direct email address to establish Trust so Dr. Johnson knows the email will only go to Dr. Jones.  The form of the record can be whatever Dr. Johnson chooses. It could be a scan of a paper record or it could be a special XML-formatted patient summary specified under VDT. The record is encrypted and attached to a secure email — for security so the information can’t be viewed in transit, a key requirement for health information exchange. Privacy, was taken care of when Marla consented to sharing of her record with other physicians involved in her care. If you’ve ever signed a HIPAA release in your doctor’s waiting room, you agreed to this. Dr. Jones gets the email in her special Direct inbox and can review the record if it’s a PDF or paper scan. If it is in the special VDT XML format called a Continuity of Care Document or CCD the record could be parsed and put right into Marla’s new chart in Dr. Jones’ office, as shown here. Parsing it and merging it into an existing record is is another futuristic component of this diagram. Note that the encryption and decryption of Marla’s record is done using the Public Key Infrastructure (PKI). We’ll look at how that works in Lesson 4.

What just saw a simplified explanation of Direct. Here we see essentially the same thing but in the more likely and more complicated case where Dr. Johnson and Dr. Jones are connected to separate HISPs. S/MIME is used to encrypt the attachment containing the patient record. SMTP is used to send secure email from an email client like Microsoft Outlook. HTTPS is used for sending webmail like Googlemail. The sender’s HISP can discover (find) the recipient provider’s X.509 certificate (their public key) using the Domain Name System (DNS) or the Lightweight Directory Access Protocol (LDAP), two technologies for managing distributed resources over a network. Once it has the recipient’s public key, the HISP uses it to encrypt the message. It then uses SMTP to send the message to the recipient’s HISP (having used DNS or LDAP to find it based on the recipient’s e-mail address). The recipient’s HISP decrypts the message, using the recipient’s private key, which is normally stored in the HISP as a service to its registered providers. The = recipient then retrieves the message like any e-mail but using the secure versions of either the Post Office Protocol (POP) or Internet Message Access Protocol (IMAP) e-mail retrieval protocols (if using an e-mail client) or HTTPS (if using webmail).

Direct currently has some technical limitations.  The first is disposition notification. In certain situations it is very important to know that a Direct message has been received. Clinical laboratories, for example, are using Direct to send results back to ordering physicians. An abnormal result may require urgent attention. Confirmation of delivery is available, although currently not very robust, but it is accomplished using encrypted and signed Message Disposition Notification (MDN). Efforts to make MDN more robust are discussed in the text.

Trust among HIPSs is another challenge. Earlier we said that the HISP established trust by verifying that Drs. Johnson and Jones who were they said they are and are licensed physicians in their practice state. That’s fairly easy to do on a local basis. Suppose, however, that physicians in two states or even two regions of the country want to use Direct. They will probably be connected to different HISPs each of which established its own policies for establishing trust. Nationwide there could be hundreds of HISPs. Is each of them going to have to investigate and contract with all the others to make sure they can trust each other? That gets unwieldy fast, as shown here. DirectTrust was established to provide a solution by establishing a Trust Community. We’ll now talk with DirectTrust CEO, David Kibbe to learn more.

Another challenge is pull, automating the retrieval of data using Direct. So far we’ve only discussed the fax machine replacement use case where Dr. Johnson can send a patient chart to Dr. Jones when he refers Marla to her. Suppose Dr. Jones wanted information from Dr. Johnson? Suppose Marla has started recording her blood glucose readings at home and Dr. Johnson wants to retrieve the most recent ones to see how she’s doing? Suppose Marla has established a personal health record and wants it automatically updated whenever there is new information in any of her medical records? These are examples of Pull where the recipient, not the sender, initiates the message. Accomplishing that is still in the future but a group of experts have proposed how it might be done, as shown here, using some new standards within Direct for requesting information and sending back a response. These would be specially formatted XML documents similar to constructs that already exist in quality reporting, as we’ll see in Lesson 8. Another interesting aspect of this proposal that’s not specifically limited to Direct is that all the patient’s data would be stored in a repository that would receive and respond to these requests, presumably based on each patient’s information sharing preferences. Many people propose something like this to simplify the privacy issues we’ll discuss in Lesson 4.

The final issue is incorporating Direct into the physician’s workflow. Earlier I showed you this and mentioned the Share button as well as automated import of the data into the receiver’s EMR. These are examples of how HIT would ideally be more finely tuned to support efficient workflow. Absent them the sending physician might have to export the patient chart from their EMR, start up their email program, find the exported chart in whatever folder it was placed, attach it, address the email and send it. All of that, except for addressing the email by selecting the intended recipient, could be automated. At the receiving end a similar but essentially reverse manual process could be avoided. Moreover, were the attached patient summary in XML, as we suggested earlier, it could be parsed so that, for example, Marla’s blood pressure, pulse, heart rate, blood sugar level and so on could go into the appropriate fields in the recipient’s EMR saving more time and eliminating potential sources of transcription error.

Now that you are familiar with Direct, its time for you to get involved. Later on we’ll learn about personal health records. For now I want you to go to healthvault.com — the free, public personal health record from Microsoft — and create an account. Later on I’ll ask you to use that account in some other activities but, for now, create it by putting in your demographic information and you’ll be given a Direct email address. Click on the question mark next to it and produce a letter for your doctor explaining to them how they can use it. The letter will refer to the CCDA, CCD and CCR, three alternate formats for an electronic patient summary an EHR can produce as part of MU. You’ll learn about them in Lesson 5B. Submit that letter for credit for this activity.

Health Information Exchange is essential for care coordination, managing populations of patients, public health and research. However, there are many challenges that have proven hard to overcome, despite many years of effort. Perhaps, most importantly, it is difficult to establish a sustainable business model beyond the confines of a healthcare enterprise which has its own proprietary business reasons for supporting an HIE. There is also an inevitable trade off between functionality and cost. Centralized models like IHIE deal with data interoperability issues and can provide extensive services, but at a high cost. New, virtually free, models like Direct are not yet providing services nearly as rich as IHIE but we’ve discussed how that may be changing..

This is the first in the series of lessons on core HIE technologies. They are clearly interdependent. In discussing HIE we’ve been drawn to the issues of Privacy, Security and Trust we’ll discuss in more detail in the next lesson. I’m sure you’re curious about the details of what got sent from Dr. Johnson to Dr. Jones and you’ll learn about that in Lessons 5A and 5B.

Key Concepts/Vocabulary

●Health Information Exchange (HIE) ●Protected Health Information (PHI) ●Centralized architecture ●Federated architecture ●Hybrid architecture ●eHealth Initiative (eHI) ●CONNECT ●Health Information Systems Programme (HISP) ●Public Key Infrastructure (PKI) ●MIME, S/MIME ●LDAP ●DNA ●IMAP ●X509 Certificates



Lesson 4

Video Transcript

By now it should be clear to you that successful management of chronic diseases in our highly specialized healthcare system requires digital data that can be shared as needed to achieve truly coordinated care. However, patient-specific healthcare data is highly sensitive and is protected by a law called HIPAA which calls for severe penalties for any failures to properly secure what is called Protected Health Information or PHI. PHI is healthcare data that is linked to information that identifies the patient. You will hear the term de-identified data which refers to the same health data once it has been separated from any fields that could directly or indirectly be used to identify the patient. Everyone in healthcare is concerned about HIPAA so the topic of this lesson are the critical technologies that secure PHI and make sure it is only shared for legitimate purposes and, even for those, this sharing has been approved by the patient or their legal designee.

This sharing is not just with health providers. Patient Engagement is a key strategy for preventing and managing disease. Patients in a 2010 survey by the California Health Foundation reported that access to their data improved their care. Those using a specific tool — a personal health record (PHR) — reported they knew more about their own health, they asked their physician a question they would not otherwise have asked, they felt more connected to their physician and they did something to improve their health. However, the survey also showed that patient adoption is still low with only 1 in 14 having used a PHR and adopters are predominantly young, highly educated, higher income patients. A big part of the reason seems to be patient concerns about the privacy and security of their health data. 68% of the respondents said they are very or somewhat concerned about misuse of their digital health data. Keep in mind that all PHRs are cloud-based web tools so it is likely that any well publicized problems with data misuse on the Internet translates into patient concerns about health data being stored there. At least partially as a result, a 2012 survey showed that only 26% of patients want their medical records to be digital with 85% expressing privacy and security concerns.

Protecting sensitive health data divides into three sub areas. Privacy in healthcare means that only individuals or entities authorized by the patient may access their data. So, a patient’s record may be stored digitally in the EHR of a hospital but that doesn’t mean anyone in the hospital may access it. It can only be accessed by authorized people for specific purposes.  Security is preventing unauthorized access to the data by outsiders, such as hackers. This is a particular concern where data is being shared.  Just as with financial records, health data has value and must be protected at all times and in all places where it resides. Trust means knowing that the individual or entity with whom data is being shared is who they say they are.

Assuring privacy, security and trust is a necessity for digital patient records and sharing those records over a HIE. As a result, it is an ONC Standards and Interoperability (S&I) Framework workgroup priority area. We’ll be looking at many S&I workgroups as we proceed so its a good idea to first look at how they operate. The process is intended to be grounded in real-world issues — called Use Cases — that are first identified and then molded into a consensus document which drives the development of standards. Here’s the workflow that surrounds the use case of a provider ordering a lab test and the return of preliminary, final and then corrected results back to the ordering provider.

Privacy begins with the patient. Only they or their designee(s) can consent to the use of their health information. There are a number of models for obtaining this consent. Using data without asking for consent is the No Consent model but this isn’t reasonable or even legal in most contexts. In the Opt-out model consent is assumed unless the patient specifically revokes it. Some HIEs are using that model but it would be very unlikely and probably not even legal for a health care provider to use it. The converse is the Opt-in model where no data is shared unless the patient consents. If you’ve visited a physician you have probably consented to the use of your data under this model.  CurrentCare, the Rhode Island HIE we’ll discuss later, uses this model. Typically Opt-in is all or none so patients can’t share some, but not all, of their data. Despite this inflexibility at least one study suggests as many as 90% of patients will consent under this model. The final Opt-in with patient-specified restrictions model provides more flexibility and would probably be the preferred method, if it could be managed.

You probably agree that Opt-in with patient-specified restrictions is the most attractive privacy consent model but how do you actually manage it? How do patients indicate what data they want to share or not share? Providing a mechanism is the data segmentation problem. Suppose, for example, a patient had hypertension and depression among their medical problems. Their hypertension is not well controlled and they have undesirable side-effects from the drugs prescribed to treat it so they are interested in joining a clinical trial for a new and promising medication. They want to share the hypertension part of their data to apply for the trial but they are sensitive about their depression and wish to restrict access to it. How do they specify that? The solution is easier if someone with clinical expertise and their trust, such as their physician, does it for them but suppose the patient has their record in a PHR and wants to apply for the trial themselves. Presented with a list of their own medications they may not recognize the names or know for sure which ones are for what condition. That form of sharing would be greatly facilitated if their PHR or EMR understood these clinical relationships. A Data Model with Relationships: Figure 4.3 Here is a simple depiction of just such a record for our hypothetical patient from Dr. Jonathan Nebeker at the University of Utah and the Utah VA. Given this underlying representation of relationships, the patient could simply click on hyptertension and see the related medications greatly facilitating the opt-in with patient-specified restrictions model.

As with privacy consent, there are several data segmentation models. A completely patient-controlled model is the norm for PHRs where there is no obvious alternative other than a friend or family member who may be more familiar with medical terminology than the patient. We mentioned a provider-assisted model but that does require that busy providers spend time on the task and, even if they are willing, this may not work well if the patient’s data is, as is often the case, spread among a number of providers. There are other approaches including organization-controlled models, hybrid models, and innovative tools that are typically aimed at providing patients with more support. All of these ultimately try to simplify the complexity of the underlying clinical data which, in turn, relies on better data structures than are typically found in today’s EHR’s.

Security and Trust are interrelated, particularly with respect to the technology that is most commonly used to assure them: Public Key Infrastructure (PKI). 

PKI can be confusing. For our purposes you need to master three key concepts: (1) public and private keys, (2) the difference between the message (sensitive information) and the digital signature derived from and attached to it, and (3) the function of two key organizations.  The first organization confirms the identity of the people or entities involved in the exchange of information.  This is the registration authority or RA.  Functionally separate, although one organization could do both, is actually signing and issuing the digital certificates that are bound to that identity.  This is the certificate authority, or CA.

We’ll discuss each of these in some detail beginning with public and private keys. They are used together to facilitate the secure transfer of information and for other purposes. You can think of them simply as two numbers that are mathematically related but in a complex way. One of them is public and is freely available. The other is private and must be secured. Given the freely available public key it is prohibitively expensive and time consuming to calculate the matching private key. PKI rests on that core assumption. If you’ve ever done banking, paid bills or purchased anything on the Internet, you’ve used these keys.

Earlier in Lesson 3 we referred to PKI in Direct.. This is another highly simplified representation of Direct designed specifically to show the dual functions these keys play in security and trust. Along the top, you see that the message attachment, which can contain the protected health data in any format the sending provider chooses, is encrypted using the receiver’s public key. This is a critical point. Anyone can “discover” their intended recipient’s public key and can use it to secure information they wish to send to the owner of that key. Since only that owner should have the matching private key, only they can decrypt the data and view it. That’s the essence of PKI for security.

Now, here along the bottom, a “digital signature” is created via a calculation performed on the data being sent so it is unique to that message. It can be used for two purposes — the validate that the message was unaltered in transit and that it actually came from the purported sender. Remember the attachment was encrypted using the recipient’s public key.  The signature is encrypted using the sender’s private key. Since anyone can obtain the sender’s public key, anyone can decrypt the signature. Here people get confused. Keep two key things in mind. The digital signature is not the message, it is derived from the message. So, once decrypted, it can be used to assure that the message can be trusted - that is wasn’t altered in transit. The fact that it can be decrypted using the sender’s public key assures that it was encrypted by the sender using their private key, thus validating the source of the message. No where was the sender’s private key or the protected health data compromised. That’s the essence of PKI for trust. Most people who aren’t already familiar with PKI find this confusing so here are some questions to make sure you are clear.

So, you now know how the recipient can trust that the message actually came unaltered from it’s sender. But how do the sender and recipient each know that the other is who they say they are? Could a hacker be masquerading as a doctor in order to get access to health data and use it to file fraudulent claims? Assuring trust to prevent this is the job of the registration authority (RA). Their job isn’t particularly technically complex, it is driven by policies intended to assure that the background of people or entities is thoroughly verified before they are issued a pair of certificates. Once a registration authority has verified identity certificates can be issued. That’s the job of the certificate authority (CA).

As we said earlier, you’ve probably used PKI on the web. An example is Google Mail. This also helps explain the value of the CA. We’re using Mozilla Firefox but you can and should do the same with any browser. This lock icon adjacent to the URL of the web site indicates that its secure. Clicking on it, as we see here, indicates the site name and that the connection is encrypted. Clicking here brings up more detail including the CA, in this case Thawte, who issued the certificates. You already know that the browser can verify that by using the CA’s public key so browsers are normally shipped with those keys to use for this purpose. Remember it is a public key so anyone can have it. Finally, clicking here brings up Google’s public key showing that it is really public. The text provides more details about the key and there are references for the more technically inclined students who want to know even more.

PKI is used for many more purposes than we’ve mentioned including securing software until you’ve entered the vendor’s code indicating you’ve paid for it, securing wireless networks and digital rights management to protect movies and music. In reality PKI is more complex than described here. The validation of the certificate should be more robust, something called extended validation. To reduce the computational load there are so-called hybrid approaches that create keys just for a specific session but this is probably not sufficiently secure for healthcare. Finally, there is the concern about advances in computing. We’ve assumed that, given the public key, it is too expensive and time consuming to calculate the private key. Proposed quantum computers might change this and could lead to the need to make major modifications for encryption to remain useful.

For digital health data to help coordinate care in our highly specialized and fragmented system, it must be shared. To support population health management, public health and research, it must be aggregated for analysis. Whenever it is moving there are inevitable concerns about respecting the patient’s privacy preferences, securing it from unauthorized disclosure and knowing that the persons or entities who sent it and with whom it is being shared are who they claim to be. In this lesson we’ve gained a basic understanding of the technologies and policies required to achieve all three of these important objectives.  We’ve not yet dealt with a question that is increasingly being asked: have we gone too far with this? Are the complexities we’ve created in the interest of privacy, security and trust now standing in the way of other important objectives. For that we talk with Don Detmer, one of the best known people in health informatics and a member of the committee that wrote the landmark IOM report we discussed in Lesson 1.

So, we know know how health data is shared and how it is protected along the way. But what about the data itself? How is it represented, how is it packaged into documents, and how are those documents actually transmitted? For that we now turn to Lessons 5A and B on Data and Interoperability Standards.

Key Concepts/Vocabulary

● HIPAA ● Protected Health Information (PHI) ● De-identified health information ● Privacy ● Security ● Trust ● Personal Health Records (PHRs) ● Privacy Consent Models ● Data Segmentation ● Data Segmentation Models ● Public Key Infrastructure (PKI) ● Public and Private Keys ● Registration Authority ● Certificate Authority




Lesson 5A

Video Transcript

Data and Interoperability standards are the virtually ubiquitous plumbing that underlie all contemporary health informatics systems and tools. Given the complexity of healthcare it should not be surprising that this is a complicated topic. In fact, we’re dividing it into two lessons.  In lesson 5A we’ll focus on how health data is represented — data standards.  In Lesson 5B, on how it is packaged into documents, transported and shared — interoperability standards.

} Why do we need data standards? This simple illustration helps to make that clear using a seemingly obvious data element, the patient’s gender. It also helps explain the difference between syntax, which is structure, and semantics, which is meaning. Here, in system A, male is represented by a “1” and female by a “O”. Over here, in system B, that is reversed. Should you mix data from these two systems without some intervening “standard”, gender would be impossible to determine accurately for reporting and other purposes. We say that these two systems differ syntactically.  They may be using the same language of 1’s and 0’s but they can’t interoperate without some intermediate translation process that maps one to the other or both to some common syntax. Over in system C, “M” is used for male, and “F” for female. We say that system C differs semantically from systems A and B — it uses a different “language” to represent gender. Moreover, system C recognizes that gender may be ambiguous and represents that with a U, a concept the other two systems don’t deal with. Interoperability between system C and the other two systems would require translation from it’s syntax to theirs or translation of both syntaxes to a common form - a standard.  Since patients with gender U can’t be represented in systems A and B, some accommodation for that would also have to be made. Semantic & Syntactic Incompatibility: Figure 5.1; If something as seemingly simple and obvious as gender can lead to this much complexity, imagine what happens with concepts such as a patient’s diagnosis which is inherently somewhat subjective and can have thousands of possible values! That’s why we need data standards.

Standards have evolved over many years to encompass more aspects of medicine; to code them in more detail; and to adapt as technology changes. This can be divided into three dimensions: structure, purpose, and technology.

Early data standards were a list such as medical diagnoses, laboratory tests, or medications. We’ll refer to standard that is such a list as a Classification. More recently attention has been paid to describing more detail and even relationships among entities in a standard. We’ll refer to a standard that can code for relationships as an Ontology.

Pre-computing, all of the early standards were for data. Physicians would use ICD - a classification of diseases - in their notes. The clinical laboratory would have a classification for their tests and the pharmacy for the medications they dispensed. As computers came into use in hospitals, the various departments wanted to share information but were using their own separate specialized computer systems.CHANGE This led to the early messaging standards. These meant a physician could order a lab test or medication at the nurses’ station and that order could be routed electronically to the appropriate department to do the test or send the medication. The next evolution was standards for clinical documents. A message might typically be an order for a lab test or medication but what if you want a complete summary of a patient’s care to send to the patient’s physician, once they are discharged. This is the role of document standards. More recently, as computers have become more powerful, standards have been evolving to represent clinical processes and workflows. These have often been targeted at hospitals but have proven to be hard to develop and implement.  If this could be overcome they could, at least in theory, lead to a reduction in unnecessary variations in the way patients are cared for.

We’ve discussed the structure and purpose of standards. The final dimension is technology and this is particularly applicable to messaging standards where the messages must be constructed from data standards in a manner that they can be understood by the systems that receive them. We just discussed why — departments in a hospital want to share information with each other so, for example, an order can flow from the physician caring for a patient to the lab and the result of that test can come back. Messaging standards serve that purpose but now we’re looking at the technology in which those standards are implemented and formatted. Early messaging standards were created using EDI/X12 - itself a standard that had evolved in other industries to automate business processes such as ordering, invoicing and payment. EDI/X12 was developed in the early days of computing when memory and storage were dear so it is quite cryptic and compact, as you can see here. Note that, with some effort, we can tell that this involves a clinical lab and a Glucose test but most of the details are not obvious. In fact, to understand each specific field typically requires a reference guide. Example from the bottom of page 107. More recently messaging and document standards have been developed using XML, a more modern syntax that is verbose but has the advantages of being more human readable and easily rendered in a browser. This is the same lab test result we just looked at. Example from the middle of page 110. While it’s still not easy to read we can more easily tell that it was a blood glucose levels after 12 hours of fasting and the value was 182 and is high. We can also see what the normal ranges are for this test.

Data standards are the most widely used health standards and are a topic that is far too complex to cover in detail here. I’ll provide an overview and you should read the text and look at the many resources on the internet for more details.

The five key data standards are: International Classification of Diseases (ICD),CHANGE Current Procedural Terminology (CPT),CHANGE Logical Observation Identifiers Names and Codes (LOINC), National Drug Code (NDC), and Systematized Nomenclature for Medicine (SNOMED). ICD and CPT are very widely used because they are required in most cases for medical billing. CPT and NDC are pretty much US specific. ICD-10, LOINC and SNOMED are internationally used ontologies capable of representing clinical relationships among their elements. NDC and CPT are classifications although CPT increasingly has subcodes to provide more details about a procedure for use in billing.CHANGE

The International Classification of Disease CHANGE(ICD) is the oldest data standard dating back to the 1800’s and even to earlier centuries when researchers became interested in the causes of human mortality. Traditionally it has been a list or classification of medical diagnoses.CHANGE It is maintained by the World Health Organization (WHO); and is updated every 10 years with ICD-10, which was adopted in 1994, being the current version.  We’re still using ICD-9 here in the US even though most other countries are using 10. ICD-10 is a major expansion capable of representing many more clinical details.  We can see that here by comparing the coding system’s capabilities for breast cancer. ICD Breast Cancers from the middle of Page 114 In ICD-9 we can know what portion of the breast is affected but, surprisingly, we can’t know which breast that is. In ICD-10 laterality is represented, greatly increasing the number of codes which is a big part of the objection to using it here in the US. In fact, ICD-10 really becomes an ontology capable of representing clinical relationships, as shown here, where we can see that the patient has gout affecting their left shoulder and that they have not yet developed a uric acid deposit, called a tophus, in that shoulder. Illustration of ICD-10 Figure 5.7 The current US target date for ICD-10 adoption is 10/1/2015 and, given how close we are to ICD-11, there are proposals to skip ICD-10.

Current Procedural Terminology (CPT) is maintained and updated annually by the American Medical Association to classify all medical procedures and is required for virtually all reimbursement. CPT codes divide into three categories.  Category I codes are widely performed and are five digit numbers divided into sections for anesthesiology, surgery, radiology, pathology and laboratory medicine and medicine. Category II codes are for the collection of quality and performance metrics and are four digits followed by an “f”. Category III codes are also four digits but are followed by an “I” and are temporary to allow for new or experimental procedures. For each code there are; full, medium, and short descriptions as you can see here where a flu vaccine is described at various levels of details for different purposes. CPT 90673 Descriptions: top of page 103. Given its use in billing, a CPT code may provide details necessary to determine the proper charge. Here are codes a psychiatrist can use to indicate the length of a visit. The charge would be more for longer visits.  List from the bottom of page 100. These codes are used to indicate how much dead, damaged or infected tissue has been removed to promote healing. Removing more could result in an increased charge. List from the top of page 102. CPT codes are simple but, given their critical role in billing, and subtleties such as these, selection of the right code is important and billing personnel are extensively trained to code correctly, typically to assure that the largest, but hopefully legitimate, bill is submitted. CHANGE

Logical Observation Identifiers Names and Codes (LOINC) was developed and is maintained by the Regenstrief Institute in Indiana but is used virtually worldwide. Each code is for a laboratory test or a clinical observation and is a number with up to seven digits. While the codes themselves are deceptively simple, they contain a lot of information detailed in their names which, as shown here, are divided into 5 or 6 main parts separated by a colon. In this example of the first part-- the analyte or substance of interest — is glucose. We can see it is determined 2 hours after the patient has consumed 100 grams of glucose because the first part of the name is divided into subparts separated by a carat. Here there are two subparts, but there can be three. The first subpart, “Glucose”, could also contain multiple levels of increasing specification separated by dots. The third and fourth parts — the time aspect ( Pt means a point in time rather than a time range) and the system sample (Ser/Plas indicates that the test was performed on those components of a blood sample) — can be modified by a second subpart, again separated by a carat. This table is a more detailed explanation of each of the parts of the name.

The National Drug Code (NDC) is a US-specific standard for medications maintained by the Food and Drug Administration. As shown here, it consists of a simple 10 digit, 3 segment structure to indicate the drug, the labeler/vendor and the packaging; maintained by the US FDA.

The Systemized Nomenclature of Medicine (and SNOMED-CT, its subset for clinical medicine); began at NIH just for pathology. The original objective was machine coding of a pathologist’s free text dictated note. It was always an ontology representing relationships among its concepts. Today, its expanded to all of medicine and is maintained by the International Health Terminology Standards Development Organisation (IHTSDO). SNOMED is huge and complex. Even its SNOMED-CT subset has 311,000 concepts and 1.3 million relationships among them. Concepts are a basic component of SNOMED-CT and have clinical meaning, a unique 9 digit numeric ConceptID and a unique human-readable fully specified name (FSN). Concepts can be represented as a hierarchy based on level of detail, as shown here. Various Levels of SNOMED Clinical Detail Figure 5.8; This illustration shows a second basic component of SNOMED — Relationship Links expressed as “| is a |” and Attribute Relationships which can be a “finding site” or an “associated morphology”. Fracture of tarsal bone - middle of page 115.  The ability of SNOMED to represent medicine is illustrated here SNOMED-CT Figure 5.9 where we can see that the patient has a particular clinical condition (post-streptococcal glomerulonephritis) caused by a group A beta-hemolytic streptococcus infection and affecting the kidneys. Using the hierarchy a computer could recognize that the kidneys are a body structure and the streptococcus is an organism. This is a simple example. There are 18 Top Level Concepts in the overall SNOMED hierarchy but we’re only seeing three of them here — Body Structure, Clinical Finding and Organism.

We’ve now had an overview of how standards have evolved over the years in terms of their structure, purpose and technology. You should think about the difference between simpler classifications such as NDC, CPT and ICD prior to version 10, and a complex ontology, such as SNOMED. The standards community has been divided for decades over the choice between “perfection” - a standard that can represent medicine in all its detail and “practicality” - standards that can actually be deployed and used in the real world. We’ll look at this more specifically in Lesson 6 when we review EMR design challenges.

We’ll be looking at messaging and document standards next but both of these rest on the data standards we’ve discussed. To see that go to the URL in the instructor notes. It will take you to the HealhtVault developer site to access a sample of a CCD patient summary. Find the Problems section and use it to answer the following questions. Note that the problems are first presented in an easily human readable text and in a table format that could readily be viewed as part of a web page. It is followed by the same problems wrapped in a considerable amount of data standards nomenclature. Each of these begins with “<entry typecode="DRIV">” and ends with “</entry>”. Study what’s between these to see how complex HL7 has become.

So, we know know how health data is represented and we’ve had an introduction to how it is packaged into documents. We will explore that in more detail in the next lesson.

Key Concepts/Vocabulary

● Interoperability ● Semantics and Syntactics ● International Classification of Disease (ICD) ● Current Procedural Terminology (CPT) ● Logical Observation Identifiers Names and Codes (LOINC) ● National Drug Code (NDC) ● Systemized Nomenclature for Medicine (SNOMED) ● Electronic Data Interchange (EDI) ● Extensible Markup Language (XML)


Lesson 5B

Video Transcript

In the last lesson we looked at the evolution of standards and examined data standards in particular. To be maximally useful in care coordination this standardized data, typically along with other non-standardized data such as free text notes, must be packaged into standardized clinical documents and sent using standardized messaging formats. We’ll look at both of these in this lesson.

Hospital health IT systems came into widespread use in the late 1970’s and 80’s. There were some early attempts to provide a single-vendor, fully integrated hospital wide solution,but most systems were developed for a particular department — such as pharmacy, clinical lab or radiology-- and it was common for each of these to select their system. As a result hospitals were faced with the problem of communicating among these systems so, for example, patients could be uniformly registered in them and charges could be reliably collected from them. Health Level Seven (HL7) evolved to create these messaging standards.

It used EDI/X12 to format the messages. Its latest version - 3 - migrates to XML which, as we discussed earlier, is a technology developed for the Internet in which tags and HTML formats are used to describe data elements within web pages. While it is more verbose, memory and disk space are now very inexpensive. It is more human readable and, of course, still machine readable and is easily rendered in a browser. Here’s an example of an HL7 v2 EDI/X12 formatted message — a lab test result as it might be sent back to the ordering physician. The OBX line is the most interesting part since it contains the test results. EDI/X12 Lab Test Result: Figure 5.x. Any idea what 1554-5 is? What about, ^182|mg/dl|70_105|H? XML Lab Test Result: Figure 5.x Here’s the same message in XML. While it’s not as obvious as something designed just for human reading, it is much clearer that 1554-5 is a LOINC code (abbreviated as LN) for the lab test and that 70-150 is the normal range and that, at least by inference, 182 is the result for this patient so H must mean the result is high.

Over many years HL7 has expanded greatly from its original messaging mission. Some would now argue that it’s become overly complex and virtually impossible to fully implement. In what follows I’ll give you an overview of many of the key components of HL7 with a particular emphasis on those that are key to data sharing for care coordination and patient engagement.

Traditionally, the standards community often seeks standards for everything so it should not be surprising that there is an HL7 standard for developing HL7 standards! It is called the HL7 Development Framework of HDF and is diagrammatically shown here. For the purposes of this overview course it should be sufficient to know it exists and to be familiar with these linked circles showing the key standards development processes.

Earlier we discussed syntax and semantics and said that syntax is structure while semantics is meaning. The HL7 Reference Implementation Model or RIM defines the semantics of a common set of administrative, financial and clinical concepts in order to foster interoperability. It consists of five abstract concepts: Every happening is an Act. Examples include procedures, observations and medications. Acts are connected through an Act relationship such as composition, preconditions, revisions and support.CHANGE Participation defines the context for an Act author, performer, subject, location. The participants have Roles such as patient, provider, practitioner, specimen or healthcare facility. Roles are played by Entities such as persons, organizations, material, places or devices.

Some of these are shown in this small part of an HL7 RIM example. Each of these can be further specified in great detail but finding the explanations can be tedious. The FHIR resources site is the best source of explanations I’m aware of but it is intentionally not complete. To get a feel for this lets focus on the specialArrangementCode in the Patient Encounter box. We see here that this is a leaf of the Act box meaning it is a particular example or instance. I picked it because most of the detail names are self evident so you can easily see the level of detail that is specified. Here we see DSET which indicates is a discrete set of possible values for this field. In fact, they are “wheel” for wheelchair, “stret” for stretcher, ”int” for interpreter, “att” for attendant and “dog” for guide dog. Here’s another detailed example where SBADM means “substance administration” and RQO means a “request, typically part of a medication order by a physician.

Before leaving RIM and moving on to some of the things it is used for it is important to emphasize again that the goal is interoperability and, in support of that, RIM can be used both for HL7 v3 messages and for clinical documents constructed, at least in part, from the data in them.  This was a key goal of the effort.

The Clinical Document Architecture or CDA defined HL7 v3 RIM-based documents assembled from administrative and clinical data for particular purposes. After a period of use a consolidation effort removed inconsistencies resulting in the current Consolidated CDA or CCDA. Here’s a simple example of some patient demographic data we’ll use to show how RIM supports CCDA documents. CCDA Based on RIM Data Model: Figure 5.x; Here’s this same patient depicted in a RIM Role. You can see the same information highlighted in the XML. Same Data Depicted as a Role: Figure 5.x; Here is the data incorporated into a CCDA document XML from the Corresponding CCD: Figure 5.x. In this case it is a Continuity of Care Document or CCD, a key electronic document for exchange among providers at transitions of care when, for example, patients are admitted to or discharged from a hospital or referred by a primary care physician to a specialist. Transitions of care are a key risk point so exchanging data at them is an important means of assuring quality and safety.

CCDA documents are assembled from templates which are essentially reusable XML components. Templates are constructed at the document, section and data entry level. These correspond conceptually to the parts of a paper form where the document as a whole consists of sections each of which consists of fields where specific data items can be recorded. Here is a document example. Within it are sections and within those data elements, in this example a text-based clinical observation and a substance/medication administration which might well be coded, and an unspecified external observation that could potentially even be physiologic data collected by the patient on their Smartphone.

Here’s an example of a CCDA section-level template.  Note that it has a template ID (templateId root). Copy it and go to this URL to find the name of this template.

The number you just searched for is an example of an OID. An OID is a globally unique ISO (International Organization for Standardization) identifier. These are not healthcare specific and are used to uniquely identify a diverse set of objects or other entities.

The data entries within the sections of a CCDA document are also formatted using templates to assure consistency. Here’s an example.

Earlier we mentioned the key role that the CCD plays at transitions of care. We saw this screen shot from an actual commercial health IT system in an earlier lesson.  Now you know that it does medication reconciliation by comparing the medication section of a CCD from another EHR (on the left) with the medications recorded in the patient’s record in their physician’s EHR (on the right). This is a dramatic example of the power of standards incorporated into electronic clinical documents as a tool to improve care.

We’ve now seen the widely used HL7 standards in action.  You now know what was in that document Dr. Johnson sent to Dr. Jones back in Lesson 3.  In the next Lesson you’ll obtain a copy and do some activities with it.  First, we’ll look at some advanced HL7 standards initiatives that point the way toward the future and may help deal with many of the limitations of current non-interoperable systems and the usability issues of EMRs.

The goal of the Arden Syntax is a standard approach to describing medical logic so that it can be shared across EMRs to support Clinical Decision Support (CDS). CDS is the idea that computers can suggest optimal therapy based on a patient’s electronic record or spot potential mistakes before they happen. To do either they not only need the electronic record, they need to understand at least a limited domain of medicine. That’s where Arden comes in. Arden consists of Medical Logic Modules (MLMs) each of which supports one clinical decision. Here a group of five MLMs are used to help provide CDS for the use of warfarin, a common but potentially dangerous blood thinner often given to patients with strokes or potential blood clotting problems. Too little of the drug may mean another stroke. Too much can cause excessive and even fatal bleeding. Warfarin control can be affected by many other drugs and even the patient’s diet, so it is a tricky drug to manage. A clinical test called a PT/INR is used to assess the degree of blood thinning. You can see here that the modules — once they are fed clinical data about the patient such as their PT/INR — can make warfarin dosage recommendations to the physician. Arden Warfarin Flowchart: Figure 5.17 I refer you to the text for the internal details of the Arden MLMs.

Arden was developed at Columbia University with support from IBM with the idea that centers of excellence could develop MLMs and share them with other institutions. However, there are a number of technical challenges to actually deploying Arden with the curly braces problem being the one we’ll briefly discuss here.

This part of an MLM helps with a radiologic study that involves injecting the patient with a contrast dye to better see the functioning of parts of their internal organs. It deals with a lab test — the creatinine level — which measures kidney function. This is important because the dye used in the study is removed by the kidneys and it can also cause kidney damage so it is important to know that the patient’s kidney functionbefore giving it. To check for that Arden needs to know the creatinine level and, to get it, {‘dam’="PDQRES2"}; must be interpreted by the EHR in a particular hospital to fetch that value from its proprietary database. So, even though the purpose of Arden is to share CDS, because EHRs aren’t readily interoperable, we run into roadblocks like this and that has led to low Arden adoption. Health eDecisions was a nearly two year long standards effort sponsored by ONC and now folded into a broader Clinical Quality Framework (CQF).  It proposed using parts of the Arden technology along with web services designed to make fetching data like this much easier.

The Clinical Information Modeling Initiative (CIMI) is an attempt to enumerate the detailed models of hundreds to thousands of medical ideas to achieve consensus among clinicians. They could be used to define standard messages or structured documents, as components of clinical rules, and to automate or facilitate constructing data entry or reporting templates. The CIMI group lists simplification of existing models (perhaps referring to RIM) as one of its key goals.

The Context Management Specification (CMS) began at Duke University as the Clinical Context Object Workgroup (CCOW). It seeks to facilitate the integration of diverse applications at the point of use. It does this by managing issues such as: a.  The identity of a patient whose data the user wants to view or update via the applications. b.  The identity of the user who wants to access the applications. c.  A moment in time around which temporal data displays should be centered by the applications. d.  A particular patient encounter that the user wants to review via the applications.

The details are highly technical but you can get the general idea from this illustration where several applications from different vendors are all centered about the same patient for the clinician. This is an ambitious but potentially very important effort since clinicians commonly complain about the time and effort involved to use many different systems that work in different ways to manage their patients.

In a seminal March, 2011 blog post The Rise and Fall of HL7 Australian standards guru Graham Grieve said that “Complicated standards can be pushed for a while but ultimately markets reject them.” He then goes on to essentially say that RIM is doomed because it is too complex, no single model will work in all domains, it’s internally inconsistent, which is often true of extremely complex constructs and, ultimately, its too expensive to implement. He pointed to JSON web services. JSON (JavaScript Object Notation) is a lightweight data-interchange format that is easy for humans to read and write. It is also easy for machines to parse and generate. The result, some three years later, is Fast Health Interoperable Resources (FHIR).

FHIR solutions are built from a set of modular components called “Resources”. The FHIR resources are a subset of RIM — essentially the most important, commonly used data constructs — organized and categorized as shown here.  I suggest you visit the Resources section of the FHIR website to further explore this key element of FHIR. These resources can easily be assembled into working systems that more quickly and easily solve real world clinical and administrative problems. FHIR is suitable for use in a wide variety of contexts, as shown here. These might include mobile phone apps, cloud communications, EHR-based data sharing, server communication in large institutional healthcare providers, and other environments. The key is the use of FHIR resource tags in the underlying data structures. The interaction between the systems and the database is via RESTful APIs, which are relatively easy and fast to implement facilitating innovation and development. As we discussed earlier, a similar web services approach was specified by Health eDecisions. The web services paradigm is increasingly seen as the best vehicle for developing and more rapidly deploying interoperability solutions and even analytic routines and services such as those required for CDS. This is an important trend that I strongly encourage you to follow over time. PAUSE To help you get started we’ll now talk to FHIR founder, Graham Grieve.  PAUSE Harvard’s Josh Mandel is a physician and computer scientist and lead architect for the SMART Platforms team.  He’s recently adopted FHIR and we’ll now talk with him about that. 

We’ve now completed our review of data and interoperability standards. This is an immense area and we’ve only skimmed the surface in an effort to equip you with a working knowledge of the areas being standardized, the approaches and technologies being used and the potential benefits. You should recognize that, for the most part, health informatics standards have been developed within the industry and have only recently begun to adopt approaches such as XML and web services. You should also appreciate the inevitable tension that exists between the need many feel to create very detailed standards for everything and the complexity that creates. Often this complexity gets in the way of the real objective which is implementation and use of the standards in day to day patient care and the increasingly recognition of that seems to be leading to a new willingness to look outside of healthcare and to adopt more facile and easy to implement approaches such as FHIR.

We’ve also now completed our discussion of the core technologies of health IT and, with that knowledge, we’re ready to see how HIT is being used in the real world. We’ll begin with what is still a very challenging endeavor even after decades of effort - the development of practical, efficient and easy-to-use electronic medical record systems.

Key Concepts/Vocabulary

● Health Level 7 (HL7) ○ RIM ○ HDF ● Electronic Data Interchange (EDI) ● Extensible Markup Language (XML) ● Clinical Document Architecture (CDA) ● Consolidated CDA (CCDA) ● Templates ● Clinical Information Modeling Initiative (CIMI) ● Clinical Context Object Workshop (CCOW) ● Context Management Specification (CMS) ● Clinical Decision Support ● The Arden Syntax ● FHIR




Lesson 6

Video Transcript

This lesson is about the critical role that data plays in the practice of medicine, the benefits of introducing digital records into that process and two key challenges in trying to do that: efficiently and accurately collect high quality, comprehensive clinical data from busy and often computer-averse providers and visualizing EHR data in a way that supports the provider’s mental model in order to improve the quality of care.

As we discussed briefly in Lesson 2, physicians are in the Data Business. They collect data, analyze that data, make decisions based on it and follow up using still more data so they can make adjustments as needed. Despite this, medical records and record keeping often receive minimal attention in medical training and most medical schools offer no training in health informatics beyond learning to use whatever electronic record systems are deployed in their hospitals and clinics.

Physicians usually start collecting data by interviewing the patient beginning with the chief complaint, the reason for the current encounter. They ask about other problems and obtain the history of those problems. To further explore the chief complaint, they ask about symptoms and they physically examine the patient.

Based on this they make a preliminary diagnosis, if possible, and order laboratory, imaging, and other tests to obtain as much objective data as possible. CHANGE From this aggregated database of subjective and objective data, they assign the patient with one or more diagnoses; and develop a plan for managing them that usually involves prescribing medications. CHANGE In subsequent visits, they follow up and make adjustments. The treatment plan may involve referral to specialists, requiring coordination with providers working at different care venues and possibly in different communities and health systems.

Research has shown that this process is subject to at least three common sources of error (transition to tablet) 1) An Incomplete Knowledge Base - the physician can’t know everything given the rapidly increasing storehouse of medical research and knowledge, CHANGE 2) An Error in Perception or Judgment - physicians are still human and are subject to human error, and CHANGE 3) A Lapse in Attention - physicians are also very busy and may not focus sufficiently on each case.

Way back in Lesson 1 we reviewed some of the problems of US healthcare. Too many errors is another. In its landmark 1999 publication “To Err is Human: Building a Safer Health System” the IOM famously said that from 44 -98,000 Americans are killed each year in US hospitals due to entirely preventable reasons. Many of those listed, such as adverse drug events, improper transfusions, wrong-site surgery and mistaken patient identities, have to do with mis-handling of data. This leads to one of the key arguments for adoption of electronic medical records. However, electronic records themselves can be a new source of errors. We will turn to that now. First we need to acknowledge the magnitude of the challenge.

If you think back to Lesson 5 you’ll recall how large and complex the data standards are. That isn’t arbitrary — human anatomy, physiology and disease is that complex. To be accurate, an electronic record must be able to capture the nuances of care. To be maximally useful, it would ideally capture most of this as structured, coded information. How do you do that? How can you provide busy physicians with a way to accurately and efficiently capture such a complex dataset? That’s the EHR data capture challenge and its been with us for decades. The most common approach is this, a template — essentially an electronic version of the paper check off forms physicians have used for years in their practices.

Where the list of choices is long, as illustrated here, it is far too easy to pick the wrong one. This is termed an “active error” — the entry of inaccurate information. It’s one of the seven common sources of EHR data entry errors cites at the Fifth Annual MIT Information Quality Industry Symposium.

Another, source of error are incorrect system defaults. This can occur in at least two ways. . A particular EHR could have been setup to default to a particular value and the provider may overlook that while charting. Another, and far more insidious, possibility is that they EHR “remembers” the values from a patient’s prior visit to save the physician time in charting this one. The obvious potential error is to document what may have been correct last time but is wrong this time. Another source of error derives from the desire to save the provider time by fitting as much as possible onto each data entry screen. This can lead to a cluttered and/or illogical layout that can cause information to be overlooked.

The next source of error — inconsistent data across locations — should not come as a surprise. This is the interoperability issue we’ve been discussing throughout the course. Where multiple physicians are involved it can be further compounded by differences in the way they document even the same clinical issues, particularly where text entry is involved. For example, they might use different terms for the same thing or non-standard abbreviations or acronyms. Similarly, physicians may not record all the needed data leading to potential misinterpretations of the past history or even the current treatments. Finally, where multiple locations are involved in a patient’s care, it may not be clear which of several observations/events is definitive or even the most up-to-date.

So, the challenge should be clear. Physicians are busy. Their work depends on data taken from a huge and complex set of possible values. They have little, if any, training informatics. EMRs could be better.  Isn’t it possible to innovate and offer approaches to the computer-physician interface that are more imaginative and ultimately more successful than mimicking the paper tools that have been used for decades. We turn to that now.

Back in the 1970’s when I was involved in developing an early EMR the data collection problem was already clear. In fact, for the most part, our physicians dictated notes and they were transcribed into the EMR. I used to tell visitors that “some day” voice recognition would make this far more efficient and accurate. Has that day arrived? To answer that question we’ll look at M*Modal, one of the most advanced medically specific voice recognition technologies. As shown here, it not only translates voice to text but it recognizes clinical concepts in that text and codes them. For example, 346.9 is the ICD9 codes for migraine headaches while 62972009 is the SNOMED-CT code for an extraction. This is very impressive but not yet perfect, at least in this example which is a few years old, because there is a SNOMED-CT code that is specific for a wisdom tooth extraction.

This illustration really shows the potential for advanced computing in medicine. To understand that we’ll now talk to M*Modal founder and Chief Scientist, Dr. Juergen Fritsch.

As impressive as it is, M*Modal is a tool, it isn’t an EMR. Once the company felt it was ready, they offered to integrate it into commercial EMRs and the first to do that was PrimeSuite from Greenway Medical Technologies. As you can see here, the voice recognition is built into the software physicians use and becomes an option for data entry in a number of clinical contexts.

The introduction of machine learning as an EMR technology is, I think, potentially a key development. If EMRs are to adapt to physicians they must have some understanding of what they do. To explore that further we’ll now turn to a second commercial EMR, Praxis by Infor*Med Corporation. Praxis: Figure 6.2 Praxis uses machine learning and each physician user trains it as they see the common problems in their practice which it identifies based on the physician’s entry of the clinical finding most specific to each problem. Over time Praxis learns how that physician usually treats each problem and, as shown here, presents a note based on the most similar past patient(s). Each phrase is what Praxis calls a “clinical concept” but these are not encoded into SNOMED-CT or any data standard, they are text descriptions as defined by each physician. To avoid the erroneous default value problem we discussed earlier, the physician must click on each clinical concept to confirm and/or edit it.

So, do physicians actually prefer EMRs with innovative approaches to data collection. This 2009 survey data from the AAFP suggests the answer is yes. Here physician choices are analyzed based on practice size. It’s important to recognize that smaller practices tend to independently make these decisions while larger practices tend to have employed physicians and/or to be aligned with a health system that often makes an enterprise EHR choice for them. Grouped by practice size, the choices are quite different. While I don’t want to generalize, based on my own direct observations of the systems at the top of this graph, the physicians that chose EMRs on their own do, in fact, pick more innovative or well designed solutions to data collection like we’ve been discussing.

The second major EMR challenge comes after the data is collected. How do you present it to physicians in a way that supports what an important National Research Committee report referred to as “their mental model”?

Earlier, in the discussion of data segmentation in Lesson 4, we looked at a design proposal from Dr. Jonathan Nebeker to illustrate the added power that comes when software understands clinical relationships. Here’s another illustration from the lab of my Georgia Tech colleague, Dr. John Stasko. His Jigsaw text analysis tool shows the strength of the relationships between the staging of prostate cancers and the specific medications and other treatments used by their physicians.

So, equipped with more powerful knowledge of clinical relationships like these, how might EMRs better support the physician’s mental model. This is really an unsolved problem but we’ll look at some key concepts that might help lead to solutions. They all point to one major deficiency in most EMRs — they don’t really distinguish among fairly obvious differences in the way they are used.

Here’s Marla. We already know her story — many chronic diseases leading to many medications and many encounters with the healthcare system. Her chart is large and complex and, should she visit her PCP, they would need a quick overview of it to adequately plan the visit and her comprehensive care. Her friend Doris, on the left, works out regularly and rarely goes to her physician. Today she’s visiting because she overdid things a bit and sprained her right knee. Doris’s chart is thin and there is really not much else for her PCP to be concerned with other than any routine preventative care that might be due.

Now, remember that Marla actually receives most of her care from specialists. Each of them is focused on the one organ or body system they care for. Remember Dr. Johnson, the endocrinologist who cares for Marla’s diabetes and Dr. Jones, the lung specialist to which she was referred? Each of them will probably be interested in different data from Marla’s very large chart. This would include subjective information Marla has provided and objective information from her prior physical exams, lab test or other studies. Each of them will prescribe medications and other treatments that are specific to the disease they are managing. Current EMRs don’t understand this and don’t automatically make these distinctions.

We conclude with some of the seven information-intensive aspects of the IOM’s vision for 21st century health care. While these are certainly not limited to the data visualization challenge nor will they be solved just through it, they align well with what we’ve discussed and their solutions certainly require improved EMR visualization capabilities.

The IOM calls for EMRs to store Comprehensive Patient Data and to use it to provide Cognitive Support for Providers and Patients Aspects of this are integration of patient-specific data where possible in order to personalize care, the integration of evidence-based guidelines to improve outcomes, reduce costs and enhance the safety of care and the rapid integration of new knowledge and technology into clinical practice.

The IOM also goes on to advocate for both practice-wide and population level care management, something that significantly scales up the data to be managed and a clear opportunity for innovative visualizations of the kind we’ll see in Lesson 8.

The IOM specifically calls for recognizing the home as a new care setting, which aligns with more use of home-based technologies for monitoring and treatment, and the use of the information technologies we’ll discuss in Lesson 7 such as personal health records to promote engagement and communication with health professionals.

We’ve now looked at the two central challenges facing EMR designers and have considered some innovative approaches, particularly to the data collection challenge. There is some additional material in the text about visualization I would suggest you review. In particular, view the medication reconciliation video from Dr. Schneiderman’s group at the University of Maryland.

Now that we’ve considered the principal challenges of medical record system for providers, we move on to informatics tools for patients.

Key Concepts/Vocabulary





Lesson 7

Video Transcript

Years ago, my professor told me that, as a practicing physician, I would probably see patients for a few minutes every few months and think that what I did then would make all the difference. In fact, he said, it was what those patients did between the visits that would make that difference. Today, we have a rich set of technologies and tools to empower patients to be more involved in maintaining their own wellness, preventing disease and managing disease more effectively should they develop it. Understanding these new technologies and the patient’s point-of-view is the subject of this lesson.

You’re already familiar with what may well be the key tool for patients — the personal health record or PHR. While the exact form of a PHR is evolving, the central ideas for a long time have been that it is patient controlled, patient records data that can become part of their electronic health record, patient controls access to their data, and it is a lifelong record.

In this Lesson we’ll use Microsoft’s HealthVault but there are several widely used PHRs and they mostly do the same things. You should already have a HV account but we haven’t yet explored it to see how it stores clinical data and what it can do to help patients use that data including sharing it with others. So, here’s some of my health data I manually input into HealthVault. You can see key data such as allergies, medical problems, medications and weight, blood pressure and so on. As shown here, users are aided in recording these by smart lists that appear as they type. Problem More recently, as Meaningful Use has dictated the export of at least standardized clinical summaries, the burden on the patient to record all their data is largely alleviated and the PHR can and should import these summaries from all providers caring for that patient. Note here that I now have a Direct email address. 

With the growth of the wireless Internet and mobile devices the PHR is now accessible anytime/anywhere and it can upload data from physiologic monitoring devices, Smartphone sensors and apps and other sources. You can see a few of them here.  Note that there are actually 224 of these at present.

Information Up until now you’ve been seen a limited range of the data that can be stored. These is actually a lot more and you can see some of it here.  I want to focus now on this item — the Continuity of Care Document or CCD. You should know what this is from Lesson 5. By clicking here a patient can upload their CCD into HealthVault once they have it, something you’re going to do yourself in the next class exercise.

You should recall that when we last saw Marla in Lesson 5B she was seeing her new pulmonary specialist, Dr. Jones, who received Marla’s XML-formatted CCD using Direct.  Under Meaningful Use Stage 2’s VDT mandate, Drs. Johnson and Jones, and all of Marla’s other physicians, are encouraged to provide electronic access to these clinical summaries to their patients so Marla is able to access that information and once she has it she can do what I just showed you and load it into HealthVault.

Marla’s given us permission to provide you with her CCD. Since she is fictional, this is not protected health information so you can have and freely use it. For this activity you should send this CCD as an attachment and email it to your HV Direct email address at (https://www.healthvault-ppe.com/us/en). First, go to your Message Center settings and make sure “Add incoming message attachments as files” is checked so the data in Marla’s CCD will be added to your record. Once that’s done,, manually add the medication “Spiriva” (spell it) to Marla’s record.  This is a drug Dr. Jones might prescribe to help her breathe better.  Also, manually add a new HbA1C level of 9.2%. You can date them both the day you add them. Now, go to Health Information and click More Actions and export Marla’s record as a CCD. You’ll need to email it in to get credit for this activity.

Beyond PHRs there are many other technologies and ideas about how to engage and empower patients. We’ll turn now to one of the most prominent - PatientsLikeMe, a social networking site on steroids for patients who have a serious medical conditions.

Before PHRs and sites like PatientsLikeMe, hospitals and physicians were able to establish “portals”, essentially web sites where their patients could do some of the things we discussed under personal health records. The first of these is now part of RelayHealth, itself a part of McKesson Technology Solutions for healthcare. They can get lab test results, request or even make appointments. They can securely communicate with their physicians even using Direct. They can also pay their bills, something not seen on PHR sites which emphasizes the key difference. Portals are provided to the patient while PHRs are generally patient-initiated and operated.  Importantly, as you can see here, patients can download their health data — in this case using Blue Button + a technology we’ve not mentioned previously that is intended for just this purpose and one that is getting a lot of attention because of the VDT requirements of MU 2.

Blue Button began in the VA in 2010 and was adopted by ONC in 2012. Their S&I workgroup expanded the standard, added more structure and dealt with Direct integration to create BB+. This graphic from the Blue Button + site shows how it can be used in conjunction with Direct to move the data from a provider’s EHR to the patient’s PHR. This one shows that BB+ can be used to bring data from multiple providers into one patient-managed technology such as a PHR. The data itself is in an XML document formatted according to CCDA. You should recall that CCDA documents are constructed from templates for the document, its sections and the actual data entries. Here’s a list of some of the sections of the BB+ CCDA.  More recently the Blue Button REST API effort is offering a RESTful API approach to using Blue Button + for both it’s traditional role — Push — where providers send the files to patients or their designated PHR/app as well as Pull where patients can, in effect, subscribe and receive updates as new data comes into their provider’s EHR. We’ll talk now to Josh Mandel from Harvard about Growthtastic!, his demonstration app for a push approach.

In our exploration of HV we saw that patients could upload data from a large number of devices. This is, of course, increasingly possible, inexpensive and convenient with embedded Smartphone motion and other sensors being the latest technologies.

You may be surprised to learn that collecting data in the home to help with care is actually quite an old idea. Here’s a photo of Steve Kaufman, one of the earliest innovators in this space, with his Home Assisted Nursing Care (HANC) robot that offered a wide variety of voice-controlled nursing services to patients at home in the mid-1990s. Among other things it dispensed medications at the proper time and took physiological measurements with the patient-operated devices of the day.

We’ll refer to this field as telehomecare but that implies a more passive role for the patient than is appropriate and technologically possible today.

In fact, as we’ve seen with HV, patients can initiate their own data collection program and even send the results as a CCD to their physician. Medicine has often not yet caught up with this reality and patient’s are often unaware of it but it will, in time, particularly as incentives foster an alignment between the increasing independent capabilities of patients and the need of providers to deliver more cost effective care. This, of course, closely parallels what has already happened in other domains such as financial services, travel and shopping where consumers have assumed many of the roles previously played by service or product providers.

Since HANC numerous commercial packaged telehomecare systems (including one that I was involved in developing) have sought to assist patients in recording subjective data about aspects of care including their symptoms, activity level and compliance with their treatment plan as well as objective data such as weight, blood pressure, pulse, temperature, blood oxygen levels and even heart activity through an electrocardiogram.  .. Another key piece of objective data — medication compliance — has remained very difficult to obtain in a cost effective manner despite a great deal of research and commercial activity. Devices and software are available to remind patients, to monitor when they open a pill container and to even dispense the proper medications at the right time. There are continuing challenges with updating the more advanced devices when medications orders change. The gold standard would be knowing that patients actually consumed their medications at the proper time and in the proper dose. The leader in this space may well be Proteus Digital Health. We’ll talk to them now.

Key objective data are increasingly available from low cost, wearable devices like the Fitbit activity monitor or even sensors embedded in Smartphones. When combined with apps on the phone, they can create a patient self-management system that often includes the ability for family members or caregivers to monitor the status of an elderly patient. These are becoming more sophisticated over time and the US FDA is currently grappling with the degree to which they should be regulated as medical devices. AliveCor’s Smartphone case that can monitor a patient’s heart beat is a good example that has been through the FDA process. This is designed to assure that the devices are safe, accurately measure what they claim, are manufactured properly and that records are kept so patients with a potentially defective device can be identified.

Technologies like AliveCor have potential uses beyond patients at home. A recent article in Circulation, a leading heart disease journal reported on success in using the device to screen for atrial fibrillation, the most common cardiac arrhythmia, and one that can lead to strokes if not identified and properly treated.

It is good to not only monitor patients but to provide them with help to manage their health and diseases more effectively. This is an area where PHR apps may have a role in part because they have access to information about the patient that is stored in the PHR. The American Heart Association’s Heart360 is an example that provides a suite of capabilities including a physician dashboard that brings together data from all patients using the app who are under their care.

The final application of technology in the home is virtual visits. Once expensive, video conferencing is now available on any computer device, even Smartphones and tablets, so direct interaction between a patient at home and a professional or other caregiver can be inexpensive and simple to achieve. This application is not without controversy. Some state medical boards take a dim view of physicians treating patients over the Internet if they have not previously actually seen that patient in person.

The challenges here are similar in many respects to those around EHRs. While efficiency may not be quite as important, usability is arguably even more important and difficult to achieve. Patients, including the elderly who may not have support at home, must be able to use these technologies. The technologies are obviously capable of generating vast amounts of data from millions of patients. No one has time to look at it all, so analytic and visualization tools that minimize false positives and appropriately alert providers are of critical importance. This is an area where machine learning and other tools of artificial intelligence are being applied.

Despite the challenges, technology to empower and remotely monitor, educate and even treat patients is, without a doubt, one of the most dynamic, innovative and rapidly growing domains within health informatics. Any students of this course with an entrepreneurial mindset would do consider it.

We’ve reviewed the many ways that technologies — in particular the web, inexpensive measurement devices and mobile computing devices — are empowering patients to become a participant in the healthcare team. However, for the most part, we’ve had a single patient at a time model in mind. How can physicians manage their entire patient population effectively and efficiently. That’s the topic of Lesson 8.

Key Concepts/Vocabulary




Lesson 8

Video Transcript

Up through now we’ve been focused on the traditional “one patient at a time” care paradigm. While this is, and will always be, the primary focus of healthcare, it should be clear to you that, especially with patients who have chronic disease and in managing public health problems across the population, a different approach is needed. Here informatics has a key and essential role to play in aggregating and reporting data in ways not anticipated in the traditional EHR.

Our case study for this will be popHealth, an open source Quality Measure Reference Implementation supported by ONC. Here is the basic architecture of the system. The key concept is that queries are run against data in each provider’s EHR, as shown in the center of the diagram, without that data ever leaving the provider’s control.

The results are statistics at one of three levels of detail, called QRDA categories, and are reported in a CDA-compliant format using HL7’s Quality Reporting Document Architecture (QRDA). As you can see here the categories are at the individual patient level, lists of patients or data aggregated over the entire practice or reporting entity. We’ll discuss QRDA and other related standards such as the format for the queries in detail in Lesson 9 so, for now, it’s just a standard vehicle for reporting the results of population or public health queries.

From these individual QRDA files, popHealth aggregates and summarizes quality metrics. Here, for example, are 500 patients from a 10-provider practice (in which individual physicians could be using different EMRs). This practice might be under an outcomes based contract where their revenue is tied to meeting goals for these quality metrics. Here, they’re doing well on smoking screening but, here, not so well on weight screening and follow-up in the 18-64 year old sub-population. This points out the need to identify the right group of patients for each metric. For example, you would not, normally perform screening mammograms on men for breast cancer and the recommendations for this screening are increasingly pointing to a specific age range for women. Note that, in recognition of this key point, the numerator — typically the number of patients whose care met criteria — is in green for each metric while the denominator — the applicable target patient group for the metric — is in blue.

Where a practice level quality metric is low, the next step would typically be to drill down to the individual providers to see who might be the source of the problem, so popHealth provides data at that level, as shown here. Even though we are working at the population level the results can be aggregated and reported for individual patients as shown here.  Such a report could be reviewed as part of a patient visit and makes the patient’s status easy to encompass at a glance. Care outside of guidelines is flagged here in red.

In Lesson 3 we studied the IHIE as the premier example of centralized HIE in the US. popHealth is designed to deal with the reality in most other places where there may be on HIE in place. You’d expect that IHIE could do more with their more facile access to data, and they do.

As shown here, Quality Health First can support more sophisticated searches than would normally be found in a distributed query framework using a simpler data model than IHIE. A wide variety of patient subsets can be analyzed across all participating practice groups.

Way back in Lesson 2 we discussed the difference between process and outcomes measures using HbA1C as the exemplar. The process measure is whether it is done periodically according to guidelines and it’s actual value is a measure of the outcome of diabetes care.

Here is a dramatic example of the potential of quality reporting to add transparency to healthcare through public reporting of quality metrics. Suppose you have diabetes and want to make sure your provider cares for it properly, where would you go to find out? In general there is no good answer but, in Indiana, many providers voluntarily report this data at a practice level. Here it is for the HbA1C process metric. Three of the practices are below the state average (red line) and two are below their regional average (green line).

Here’s a similar QHF outcome metric report based on HbA1C that shows seven practices are below state average (red line) and five are below their regional average (green line).

With the growth in outcomes based contracting by insurance companies, Medicare and even major employers commercial companies now provide the population health management tools. After a quick look at what they do, we’ll interview Wellcentive, based here in Atlanta, to learn how they do it.

A report of overall performance for a list of practice-defined alerts illustrates the need to managed metrics specified in these contracts. Here you see two quality metrics from United Healthcare, a major national health plan.

Here we see an analysis by provider of the use of lipid-lowering drugs (LLDs) for patients at risk for coronary heart disease that is intended to help providers find patients whose treatments may fall outside of accepted standards of care. Here is a further provider analysis and an analysis of the relationship between blood pressure and the use of LLDs illustrating the clinical detail that is possible when EMR data is made available in addition to the typical quality metrics used in population health.

From an informatics perspective many aspects of public health are similar to population health in that data is aggregated and reported.  However, public health takes a broad view of the factors determining health and disease. To do this, as shown here, it uses disparate data sources to understand the impact of many factors and determinants of health and disease.

In the next lesson we’ll be looking in more detail at the technologies for aggregating data from diverse EHRs. One specific example is the Biosense 2.0 system developed at the Centers for Disease Control and Prevention here in Atlanta. An often cited example of the use of this technology is the Tarrant County Public Health Department in Fort Worth, TX which has used it to collect and analyze data from 60 regional hospitals for a key and foundational role that public health plays: syndromic surveillance, monitoring for disease outbreaks. Here you see an example, a time ordered display of the number of visits (typically these would be ED visits) for a particular clinical problem. The capability to produce this on a timely manner across an entire region is a powerful surveillance tool.  To learn more about how this is done we’ll talk with Dave Heinbaugh, Tarrant County Public Health Informatics, Fort Worth.

In this lesson we’ve seen that data can be aggregated across EHRs to manage entire patient populations against defined quality objectives. We’ve also seen that it can be used to support and enhance critical public health services such as disease surveillance.

Having seen what can be done we now turn to how it is done.

Key Concepts/Vocabulary




Lesson 9

Video Transcript

Distributed query is securely obtaining useful data from diverse EHR systems and other sources. We’ll look at three current open source distributed query technologies. They are different in their technical approach and goals and understanding those differences and the reasons for them is a key objective of this section of the lesson. This overall effort is now under the ONC supported Query Health initiative. I recommend you view and ONC video referenced in the instructor’s notes for more details on the overall effort and the individual systems that comprise it. As we learned in the interview with Wellcentive, there are also commercial solutions to his problem but those are proprietary and less available for this kind of discussion.

The first is hQuery where the goal is simplicity in part by working with a limited data set that is well standardized because of its key role in quality measurement and other common clinical activities. hQuery provides an attractive, modern point-and-click interface (called the hQuery composer) to the query builder who might even be a non-technical healthcare provider. At the same time, the possible queries that can be formulated are somewhat limited. hQuery uses a simple patient information model to facilitate query building by nontechnical users. Data are forwarded to an hQuery Gateway located at each source system which receives queries in a standard format and forwards them to an adapter which knows how to translate the query for the source system which might, for example, provide a CCDA document in response and can convert it into the standard data model for transmission back. You should watch a video to learn more.  The URL is in the instructors’ notes (http://news.avancehealth.com/2011/08/hquery.html). It presents results in an attractive way that, in this example, includes frequency, time and geographic distributions. 

Informatics for Integrating Biology and the Bedside (i2b2) is an NIH-funded effort based at Partners HealthCare System in Boston, Mass. Its mission is to enable clinical investigators to conduct research using state-of-the-art genomics and biomedical informatics. i2b2 is sophisticated to support complex research environments but provides an easily understood database schema that can be used to create a data warehouse where large clinical abstracts from an enterprise EHR can be stored for future analysis. This is important because the database schema of commercial enterprise EHRs can be dauntingly complex, proprietary and is not necessarily designed well to support ad hoc queries.

i2b2 implementations are comprised of “cells” that communicate via web services and are together called a “hive” as shown here. The role of most of these cells or web services should be clear from their names. Importantly, custom cells can be added to the hive. There is an organized i2b2 users group to share information and applications; and to create the potential for translational research through collaboration and federated queries across institutions.

In many instances it is desirable to bring together data from many sources and providers but those data sources are cautious about participating because of concerns about how their data will be used and whether their institution might be portrayed negatively in some analysis. PopMedNet Schema Figure 9x One solution, as depicted here for PopMedNet, is for each source to maintain control of its data (sometimes referred to as “data lockers”) but be capable of accepting and responding to queries that might go to many data sources. PopMedNet is intended to support medical product safety analysis based on aggregated reporting of complications from multiple institutions; the comparative effectiveness of alternate treatments, again resting on data from multiple sources and other studies.

9x I mentioned Query Health earlier as an umbrella effort. Here we can see a proposed architecture for that which utilizes all three of the technologies we’ve just reviewed. The goal is to facilitate cross-platform queries.  The technical vehicle for that are distributed query standards and we turn to that now.

There are four kinds of these standards each of which specifies a different key element of distributed query. (1) Envelope standards define the package for sending/receiving queries, (2) Format standards provide a Declarative specification of the query, we’ll explain what that means in the next exercise, (3) Results standards such as QRDA we discussed in the last lesson specify the format and packaging of the query results and (4) Data Model standards such as CEDD — common data element definitions — specify the data model that will link data from the contributing systems.

Before discussing the standards we need to differentiate between a declarative and a procedural specification. To do this, we’ll use baking a cake. The declarative statement expresses the desired result but does not say how to achieve it. The procedural statement provides a recipe for achieving the goal. Think back to the curly braces problem with the Arden syntax. It’s really the same thing. Arden provides a declarative standard but the procedure will be different depending on the system that is the source of the data. The hQuery Gateway similarly, receives a standard query on one side but knows how to get it done on the other.

The Query Envelope standard serves to provide identification that is unique within the network; the information requestor ID including name, email and organization; the purpose and priority of the query using 7 purpose codes (e.g. TREAT), its Priority from 1-5 (1 highest), its type Type, 1-20 characters and PHI level (Aggregated, Limited, De-identified, PHI) and its Timing, Submission date/time and optional execution date/time.

Queries are specified in the Health Quality Measure Format (HQMF), an HL7 standard format for documenting the content and structure of a quality measure in an XML document format based on the HL7 RIM. It can consist of three levels of detail: metadata such as who wrote it, the dates over which it is valid, who validated it, and other details about how the measure works or is used; human narrative including measure description, data criteria, measure population and measure observations; computer instructions as to how to count and compute the results of the measure. Here is an example of some XML providing instructions to the computer to only include patients who have had a weight measured, presumably in the numerator of a weight screening quality metric that, as you should recall from Lesson 2, is a requirement of Meaningful Use.

We introduced QRDA, the standard for query results, in Lesson 8. You should recall that they can be reported at three levels of detail: patient-level, patient-list level or aggregate level. In this example of QRDA XML the two result templates refer to NQF defined quality measures for inpatient asthma care, each of which has its own complex definition.

The Clinical Element Data Dictionary (CEDD) is a tool for implementers to use in setting up their source data in support of distributed queries within a larger Query Health solution. This is not intended as a new standards development effort and began with the elements already specified in the CCD and which most EMRs already support, since they were required for Stage 1 certification. Here’s a simple example for the patient allergy data element showing how it ties to already accepted standards used in the CCD.

In this lesson we examined in more detail exactly how data from multiple EHR systems can be queried and aggregated for diverse purposes from quality reporting to advanced clinical research. All of these technologies serve the essential role of providing a framework over the many non-interoperable EHR systems deployed in healthcare today. Taken together they illustrate different technological solutions each of which is optimized for a specific problem in a specific cross-institutional context.

So, over the last few lessons we’ve advanced from electronic record systems for providers and patients to systems for querying those systems and aggregating data for potentially interesting purposes. In our final Lesson we’ll see just how interesting some of the results can be as we delve into what is arguably the most dynamic area of health informatics today — big data and analytics.

Key Concepts/Vocabulary

●Distributed query ● Distributed query standards ● Data warehouse ● Data lockers ● hQuery ● i2b2 ● PopMedNet ● Query Health ● Health Quality Measure Format (HQMF) ● Quality Reporting Document Architecture (QRDA)




Lesson 10

Video Transcript

The purpose of this lesson is not to teach you how to do analytics. We’ve got other courses for that. Here we’ll look at the end results that are being achieved by aggregating and then analyzing data at least in part from digital health records. We’re clearly heading into a new era of medicine and healthcare and this lesson is intended to give you at least a feel for what it might look like.

The world is awash in data. It’s growing at exponential rates. People have coined the term “big data” to refer to this phenomenon but can’t quite agree on what that means, what separates big data from everything else. Cesar Hidalgo at MIT’s Media Lab says that, to qualify for this distinction, data must be big in size, resolution, and scope. To reframe this idea in a way that is directly relevant to transforming healthcare delivery systems, data must represent many patients and providers, must do so in detail, and must be combined with other data to give the context within which care is delivered and the external rules and policies within which that delivery system must operate. The data must, in summary, be sufficient to represent the behavior of the complex adaptive system we’ve been discussing.

The historic gold standard for developing new medical knowledge was the controlled clinical trial. Give two randomly selected groups of patients alternate therapies (or a new therapy and a placebo) and see who does better over time. These are difficult to do. Finding and recruiting the right patients is hard. They take a long time and they are expensive. However, if the question is which treatment works best in actual human patients there is currently not a good alternative approach.

Consider a different question such as what is the optimal treatment strategy among already known and available options? Or If a particular chronic care model were changed in a specific way, what would the outcomes be on clinical quality and cost? As opposed to these classic research questions, determining optimal treatment would require many alternative experiments, that is, trying every possible treatment strategy on groups of similar patients. To answer to the second, an experiment could be conducted by changing the clinical process in half of the clinic and comparing it to the other half that is operated as before. However, this would often be too costly and complex to do. These are the types of questions best answered through modeling and simulation using digital health data. There are a number of technique for doing this. Again, this is not an analytics course so we’ll describe them but not go into the details of how they are done.

Decisions trees are directed graphs; recursion (one-way); time is not represented. Here is a generic clinical decision strategy example where different treatment choices yield different outcomes.

Markov Models are also trees but introduce recursion where steps can be repeated and time is now represented. However, there is typically no memory so each step is based entirely on the current state of things. Here is a diabetes example where patient risks and outcomes evolve over time. Note that, unlike the decision tree, there are many paths through the model and it is possible to go back to a prior point depending on actions and probabilities.

In a Discrete event simulation entities and their attributes are represented along with queues where they wait for something typically because of finite resources. A classic healthcare example, as shown here, is an emergency department. Anyone who has ever sought treatment in one knows all about queues!

Agent based simulations are richer in attributes than discrete event simulation and agents can interact with each other and their environment. We’ll look at one of these from Georgia Tech, a simulation of the Center for Health Discovery and Well Being a novel clinic whose objective was to identify and mediate risks of future chronic disease.

Here is a visualization of the agent-based simulation of the Center for Health Discovery and Well Being, a special clinic established to explore the potential for preventing the development of chronic disease. You can see physical areas such as this education room where trained coaches interact with patients. When the simulation is actually run all the clinic personnel and the patients being served move along these pathways governed by the time it takes to do each element of the clinic’s work, the available resources and other factors. The simulation was constructed to help the clinic identify a set of processes and a revenue model that would make it both self-sustaining and of value to its parent organization.

We talked about the potential applications of analytics to the determination of optimal treatment. That now typically means the best results at the lowest cost. These are, of course, not precisely definable terms and there is a serious debate about issues such as the value of spending substantial sums on treatments that only prolong the life of terminal patients by small increments of time. The research shown here illustrates the potential to help with less controversial clinical contexts. A partially observable Markov Decision Process — a variation that introduces memory — was developed and compared to the actual treatment of nearly 6,000 depressed patients abstracted from their electronic records. I leave it to you to read this section in the text for the details but, as is shown here, under certain assumptions the model delivered improvements that were better than or almost as good as real physicians but at a better cost per unit of improvement. As we seek to re-engineer the healthcare system, technologies like this may become a routine part of clinical decision support for physicians. Some would even speculate that, at least in certain circumstances, they may replace physicians, but I leave it to you to consider that.

Congestive heart failure occurs when the heart is no longer an effective pump. It is the single most expensive ICD9 code so there is great interest in improving our care. Early on the symptoms are subtle so it may not be diagnosed for some time even after they begin. Since earlier treatment can forestall expensive complications earlier diagnosis is preferable. To do it researchers first analyzed electronic patient records, including the parts that were free text such as patient-reported symptoms. They developed extraction algorithms, as illustrated here, that used the structured and text components to develop a set of from 10 - 100,000 clinical features. These were classified using logistic regression (a statistical technique commonly used to predict whether a patient has a condition based on characteristics of the patient) and random forest (a method that uses multiple methods to classify objects) to determine which features were predictive. As shown here, Features Improve CHF Prediction: Figure 10.3, the resulting model substantially improves the diagnosis of CHF based solely on medical literature where as few as 50 features with high predictive power, based on the model, are added. This confirms the model’s prediction. For more on this we’ll talk to Georgia Tech Professor, Jimeng Sun, who did this research.

We now understand that cancer is a more complex family of diseases than previously thought and that the results of treatment in any individual patient depends on their particular genomic, proteomic and metabolic pathways and other personal factors and on similar factors in the cancer. Given the high mutation rate in cancers, there is usually more than one cell type, essentially more than one cancer in each patient. Traditional chemotherapy is essentially a metabolic poison that selectively targets rapidly growing cells and works because cancer cells divide more rapidly than normal cells. Our bone marrow,hair cells and the lining of the GI tract also grow rapidly and are attacked by the treatments leading to side effects that can be awful. More recently we’ve developed mechanistic treatments that have far fewer side effects because they selectively attack metabolic pathways in the cancer if it has the specific pathway structure that the treatment targets. Moreover, these are very expensive treatments and precious time is lost if they don’t work. Without some analytic tool it is hard to know which patients will benefit from a therapy. This research was aimed at developing a predictive model to assist physicians in selecting the right mechanistic drug for each patient. It is based on a comprehensive model of known cancer biochemical pathways, a small part of which is shown here. The blue boxes are components and the red circles are their reactions. The researchers report that when genomic data on a patient and on the primary cell types in their cancer, including cancer stem cells if possible, the model has successfully predicted the efficacy of treatment. It is now being commercialized by Alacris, of a startup company in Germany where the research was done.

Up through now we’ve been discussing how medical diagnosis and treatment can be improved through analytics. We turn now to an area that has only recently begun to get the attention it deserves, how similar techniques can improve the care delivery system. This research considered various configuration of the beds in a hospital’s surgical suite. Traditionally tjere are three types (preoperative holding area (POHA), postanesthesia care unit (PACU), and Level 2 recovery). Georgia Tech researchers developed a model using medBPM, a healthcare specific modeling tool, and showed that an alternate approach using universal beds that could be reconfigured for all three purposes could serve the same number of cases with around a third fewer beds.

With their records now digital, could we infer the underlying care processes that patients receive as they traverse the complex service areas of the hospital? More importantly, could we identify differences in these processes and the impact these have on outcomes and costs? This analysis is common in other industries and is referred to as process mining. However, those industries typically have mechanized processes where sensors routinely and accurately provide digital, time-stamped data. This is not yet routine in healthcare which is still a largely manual industry and where care steps may be documented digitally but often incompletely, inaccurately or after the fact. Nevertheless, there are situations where process mining appears to be feasible. This research from The Netherlands, where process mining originated in the late 1990’s, examined the care of ischemic stroke patients - patients with a clot in the arteries of their brain — in two hospitals. The results, as shown here, clearly indicate significant differences with one hospital using the more state-of-the-art approach aimed at protecting brain cells to limit the damage from ischemia. Stroke Care Process in Two Hospitals: Figure 10.6 This is early work but, here at Georgia Tech, we feel that process mining is an important technology for re-engineering our healthcare delivery system to be safer, more cost effective and ultimately more valuable and responsible component of our society.

So, we’ve now reached the end of this course. We began with the nature and problems of our healthcare system and the key role that chronic disease plays in it. We made the case for digital records and data sharing and we learned what the federal government is doing to encourage their adoption. We examined the key underlying technologies and looked at how they are being used in actual systems and tools for providers, patients, public health and clinical research. We then explored in more detail how data can be aggregated for analysis and concluded with a number of exciting examples of the results that can be achieved. Of course, we’re only at the beginning of a long journey. It is my hope that this course will encourage you to come along and be part of the generation that actually achieves the long held dream of transforming healthcare through health informatics.

Key Concepts/Vocabulary

● Controlled studies ● Decision trees ● Markov Models ● Discrete event simulation ● Agent-based models ● Process modeling





Suggested Blogs:

Geek Doctor
John D. Halamka, MD, MS, is Chief Information Officer of the Beth Israel Deaconess Medical Center, Chief Information Officer and Dean for Technology at Harvard Medical School, Chairman of the New England Health Electronic Data Interchange Network (NEHEN), CEO of MA-SHARE (the Regional Health Information Organization), Chair of the US Healthcare Information Technology Standards Panel (HITSP), and a practicing Emergency Physician.

HIS Talk
The anonymous author says he works for a non-profit hospital that has vendor relationships with some of the companies he writes about. He says that his objectivity (and potentially his job security) could be compromised if vendors or anybody else worked that connection to muzzle him.

HIT Sphere
This is an attempt to create a one-stop shop where people can get blogs, news, tools, and other items of interest to the healthcare IT community. It was founded and is operated by Shahid N Shah, an enterprise software analyst who specializes in healthcare IT. Over the past 15 years he has been CTO for CardinalHealth’s CTS unit (now CareFusion), CTO of two Electronic Medical Records (EMR) companies, a Chief Systems Architect at American Red Cross, Architecture Consultant at NIH, and SVP of Healthcare Technology at COMSYS.

InformationWeek Healthcare
A group of regular bloggers (including your instructor) comment on contemporary issues in healthcare and health IT.

John Lynn
John has written over 1,500 articles on the topics of EMR, EHR, HIPAA, and healthcare IT. He was the EMR Manager for the University of Nevada Las Vegas’ Health and Counseling Center. In this capacity he led the conversion from paper charts to a full electronic medical record. He has also worked on a variety of EMR consulting opportunities.

Wes Rishel
Wes is a vice president and distinguished analyst in Gartner’s healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards.

Some of these blogs may accept advertising from the HIT industry so consider that when you read them!

Suggested schedule

This is the Fall 2015 course schedule for the lessons (1 per week), exams, and project.

CS 6440 Fall 2015 Schedule and Deliverables.png