11.1 Disparate Data Sets and Alternate Solutions
Key Takeaways
- Domain 3 tasks A.5 and A.6 sit in Information and Systems Management (30%): interpret disparate data first, then formulate more than one process or application path.
- Claims, EHR, and device feeds differ in grain, identity, lag, and vocabulary. A last-name join is not analysis.
- Publish match rate, unmatched residual, and the identity method (EMPI, deterministic key, or device-binding table) before any outcome claim.
- Alternate solutions include status quo, process-only, configure, interface, buy-module, buy-platform, and build—not a single favorite vendor.
- A new platform does not repair a 28% identity mismatch. The mismatch travels into the new database.
11.1 Disparate Data Sets and Alternate Solutions
Quick Answer: Domain 3 tasks A.5 and A.6 are a pair. First profile and interpret claims, EHR, and device (or other) sets that do not share grain, identity, lag, or vocabulary. Then formulate more than one process or application path. A last-name join is not analysis. A single favorite platform is not an alternate-solution set.
Information and Systems Management is 30% of CPHIMS—the heaviest domain. Chapter 10 covered SDLC, needs and gap analysis, DMAIC/PDCA, and process maps. This section is the analysis work that starts once you have a problem and messy sources: can you say what the data can honestly support, and can you propose more than one way to close the gap? Design (chapter 12) and selection (chapter 13) come after.
Why disparate-data analysis is a professional competency
Healthcare does not have one database of truth. A diabetes program, a readmission committee, or a remote-monitoring contract will almost always pull claims (what was billed and paid), EHR (what was documented and ordered), and device or HIE data (what a sensor or outside organization recorded). Those sets answer different questions. If you inner-join them on a fuzzy name and present “the” HbA1c or “the” program result, you have not analyzed anything. You have decorated a meeting.
Task A.5 rewards the habit of naming source, grain, identity key, lag, and vocabulary before any join. Task A.6 rewards the habit of writing several process and application options after you know what the data can support—including process-only and configure-existing options, not only a new purchase.
Profile each set before you join
Treat every feed as a stranger until you can fill this card:
| Source | Typical grain | Identity you actually have | Lag | Vocabulary | What it can support | What it cannot |
|---|---|---|---|---|---|---|
| Claims / billing | Claim or claim-line | Member ID, subscriber ID, NPI, billed dates | Often 30–90+ days after service | ICD, CPT/HCPCS, revenue codes, DRG | Utilization, paid cost, coded comorbidity, attributed membership | Real-time census, nursing notes, unbilled care, uninsured self-pay never submitted |
| EHR clinical | Encounter, order, result, note, med-admin | MRN, encounter ID, visit number | Minutes to a day for structured events; notes later | Local codes plus mapped SNOMED CT, LOINC, RxNorm, ICD | Clinical process, results, orders, in-system care | Care outside the enterprise, adjudicated cost, device-continuous streams |
| Device / RPM / CGM | Reading or session | Device serial, vendor cloud ID, sometimes an email | Near real time if bound; hours if batched | Vendor observation codes; may map to LOINC | Wear-time, physiologic trend | Patient identity unless a binding table exists; billed medical necessity |
| ADT / registration | Event (admit, transfer, discharge, register) | MRN plus a too-often-duplicate name/DOB/address set | Seconds to minutes | HL7 event types | Location, census, identity source of truth if governed | Clinical completeness, claims payment |
| HIE / outside record | Document or event | Community EMPI if lucky; else demographics | Hours to days | C-CDA, FHIR resources, mixed local codes | Cross-organization encounters | Completeness; not every site participates |
A grain mismatch is not a rounding error. Averaging a claim-line (one CPT), an encounter (one visit that generated five lines), and a CGM reading (hundreds of points per day) produces a number that has no operational meaning. Decide the analysis grain first—attributed member-month, completed 90-day program episode, discharge—and roll every source up to that grain.
Identity mismatch is the usual failure
The join key is the analysis. Typical collisions:
- MRN ≠ member ID ≠ device serial ≠ email. Registration staff, payers, and device vendors did not design one namespace.
- Duplicate MRNs. Same person, two charts, after an urgent registration or a name change. The registry then double-counts or drops them.
- Name and date-of-birth overlaps. Common names plus a popular DOB create false matches if you skip address, phone, or an EMPI score.
- Dependent versus subscriber. Claims may sit under a parent subscriber ID; the EHR has the child’s MRN.
- Clock and calendar. Claims use statement period and paid date. EHR uses documented event time. Devices use UTC or a clinic clock that was never synced.
Deterministic matching requires an exact or carefully normalized shared key (enterprise ID, or a high-quality last-four + DOB + sex rule that you have tested on a clerical sample). Probabilistic or referential matching through an EMPI scores several fields and should publish a match rate, a clerical-review queue, and a false-match tolerance. Device binding is a separate table: this serial belonged to this MRN for this date range. If the binding is missing, you do not have a patient-level series. When a loaner CGM is reassigned, last month’s glucose otherwise attaches to a new patient.
Report match rate and residual. “We linked 72% of attributed members to an EHR encounter in the window” is analysis. “We joined the files” is not. Silent drops of the unmatched 28% turn a coverage problem into a fake outcome.
Interpret, then formulate alternates
Task A.6 is not “pick the platform you liked at the conference.” After A.5 tells you what the data can support, write a set of process and application options against the same gap:
| Alternate | What changes | When it is honest | Typical failure |
|---|---|---|---|
| Status quo (baseline) | Nothing | Always required as the comparison | Teams skip it and cannot show incremental value |
| Process only | Registration dual-search, MRN merge campaign, coder query, new huddle | Identity or workflow is the constraint | Buying software to paper over bad registration |
| Configure / extend current system | Registry workbench, new report, unused licensed EHR module | The capability is already paid for but unused | “We already paid for it” used as a slogan with no gap test |
| Interface / integrate | Engine, FHIR/HL7, EMPI, payer roster file | Sources are adequate; plumbing is not | Point-to-point spaghetti and no survivorship rules |
| Buy a module | Add-on from the incumbent suite | Strategic fit and data already live in the suite | Incumbent tax; still no identity repair |
| Buy a new platform | Overlay or replacement | Requirements exceed the current suite and identity is governable | New database inherits the 28% mismatch |
| Build | Custom app or warehouse mart | Unique workflow, no product fit, staffed sustainment | Shadow IT with one developer |
An alternate-solution package should name tradeoffs: residual identity risk, time-to-value, interface burden, lock-in, and whether the process change is required anyway. If every option except “buy Product X” is missing, you have not done A.6.
Walk a diabetes (or any) join in this order: profile lag and keys; build or reuse an EMPI crosswalk and a device-binding table; declare grain; state inclusion (uninsured patients missing from claims, out-of-network A1c missing from the EHR, CGM non-wear is not normal glucose); publish match rate; then list alternates. The reverse—selecting a platform, then hunting for a join that makes the slide green—is how programs fail audits and how CPHIMS stems fail candidates.
Scenarios and exam traps
Scenario. Quality wants one rate of “controlled diabetes.” Finance pulls claims ICD rows. Nursing pulls last EHR A1c. The vendor pulls CGM time-in-range. The three rates differ by 11 points. Walk grain, identity, lag, and inclusion before anyone presents “the” rate.
Scenario. A director saw a population-health demo and asks for a sole-source buy because “our data are a mess.” Messy data is an A.5 finding. It is not a reason to skip A.6. Offer EMPI cleanup, registration dual-search, and an interface of the payer roster into the existing registry beside the buy.
Scenario. Analysts inner-join claims to EHR on last name + first initial + year of birth and get a 96% “match.” That is often a collision rate, not a match rate. Common names will false-match. Demand an EMPI or a tested deterministic key and a clerical sample.
Scenario. Device serials are loaded as if they were MRNs. A loaner CGM is reassigned; last month’s glucose attaches to a new patient. Binding tables with date ranges are part of the analysis, not an IT nicety.
Watch these traps:
- Joining before profiling grain, identity, lag, and vocabulary.
- Last-name or device-serial joins presented as identity resolution.
- Silent drops of unmatched rows.
- One favorite application with no process-only or configure-existing alternate.
- Treating a new platform as an identity repair.
- Mixing claim-line, encounter, and device-reading grains in one average.
A diabetes program wants one outcome from payer claims, EHR A1c results, and CGM device files. What should the informatics lead do first?
After profiling, 28% of attributed members have no EHR encounter, and leadership wants to buy a new population-health platform to “fix the data.” What is the best A.6 response?
Why do claims and EHR counts of “patients with diabetes” routinely disagree even when both extracts are technically correct?