A Deep Dive into "Custom Data Structures." Part Two

This newsletter is the second of a two-part opinion piece in response to an article posted on Medium by my good friend Shereese Maynard, Health IT influencer extraordinaire. The first piece comments on Shereese's opinion that many of today's challenges with Electonic Medical Records (EMR) can be addressed using "Flexible Health IT Models." After speaking with Shereese to understand what this means, I agree with her that "Flexible Health IT modeling is a way of looking at the EHR that allows for customization and configuration to meet the needs of specific users or user groups. Instead of being locked into one way of doing things, you can tailor the system to fit your workflow." Some in the Health IT world would call this user/human-centered design or quality by design, and this is often the focus of "optimization" efforts after the initial EMR installation. However, based on comments from providers on LinkedIn and Twitter, there is a widespread misconception that how a particular EMR works for one physician is the only way the EMR was designed to work, which is not the case. In the previous article, we discussed that a provider's EMR experience largely depends on decisions made locally by the organization they work for/with.

The article's second premise recommends using custom data structures "to store information in the EHR that is not part of the standard structure. They allow you to define your data types and how they relate to other data types, and these structures give you more flexibility in how you store and access information." This statement is a logical next step that would need to occur if EMRs were tailored to support specific users or user groups and their workflows. These customizations will generate additional data that must be captured and stored to enable the increased flexibility providers need. But like the widespread misconceptions about the EHR's level of flexibility to support specific users or use cases, there are widespread misconceptions about how underlying "data structures" capture and store information collected through an EHR. The example given in the original article bears this out.

The example posits that an end-user might want to capture the symptoms that a patient is experiencing using a custom data structure. It continues by imagining one could create a list of all the possible symptoms a patient could have and then define the relationship between the patient data type and the symptom data type to track which patients have which symptoms, which is brilliant. However, there is a problem. A data structure already exists for symptoms, so there is no need to create a "custom" data structure. A mechanism also exists that links patients and their symptoms. Data structures exist that capture 80 - 90% of information related to the practice of medicine and the provision of healthcare. This knowledge gap is quite common among people working in healthcare, and it's understandable why this gap exists.

The industry has been working with claims data for decades, and in general, there is high data literacy for claims data. For example, there is widespread awareness of diagnoses and the ICD10 codes used to represent them, procedures and the CPT codes that represent them, and prescriptions and medications. What isn't well known is that claims data make up only five percent of the types of data we collect in healthcare. The rest of the data, what some refer to as "clinical data," makes up the other 95%. For example, symptoms are "clinical" data and aren't on a claim. Lab test results and vital signs are two additional examples of clinical data not on claims. As an industry, we collect and store exponentially more clinical information, or what some perceive as "not part of the standard EHR structure," than we do claims data; it's just not a widely known fact. Detailed clinical data holds the key to improving patient outcomes with surgical precision. Having a lab result provides more value than knowing if the lab was drawn or not. A lab result gives the provider targeted and actionable information to create a treatment plan. We will be able to ask and answer increasingly pointed questions using clinical data that we can't today with claims,

To give you an idea of the difference in magnitude between clinical data and claims data, think of each piece of healthcare information as a Lego. Each piece of healthcare information is a person, place, or thing (a noun) and a different Lego piece represents each, respectively. The data elements contained in a claim can be represented by six to seven Legos: a patient, insurance information, a provider, a prescription, a diagnosis, a procedure, and a location where the treatment took place. Most of the industry is familiar with these six or seven "Legos." In comparison, there are 147 unique Legos currently representing clinical data, and they are continuing to grow. We require seventy-one times more Legos to store clinical data than the number needed to store claims data.

Clinical information is unique because of its complex medical nature. Clinicians and specialized technicians are the only groups who intimately understand the nuanced language of the disease process, diagnostics, treatments, medications, allergies, and prognosis. They are the subject matter experts of clinical data. Equally unique is the language used to describe how care is delivered, including the processes and operations of taking care of patients. In general, nurses are the subject matter experts in the processes and operational functions required to deliver safe, effective, and engaging care; this is especially true in the hospital setting, case management, patient engagement, and population health. In addition, the level of granularity, or detail, required to represent clinical data is exponentially more complex than that of claims data. For example, medication on a claim represents the context, or action, of dispensing one medication via one prescription for one patient. This example is what "medication" means to most non-clinical healthcare workers. By contrast, in clinical data, a medication has five familiar contexts: a pharmaceutical substance, a medication order, a medication dispense, a medication administration, and a medication inventory record in the pharmacy. And there are dozens more medication contexts being developed as we speak.

Adding to the complexity of clinical data is that until very recently, there was no standard way to represent or store clinical data. This lack of a standard structure (data model) to collect and store clinical data has led to the lack of interoperability we wrestle with today. Again, let's use Legos as a working concept to represent a structure that holds healthcare data. Currently, some organizations are using Legos to collect and store clinical data. For example, a symptom may be stored in a single-layer, blue Lego, with four buttons on top. A diagnosis may be stored in a double-layer, yellow Lego, with two buttons. And a medication stored in a triple-layer, red Lego, with one button, etc. If this mechanism were consistent across the industry, it would be easy to exchange and reuse patient information between organizations.

Imagine a scenario where a local hospital uses Legos and needs to share information with the patient's primary care physician (PCP) located a few blocks from the hospital. The hospital can share the information with the clinic via a PDF. If only a PDF is shared, the document is not reusable. In other words, the PCP will see the PDF once. Then the data, including medications, procedures, and diagnoses, will be stored away in the EMR in a place others will not likely look in their usual workflow. For the information to be usable for the entire care team would require the hospital to send the clinic four Legos that contain the patient's hospital medications, hospital diagnoses, hospital procedures, and patient discharge instructions, which could then be combined with the patient's Legos at the clinic. The reality is that likely, the clinic is not using Legos; they are using something else. The IT leader of the clinic is a huge history buff, and when the choice was made about how to store data for the clinic, he chose Lincoln Logs. Because of this, the information from the hospital, stored in Legos, cannot be combined with the patient's Lincoln Logs at the clinic.

Extrapolate this scenario across the healthcare ecosystem and we have organizations storing data in Legos, Lincoln Logs, Duplo Blocks, Erector Sets, Tinker Toys, Bristle Blocks, wood blocks, foam blocks, and the old standby, popsicle sticks, and glue. In the current situation, it's not hard to understand why healthcare data pose significant barriers to the modernization of the industry. We have been using "custom data structures" in healthcare for decades. Custom data structures cannot be extracted, aggregated, harmonized, consistently cleaned, and transformed across different Lego derivatives without an enormous, highly skilled Information Technology department. Custom data is what analysts, statisticians, and data scientists call "dirty data." Unfortunately, analysts and data scientists spend upwards of 80% of their time cleaning "dirty" data before it can be used for longitudinal patient records, analytics, AI, or machine learning. Let's connect these two dots to avoid creating more work for our technical teams. This rework is an example of the waste we talk about eliminating in healthcare. We create this additional work for ourselves and then wonder why our IT department budgets continue to skyrocket.

According to Experian Research, dirty data has a direct impact on the bottom line of 88% of companies, with the average company losing 12% of its annual revenue.

Fast Healthcare Interoperability Resources (FHIR) is the standard data model (the Legos) that the entire world has embraced to represent healthcare data. We are finally at the tipping point of interoperability being achievable. To continue to generate custom data from this point forward goes against everything the industry has been working for decades to correct.

If you need to collect and store data that is seemingly outside your current capabilities, please reach out to a semantic Subject Matter Expert (SME) regarding the specific meaning and scope of use for clinical and claims data. They will be able to determine if there is an existing FHIR Resource and/or data element that will meet your needs. Be wary when you hear the words "extendable, extensions, or extend" in the context of FHIR Resources. Someone may be proposing a solution that "extends" the FHIR standard when an appropriate FHIR resource exists, but they are unaware of it. Recommendations to unnecessarily extend FHIR will happen as we transition from seven claim data concepts to 147 clinical data concepts to represent healthcare data. Your local IT team may not have the healthcare domain expertise or semantic data literacy to determine or recognize that a Resource, data element, codeSet, or terminology exists that is fit for your purpose. We want to avoid the proliferation of custom data structures and FHIR extensions. These same semantic SMEs can also support your organization's efforts to leverage APIs by ensuring you are requesting/sending the correct information and FHIR Resources in your GET, PUT, POST, and DELETE methods.

What do you think about the use of Legos as an analogy for health care data models? Is it an effective way to communicate the problem?

Interested in seeking advice from a trusted healthcare informaticist about FHIR data modeling? Email us at [email protected] to see how we may be able to help your organization transition to the new FHIR standard with confidence.