DEV Community: Scott Shoemaker

MedReach-AI: Kicking Off Sprint 3 and the "Brain" of Phase B

Scott Shoemaker — Tue, 18 Aug 2026 11:01:22 +0000

Hey everyone, Scott here. Collin and I are back with the latest engineering update for MedReach-AI.

We just officially closed out Phase A of development. Over the last two weeks, we built a rock-solid foundation for our file ingestion pipelines, set up a heuristic engine that automatically maps healthcare columns, and locked down our export endpoints with strict HIPAA-compliant filters.

With the plumbing working flawlessly, we are now shifting into Phase B: Data Intelligence. This is a massive two-week sprint where the workload essentially doubles, and we transition from simply moving data around to actively analyzing and sanitizing it.

The Sprint 3 Goal
To put it simply: we are building the brain. Our goal for Sprint 3 is to take raw, uploaded healthcare datasets and run them through automated PII/PHI scrubbing, real-time government registry validations, and machine learning anomaly detection before the user ever sees the final dashboard.

How We Are Tackling Phase B
Looking at our Jira board, we have broken this phase down into a few core pillars:

Machine Learning (The AI in MedReach-AI): This is the part I am most excited to dive into. We don't have months to train a massive neural network, so we are utilizing unsupervised machine learning via Scikit-Learn. By deploying IsolationForest and DBSCAN clustering algorithms, our backend will be able to mathematically evaluate a dataset on the fly and flag statistical outliers or corrupted records without relying on rigid, hard-coded rules.

Security & Compliance: We are integrating the Microsoft Presidio engine to actively detect and anonymize protected health information (PHI). We are also building ingestion engines for CMS Open Payments data to flag financial conflicts of interest (Sunshine Act compliance).

External Validation: We are building an asynchronous client to query the official CMS NPI Registry. This will validate provider credentials in real-time and enrich our database with verified classification statuses.

Dashboards & Deduplication: While I handle the machine learning and deduplication algorithms on the backend, Collin is building out the interactive React tabs. These interfaces will allow compliance officers to visually review our AI’s flags, merge duplicate records, and download legally sound PDF audit trails.

What’s Next?
It is a heavy workload, but our Phase A architecture is clean, and we are ready to execute. For the first week of this sprint, I am focusing entirely on getting that Scikit-Learn Isolation Forest up and running to start flagging our test data.

We will be back next week with a mid-sprint update to share how the anomaly models are performing!

MedReach-AI: Sprint 2 Progress & Milestone 2.1 Update

Scott Shoemaker — Fri, 14 Aug 2026 23:04:45 +0000

That makes perfect sense. Since Phase A is a full two-week sprint (August 10th to August 24th), today (August 14th) marks the exact midpoint.

Framing this as a midway check-in adds a lot of professionalism. It shows you aren't just scrambling week-to-week, but executing a well-planned, two-week architecture. Week 1 was about safely catching the data; Week 2 is about aggressively processing it.

Here is the updated blog post reflecting the two-week Phase A narrative.

MedReach-AI: Phase A (Mid-Sprint) Progress & Milestone 2.1 Update
Welcome back to the MedReach-AI development log. I’m Scott Shoemaker, alongside my co-developer Collin. As we push through our software engineering capstone, we are excited to share our progress for the 2.1 Project Milestone.

We are currently executing Phase A: Data Management, which is scoped as a comprehensive two-week sprint running from August 10th to August 24th. Today marks the midpoint of this sprint. For Week 1, our engineering focus was establishing the core file upload architecture on both the frontend interface and the backend API.

Here is a breakdown of what we accomplished in the first half of Phase A, the roadblocks we cleared, and our roadmap for Week 2.

Week 1 Backend: Securing the Data Pipeline
On the backend, my primary responsibility for this first week was ensuring our FastAPI server could safely catch and store incoming data streams before we begin processing them. I completed two major tickets:

MA-17: Firebase Storage Upload Endpoint (Completed): I engineered a tenant-scoped file upload endpoint. When a file is uploaded, the API successfully routes it to our local Firebase Storage emulator. It returns a 201 Created status with a generated UUID and the definitive storage path, guaranteeing strict data isolation between clinics.

MA-22: Malformed Data & Schema Error Wrapper (Completed): To ensure bad data doesn't crash the server during Week 2's heavy processing, I implemented a validation wrapper using Python's csv module. If a clinic uploads a corrupted file, the server intercepts the unparseable delimiters or decoding errors and returns a structured 400 Bad Request. This payload identifies the exact line number of the error, keeping the application stable.

Week 1 Frontend: Building the Interface
On the frontend, Collin spent this week translating our Phase A wireframes into functional, interactive React components:

MA-16: UI Drag-and-Drop File Upload Component (Completed): Users now have a clean, intuitive dropzone to pull their CSV files into the application.

MA-20: UI Column Mapping Confirmation & Override Table (Completed): Collin built out the data table where users can visually review their uploaded data and manually override data types before final submission. The state management is wired up locally and prepped for backend integration.

MA-15: UI Export Screen & File Download Controls (In Progress): The core layout for the data export screen is established. Finishing the button states and download triggers will carry over into early next week.

Roadblocks & Technical Challenges
No sprint is without its hurdles. On the backend, setting up the storage emulator for MA-17 resulted in a massive port conflict. Localhost ports 8080 and 8000 were clashing with background processes, crashing our startup sequences. I resolved this by remapping the Firestore emulator to port 8081 and updating our configurations, successfully clearing the network blockage.

On the frontend, ensuring the local React state perfectly matches the expected backend JSON payloads took some extra coordination. Because of this, MA-15 required a bit more time and will bridge the gap into Week 2 to ensure the data formatting is perfectly aligned.

The Roadmap: Week 2 of Phase A
With the file ingestion infrastructure stabilized in Week 1, the second half of this sprint is entirely dedicated to active data processing and endpoint integration.

Scott's Backend Tasks (Week 2):

MA-21: Pandas Chunked CSV Ingestion Engine: Standard of Completion: The engine must successfully process a 100,000-row CSV file without exceeding 512 megabytes of server RAM. I will utilize the Pandas chunksize parameter and tracemalloc to strictly monitor and prove our memory footprint.

MA-19: Heuristic Column Type Detection: Standard of Completion: The backend must automatically evaluate the sample data and infer column types (like emails and phone numbers) using regex, returning a mapped schema dictionary.

MA-18: Clean CRM-Compatible CSV Export Pipeline: Standard of Completion: The API successfully returns a sanitized dataset formatted for standard CRM ingestion.

Collin's Frontend Tasks (Week 2):

Complete MA-15: Standard of Completion: A fully functional download interface that triggers the browser's native file save dialog with the scrubbed data.

Endpoint Integration: Wiring the completed Phase A frontend React components directly to the active FastAPI endpoints to establish end-to-end functionality.

We are in a great position at the midway point of Phase A. Our repositories are stable, our data validation is bulletproof, and our interface is coming to life. Check back at the end of the sprint as we fire up the data-scrubbing engine!

Sprint 1: Standing Up the MedReach-AI Backend (and Taming Emulators)

Scott Shoemaker — Fri, 07 Aug 2026 01:27:21 +0000

Kicking off a brand-new project is always a fun mix of grand architecture planning and immediately running into weird setup bugs. This week, we officially started the MedReach-AI capstone project, and my main focus was getting our Python and FastAPI backend repository scaffolded and ready to go.

Overall, the basic server setup was a breeze, but hooking up our local dev tools and establishing the Git workflow threw a couple of curveballs my way.

The Problem: Firebase Emulators vs. Strict Security
I set up the Firebase Emulator Suite for our Firestore database so we can develop locally without worrying about cloud costs. Usually, when you connect the Firebase Admin SDK to a local emulator, you just pass a dummy credential dictionary with a fake private key (like "private_key": "mock-key"). But when I spun up the Uvicorn server to test it out, the app immediately crashed.

It turns out the underlying Python cryptography package recently got a security upgrade. It now strictly validates the math behind RSA keys before the app is even allowed to start. Since my "mock-key" obviously wasn't a valid RSA structure, it threw a ValueError: Unable to load PEM file and stopped the server dead in its tracks.

The Fix: Demo Projects to the Rescue
Instead of wasting time trying to generate a mathematically valid fake RSA key—which kind of defeats the purpose of a quick local setup—I realized I could bypass the certificate requirement entirely.

Firebase actually has a built-in way to handle this. By stripping out the dummy credential and initializing the app with a "demo" project ID, the SDK knows it's strictly in an offline testing environment.

Python
Tell the SDK to connect to the local emulator
os.environ["FIRESTORE_EMULATOR_HOST"] = "127.0.0.1:8080"
Initialize using a demo project ID instead of a certificate
if not firebase_admin._apps:
firebase_admin.initialize_app(options={
'projectId': 'demo-medreachai'
})

That completely fixed the crash. My /api/health endpoint was instantly able to query the local Firestore database.

The Problem: Git Remote Collisions
Next up, I needed to push this clean, working baseline (complete with Black and Flake8 formatting) up to our backend-dev branch on GitHub. Simple enough, right? Nope. Git immediately rejected the push.

Because the repository was originally created on GitHub's website before I scaffolded the local files, it had an auto-generated template commit (like a default README) that my computer didn't have. Git’s safety features kicked in to stop me from accidentally wiping out that remote work.

The Fix: A Good Old-Fashioned Force Push
Usually, running git pull --allow-unrelated-histories is the move here to merge the two timelines. But since my local environment was specifically built to be the absolute "source of truth" for the backend, I didn't want to merge in random GitHub template files.

I went with a force push to overwrite the remote branch and establish my local folder as the true baseline:

git push -u origin backend-dev --force

Wrapping Up Sprint 1
With Git sorted out and Firebase playing nice with the emulator, the MedReach-AI backend is officially up and running. Our Uvicorn server is live, the interactive Swagger UI is generating our docs automatically, and our linters are keeping the code clean.

The foundation is set, and next week we finally get to dive into feature development!

Sprint One: Slicing the Monolith and Standing Up the Phase A Backend

Scott Shoemaker — Sat, 25 Jul 2026 08:32:44 +0000

Welcome back to the dev log. Last week, Collin and I officially pivoted MedReach AI into a "Data Intelligence First" platform, locking in our enterprise architecture and securing our multi-tenant data models. This week, the planning phase ended. Sprint 1 officially kicked off, marking our transition into active software engineering.

However, as we moved to pull our Phase A (Data Management MVP) tasks from the backlog, we immediately encountered a classic software development trap.

The Problem: The "8-Point Ticket" Trap
As the Scrum Master for this project, my goal is to protect our team’s velocity and prevent burnout. While planning Sprint 1, I noticed several of our backend architectural tickets—such as integrating Microsoft Presidio for PII scrubbing and building our async CMS NPI Registry validation pipeline—were estimated at 8 Story Points.

In Agile development, especially for a two-man capstone team balancing outside lives and careers, an 8-point ticket is functionally a monolith. It represents too much ambiguity. If a single ticket takes 20+ hours to complete, it risks sitting in the "In Progress" column for the entire sprint. If I hit a bug on day two, my velocity flatlines, and worse, I become a bottleneck for my frontend partner who is waiting on that API contract.

Caption: Breaking down our Phase A backlog into highly granular, sprint-ready deliverables.

The Solution: The 4-Point Hard Cap
To solve this, I enforced a strict Agile capacity rule for our board: No single task can exceed 4 Story Points.

We mapped our estimation scale directly to our weekly capacity, where 1 point equals roughly 4 to 5 hours of engineering work. By capping tickets at 4 points, we ensure that the absolute maximum size of any task represents one week of part-time capacity (approx. 20 hours).

I spent the first part of this week slicing our backend monoliths into testable, bite-sized components. For example, instead of one massive ticket for "NPI Validation," we now have separate 2- and 3-point tickets for the base REST connection, the async batching queue, and the local caching layer. This granularity guarantees that even if we hit a roadblock, we can still merge smaller victories and keep the burndown chart moving.

Execution: Architecting the Phase A Backend
With our sprint scope cleanly defined, I swapped my Scrum Master hat for my Backend Architect hat. My primary technical focus this week was our most critical MVP blocker: Security and Ingestion.

JWT Middleware & Multi-Tenant Isolation: Before parsing a single CSV, we had to ensure our data boundaries were airtight. I mapped out and configured the Firebase Authentication middleware to intercept API requests and validate custom Role-Based Access Control (RBAC) claims. This ensures that an Editor in Company A can never access, query, or mutate data belonging to Company B at the database level.
Chunked Ingestion Pipeline: I also began scaffolding the pandas chunked CSV reader. Because enterprise healthcare datasets can be massive, this async ingestion engine is designed to parse large files without maxing out our server's memory, passing the data smoothly to our heuristic column detection logic.

Caption: The MedReach AI Multi-Tenant Isolation & Role-Based Access Control architecture, defining strict database-level boundaries and the permission matrix for our Phase A MVP.

What’s Next?
By slicing our tasks down and securing the gateway, we have created a safe, isolated sandbox to begin heavy data manipulation. Next week, I will be deep-diving into the Microsoft Presidio integration to automate our PII/PHI redaction engine.

Until next time, keep your sprints short and your endpoints secure!

Sprint One: Why We Pivoted MedReach AI to "Data Intelligence First" and Killed the Paid API

Scott Shoemaker — Sun, 19 Jul 2026 15:19:19 +0000

Welcome back to the dev log! If you read my Sprint Zero post, you know my capstone partner, Collin, and I set out to build a full-stack AI platform using an asynchronous, horizontally split workflow. As we transitioned from initial scoping into Month 2 of our build, our concept matured into MedReach AI—a specialized B2B healthcare SaaS platform designed for mid-size pharmaceutical and medical device companies.

However, as we dove into our software architecture review this week, we hit a massive strategic crossroads that forced us to completely refactor our engineering roadmap and Jira backlog.

The Problem: The Insecure "Marketing Automation" Trap
Originally, we visualized MedReach AI as an AI-driven marketing campaign generator that happened to clean Healthcare Professional (HCP) databases. But after evaluating industry pain points, we realized we were solving the wrong problem first.

In the pharmaceutical and medical device sectors, marketing teams don't struggle to generate email copy; they struggle with dirty, unvalidated, and legally hazardous data. Up to 30% of standard HCP databases are riddled with outdated contacts, retired physicians, and unvalidated National Provider Identifier (NPI) numbers. Running automated campaigns on bad data doesn't just waste budget—it creates massive legal exposure under federal regulations like the Physician Payments Sunshine Act and FDA off-label promotion guidelines.

Furthermore, enterprise platforms that actually solve this (like Veeva or IQVIA) cost upwards of $500,000 annually, pricing out two- to three-person marketing teams. From an engineering perspective, treating data cleaning as a simple preprocessing step for a marketing tool was a recipe for disaster. It meant we were treating security, multi-tenant data isolation, and role-based access control (RBAC) as secondary features. In healthcare SaaS, if you bolt on security at the end, your platform is inherently broken.

Caption: Restructuring our Jira backlog into three distinct functional milestones: Data Management, Data Intelligence, and Visualization & Export.

The Solution: A "Data Intelligence First" Architecture
To fix this, Collin and I leaned heavily into our Agile framework and initiated a comprehensive architecture pivot. We repositioned MedReach AI entirely around Data Intelligence, treating campaign generation simply as one of several downstream outputs of a clean, standardized dataset.

To execute this without losing sprint velocity, we made three critical architectural decisions this week:

1. Shifting RBAC and Security to the MVP Blocker
We completely reorganized our 54-task Jira backlog into three new phased milestones: Phase A (Data Management MVP), Phase B (Data Intelligence Alpha), and Phase C (Visualization & Export Beta).
Crucially, we pulled our Firebase Authentication JWT middleware, Firestore database-level multi-tenant security rules, and full-stack RBAC (Admin, Editor, Viewer roles) out of future sprints and pushed them directly into Phase A. Why? Because no file upload or cleaning pipeline should ever be tested without strict tenant isolation already enforcing database boundaries.

2. Killing the Paid API (Why Local Open-Source Wins)
In an era where every startup simply wraps the OpenAI or Anthropic API, we made a deliberate engineering choice: we are using zero paid external LLM APIs.
Instead, our FastAPI backend orchestrates self-hosted Meta Llama 3 8B and Mistral 7B models running locally on an on-premise Ollama runtime. In healthcare, clients are legally and commercially terrified of transmitting Protected Health Information (PHI) or proprietary HCP lists to third-party AI vendors. By keeping 100% of our AI inference inside our own platform infrastructure, we eliminate per-call API costs at scale and turn data privacy into our primary B2B selling point.

Caption: MedReach AI's system architecture, highlighting our self-hosted AI runtime and isolated Firestore multi-tenant data layer.

3. Layering the Tech Stack for Asynchronous Speed
By stabilizing our Phase A core this week, Collin and I can safely maintain our horizontal split. While Collin builds out the React 18 / Tailwind CSS drag-and-drop upload zones and natural language query interfaces on the frontend, I am building the backend Python pipelines. I'm currently integrating Microsoft Presidio for automated PII/PHI detection, scikit-learn for Isolation Forest anomaly detection, and asynchronous HTTP clients to validate provider records against the public CMS NPI Registry in real time.

What This Means for My Journey
As someone aspiring to step into an AI Solutions Program Director or Product Manager role, this week was a masterclass in product framing and technical risk management. It reaffirmed a core lesson: good software architecture isn't just about writing clean code; it's about aligning your database schemas and sprint backlogs with the actual commercial and regulatory realities of your industry.
With our roadmap refactored, our Jira board aligned with our design documentation, and our security gates locked in place, we are ready to build the core cleaning engine.
Next stop: getting our pandas chunked CSV ingestion pipeline and Presidio anonymizers communicating smoothly. Stay tuned for Sprint 2!

Architecting MedReach AI: Solving Data Rot and Regulatory Bottlenecks in Pharma Marketing

Scott Shoemaker — Sun, 12 Jul 2026 16:17:13 +0000

As we kick off Month 1 of our AI Software Development Capstone, I am thrilled to officially introduce the project I will be co-developing over the next five months: MedReach AI.

In my role as the Project/Scrum Master and Backend Architect, I am pairing up with my teammate, Collin Miner, who will be spearheading the frontend UI/UX and client-side architecture. Together, we are building a multi-tenant SaaS platform designed to completely overhaul how pharmaceutical and medical device companies handle outreach, segmentation, and compliance. But before diving into our tech stack, we have to look at why this industry is in desperate need of a modern, lightweight solution.

The Problem: Data Rot and the "Two-Person Marketing Team" Dilemma
Mid-size pharmaceutical and medical device companies face a massive operational bottleneck: their marketing teams run off Healthcare Professional (HCP) databases that are constantly decaying. Industry data shows that physician contact information degrades rapidly—doctors relocate, change specialties, retire, or move across state lines where different data privacy laws apply.

When a two- or three-person marketing department attempts to run a campaign using unvalidated spreadsheets, three critical failures occur:

Wasted Budget & Poor Targeting: Campaigns are sent to outdated contacts or duplicate records, sinking ROI.
Regulatory & Compliance Risks: In the pharma world, sending unverified communications can lead to severe penalties under federal regulations like HIPAA, the Physician Payments Sunshine Act, and strict FDA guidelines regarding off-label promotion.
Resource Drain: Small teams end up spending 80% of their time manually scrubbing CSVs and cross-referencing government registries instead of actually designing marketing campaigns.

While enterprise-grade data hygiene tools exist, they cost hundreds of thousands of dollars annually and require dedicated technical implementation teams—completely pricing out mid-sized organizations.

Sprint Zero: Architecting an Asynchronous Workflow for a Two-Man Dev Team

Scott Shoemaker — Sun, 05 Jul 2026 18:55:51 +0000

Hello World! I’m Scott M. Shoemaker, a Computer Science student with a concentration in Artificial Intelligence, based in Webster, New York. This post marks the official beginning of my Capstone project. However, before a single line of code is written, I had to tackle one of the most critical challenges of software development: project architecture and team management.
The Problem: Scope Creep and Development Bottlenecks
My Capstone team recently pivoted to a two-man structure. My partner, Collin, and I are tasked with building a full-stack GovTech AI application—incorporating React, Python, FastAPI, and PostgreSQL—in just five months. The primary problem we faced this week was logistical: how do two developers, who are also balancing outside careers and lives, build a complex application without constantly blocking each other's progress or causing massive code-merge conflicts?

The Solution: Asynchronous Sprints and API Contracts
To solve this, I leaned on my Agile Project Management and Scrum Master certifications to design a workflow that protects our velocity. Instead of a traditional, intertwined development cycle, I structured our execution plan around a strict asynchronous workflow managed via 2-week sprints.

Our solution utilizes a "horizontal split." I am acting as the Backend Architect and Scrum Master, while Collin owns the Frontend UI/UX. To prevent bottlenecks, the strategy we implemented this week was to define strict API Data Contracts early. By agreeing on the exact JSON format my backend will eventually send, the frontend can be built out using dummy data next month. Meanwhile, I can construct the database and tune the Gemini API in complete isolation. We will not integrate the two halves until Month 3. This isolated sprint strategy mitigates our highest risk and removes development friction.

My Journey and Goals
My journey into computer science has always been driven by a desire to turn chaotic, complex systems into structured, working logic. Beyond this Capstone, my ultimate goal is to step into a role as an AI Solutions Program Director or Product Manager, ideally within the GovTech or AgTech sectors. I want to build practical software that bridges the gap between high-level AI capabilities and real-world utility, translating dense, bureaucratic systems into highly accessible tools.

I’ll be documenting the technical hurdles, AI prompt tuning, and backend breakthroughs of this 5-month journey right here. Stay tuned for Sprint 1!