// featured case study
EMR Platform
Vision Group Canada · 2023 – present
The platform ophthalmology and refractive surgery clinics operate on. It carries a patient through the entire arc: referral in from a community optometrist, consult, pre-op workup, surgical scheduling, the procedure, post-op follow-up, and the handoff back to the referring optometrist.
Refractive surgery runs on a referral loop with physicians outside the organization. So the system has two populations with different trust levels — and only one of them belongs inside the EMR.
the boundary
Two front doors. One database.
Outside physicians never enter the EMR. They submit referrals through a separate co-management portal, built by a different team, in PHP, on separate hosting. The EMR stays internal: clinic staff, optometrists, ophthalmologists, surgeons, technicians, admins. A referral either attaches to a patient already on file or creates one. That boundary was organizational before it was architectural — a different team, a different stack, a different host. It happens to be a defensible design, but it wasn't drawn on a whiteboard.
the integration
S3 → Lambda → FSx
Two runtimes with nothing in common still had to exchange clinical documents. A referral document lands in S3; an s3:putObject event triggers a Lambda I own; the Lambda delivers into the FSx share, and the document surfaces on the patient's file. It's the unglamorous shape every senior engineer recognizes on sight — an event-driven cloud stack handing off to a consumer that only speaks files.
reporting migration
Reporting can't go dark while you replace it
Moving clinical reporting off SSRS/SQL Server onto Microsoft Fabric. Clinic staff run their day on those reports, so the new stack was built alongside the old one and cut over at the end — on two Lambdas I wrote. One carries the incremental stream: changes leave DynamoDB, ride Kinesis, and land in Fabric, which keeps reporting current. The other backfills history, writing NDJSON into Azure Blob Storage for Fabric to ingest, with Step Functions orchestrating the run. Live changes and years of history are different problems, so they got different machinery.
appointment dashboard
Built for receptionists, not for a generic staff user
Real-time status board for the clinic floor. Every patient appointment carries a status — arrived, with technician, with MD, no show — and reception needs that picture at a glance across the full day, not buried in a chart. The engineering was the smaller half: this was the first feature where I owned the design requirements directly, working with a UI designer and a project manager to turn what clinic staff actually needed into something shippable. The heaviest users are receptionists, and building for them specifically is what made it land.
scope
Three years of full-stack feature ownership across the React/TypeScript/MobX frontend and the AWS backend — Lambda, DynamoDB, CDK — with infrastructure changes made in coordination with the team's CDK owners.