Spencer Swindell

Late-arriving data is one of those problems you don’t notice in dev — until production data starts breaking trust. At CVS Health, I worked with claims and eligibility data where updates didn’t always arrive in order. A claim could be corrected days or even weeks later, after reports were already published. Ignoring this wasn’t an option. How I handled late-arriving data in production: 🖊️ Event time over load time Instead of trusting ingestion timestamps, I designed pipelines around business effective dates (service date, eligibility window). This ensured corrections landed in the right reporting period. 🖊️ Reprocessable Bronze layer Raw data was always preserved in S3/Delta Bronze. When late data arrived, I could safely replay transformations without touching the source. 🖊️ Merge logic, not overwrite In Silver and Gold layers, I used MERGE-based updates (Spark + Snowflake) to adjust existing records instead of reloading entire tables. 🖊️ Controlled backfills I built parameterized Airflow jobs to reprocess only impacted date ranges, avoiding full historical reloads. 🖊️ Audit & reconciliation checks Every late update was tracked with record counts and before/after comparisons so business teams knew what changed and why. The result: Correct historical reporting Fewer “why did this number change?” questions Higher trust in dashboards No manual data fixes Late-arriving data isn’t a bug. It’s a reality of real-world systems — and your pipelines need to respect that. #DataEngineering #LateArrivingData #HealthcareData #ETL #Airflow #Snowflake #AWS

4

🚀 Member Eligibility Verification: The Shift from EDI to FHIR (and Now AI) As a Business Analyst / Product Owner in US Healthcare, I’ve seen how deeply provider workflows still rely on EDI 270/271 for member eligibility—despite clear limitations in speed, scalability, and provider experience. With CMS interoperability mandates and the rise of FHIR + SMART on FHIR apps, eligibility verification is evolving into an API-first, real-time capability, embedded directly within provider portals and EHR workflows. The next logical step in this evolution is AI-augmented eligibility intelligence. 🔹 From a BA / PO perspective, what’s changing? ➡️ Requirements shift from transaction-based to service-oriented eligibility capabilities ➡️ Mapping X12 segments → FHIR R4 resources (Patient, Coverage, InsurancePlan, Organization) ➡️ Defining acceptance criteria around real-time response, data completeness, explainability, and auditability ➡️ Replacing batch dependencies with RESTful APIs, SMART on FHIR, and OAuth2-based authorization ➡️ Introducing AI layers to interpret benefits, predict eligibility confidence, and flag denial risk early 🔹 Why this matters — functionally, technically, and operationally ✔️ Faster eligibility confirmation at point of care ✔️ Clearer coverage interpretation → fewer downstream claim denials ✔️ AI-assisted insights on coverage nuances, accumulators, and carve-outs ✔️ Simplified data models → improved DB storage & retrieval performance ✔️ Stronger alignment across UM, Prior Auth, Claims, and RCM workflows ✔️ Improved provider satisfaction through embedded, intelligent SMART apps 🔹 Product takeaway Eligibility is no longer just an operational check—it’s becoming a core, intelligent product capability that supports interoperability, compliance, and revenue integrity. 📌 EDI will continue to coexist, but payer platforms that evolve toward FHIR-first, AI-enabled eligibility services will deliver better outcomes, lower administrative cost, and scalable digital experiences. 💡 As BA/POs, our role is to translate regulation → workflow → technical design → AI-assisted decisions → measurable business outcomes. #HealthcareIT #FHIR #SmartOnFHIR #HealthcareAI #GenAI #AIinHealthcare #Interoperability #APIDriven #DigitalHealth #HealthTech #EligibilityVerification #RevenueCycle #PayerProvider #USHealthcare #ProductManagement #BusinessAnalysis #AIOps #IntelligentAutomation

4

I want Fabric User Defined Functions to be able to write back to an on prem SQL server. There, I said it. Don't get me wrong. All these other improvements are awesome. 6 months from now Fabric UDFs will be everywhere doing all the fun things functions do. But literally 100% of the time someone trys Translytical features in Power BI, I get a message on Teams asking how to make it right back to SQL Server. Then I have to explain the weird pattern the team came up with using composite models to kinda make it work. I don't care if we have to jump through some hoops or have a similar function back on prem, but the holy grail to me is somehow getting a Fabric UDF to write back to on prem. If you have a way, please share it. Otherwise I'll be waiting Microsoft! #Microsoft #FABRIC #DATA #IGNITE #HYBRIDCLOUD https://lnkd.in/ggK7Pdrd

4

1 Comment

Not necessarily a cyber role - but if Henry is handling it - I'd take a look. And it's Remote.

3

1 Comment

Big news from the world of EHRs: Oracle Health has officially launched its next-generation, AI-powered EHR platform built from the ground up on cloud infrastructure. This is not a 1990s system patched with new bells and whistles. It’s a true reinvention of the EHR, voice-enabled, agent-led, and ready for ambulatory providers now, with acute-care modules slated for mid-2026. So, what does this mean for hospitals across the U.S. (yes, even yours)? Let’s unpack: 🔍 What This Means for U.S. Hospitals Ambulatory first, then inpatient. Oracle’s rollout plan starts in ambulatory settings, then expands into acute care. So hospitals with large outpatient networks might be the early movers, while full-scale inpatient systems likely follow in 2026. Choice for the mid-market & big players alike. If you’re a 200-bed community hospital, this could be your “reset” moment. For health systems, this is a strategic play: a chance to leap-frog legacy burden and rebuild on a modern cloud + AI foundation. Reports already show several systems preparing to adopt. Timeline Reality Check. If you’re thinking “we’ll flip the switch next quarter”...not quite. Realistically: 2025–26: Ambulatory go-lives pick up pace 2026–27: Inpatient/acute rollouts, specialty modules 2027+: Large health systems with multiple campuses/integrations will still be executing phased deployments Hospitals should begin strategy now if they want to avoid being forced into “swivel chair” mode while peers move ahead. What’s at stake? Efficiency, clinician experience, and data-flow maturity. The promise: Voice commands, fewer screens, embedded AI agents suggesting actions – freeing clinicians from EHR fatigue. For hospitals, this means potential gains in throughput, reduction in burnout, and stronger clinical-business alignment. The “what about our existing system?” question. Most hospitals already have an EHR (Epic, Cerner/Cerner-now-Oracle, Meditech). What this means: Either a greenfield replacement or a coexistence + gradual migration strategy. Oracle mentions a “coexistence strategy” with Cerner Millennium data. So for risk-averse health systems, that gives a runway, but also means a longer, broader enterprise-project. ✅ Will Hospitals Adopt It? My Prediction Short answer: Yes, but not overnight. Likely early adopters: Ambulatory-first systems, community hospitals looking for modern tech stack, and systems that have paused legacy upgrades. Seema Verma - building an entirely new EHR from scratch is bold, but the true challenge is migration strategy: How do you plan to guide large hospital systems with deeply embedded legacy EHRs toward your platform without disruptive upheaval and what time-horizon do you think is realistic for a full system swap (ambulatory + inpatient) in a health-system environment? https://lnkd.in/eX6AzDsN

6