Building Healthcare Software at metricHEALTH

I joined metricHEALTH Solutions Inc. as a Software Developer and Data Engineer in April 2024. The work has split roughly into thirds: building integrations that move clinical data between systems, automating quality assurance for software that has to be right the first time, and creating dashboards that surface clinical and operational signals to people who actually act on them. This page describes what that has looked like and what it has produced.

A few engineering and operational markers, recorded internally: 99.9 percent platform uptime, a roughly 25 percent reduction in development cycle time on modules covered by the test automation, a 40 percent improvement in KPI visibility for clinical operations leadership, and a 30 percent reduction in manual testing effort on the same modules.

metricHEALTH is a Barrie-based digital health company building software for healthcare providers, payers, and the patients they serve. The product surface includes patient enrollment and engagement tools, remote monitoring infrastructure, and analytical dashboards for healthcare leadership. The technical surface includes everything that connects those products to the systems that already exist in clinics, hospitals, and home-care programs: electronic health records, laboratory information systems, pharmacy systems, billing systems, and the various proprietary devices that show up in modern care delivery.

Healthcare software is unusual in two ways that shape every engineering decision. First, the data is sensitive in a regulated, legally consequential way. Privacy is not a feature, it is a compliance posture that has to hold across every code path. Second, system reliability is not optional in the way it might be for a marketing site. A patient enrollment endpoint that fails silently is a patient who does not get into the program they were referred for.

A significant portion of my work has been on FHIR-aligned integrations: REST APIs that move data between systems while staying compatible with the HL7 FHIR standard. FHIR matters because it is the lingua franca of modern healthcare interoperability. A system that speaks FHIR can talk to the EHRs, public health registries, and patient-facing applications that have standardized around the same vocabulary.

The integration work has spanned several patterns. Synchronous REST APIs for use cases where a clinician is waiting on a response. Asynchronous webhook-style flows for high-volume bulk transfers. Periodic ETL jobs for systems that do not support push at all. The right pattern depends on the latency budget and the source system's capabilities. Picking the wrong one is expensive in subtle ways: a synchronous API in front of a legacy system that takes 30 seconds to respond will time out under load, and a nightly ETL behind a workflow that needs same-day data will produce a reporting layer nobody trusts.

A specific deliverable I have spent time on is integration with Microsoft Dynamics 365, which one of our enterprise clients uses for case management. The integration moves patient records, care interactions, and outcome data between the clinical platform and Dynamics with field-level mappings that respect the privacy classifications on each side. OAuth handles authentication. Pydantic-style validation gates everything that crosses the boundary. The single most useful pattern in that integration was a normalisation layer between FHIR resources and Dynamics entities so neither system had to know about the other's vocabulary. When Dynamics renamed a field on its end, only the mapping config changed, not the FHIR-side handlers. That kind of layering reads like overkill on the first pull request and pays for itself the third time the source-of-truth schema shifts.

Automated testing in healthcare is a discipline of its own. The cost of a regression that ships to production is high, and the time available for manual testing in a small team is finite. Closing that gap was one of my deliverables. I built a Python and Selenium test framework that runs as part of the CI/CD pipeline on every pull request, executing UI flows and API integration tests against a non-production environment.

The mechanism is the boring part that does the work. Every pull request triggers a Selenium suite that drives the actual UI flows a clinician would touch, alongside API contract tests against the integration endpoints. Failures block merge. The framework runs against a non-production environment that mirrors production schemas, so regressions surface against realistic data shapes rather than against fixtures that have drifted from reality. The cycle-time and manual-effort gains noted above came from this kind of disciplined investment in test infrastructure rather than from heroic individual effort.

The hardest part was not the framework, it was the test data. Synthetic patient records that exercise the realistic edge cases (long names, multi-byte characters in addresses, dates of birth before 1900, missing optional fields, conflicting identifiers across linked records) take real effort to design and longer to maintain. Most flaky tests I have inherited were flaky because the test data was over-clean. A test suite that only covers the polite path is a test suite that ships bugs.

The third area of my work has been business intelligence: building dashboards in Power BI and embedded BI tools that translate raw clinical and operational data into views a manager can act on. The technical work is some combination of SQL data modeling, DAX measure design, and source-system integration, depending on how the underlying data is stored.

The visible outcome is unspectacular: replacing weekly spreadsheet exports with live dashboards that always reflect current data. People who used to ask "where is the report" now look at the report. That is the entire transformation, and it accounts for the bulk of the operational gain noted above.

In November 2024, the City of Barrie awarded the metricHEALTH team the Mayor's Award for Research and Innovation. The award recognised work at the intersection of healthcare technology and applied research, jointly with Georgian College's Research and Innovation Department.

I was part of a small core engineering team that internally went by "The Three Musketeers." The award is a team award, not an individual one, and the recognition reflects work the whole team contributed to: the FHIR integration architecture, the test automation that enabled reliable rapid release cycles, and the clinical dashboards that have actually changed how operational decisions get made.

Three things, all of which transfer beyond healthcare.

Compliance is an architectural constraint, not a checklist. Privacy by design, separation of duties, principle of least privilege, encryption at rest and in transit. These are decisions that have to be made early and then enforced consistently. Bolting them on later is approximately impossible. SOC 2 is a control framework that operationalizes that discipline, and working in a SOC 2 environment has shaped how I think about systems generally.

Test automation is a moral position. In a domain where quality matters, the team's willingness to invest in non-glamorous test infrastructure is the leading indicator of how the system will behave in production. Code coverage is a proxy for that willingness, not a goal in itself.

The hardest integration problem is not technical. It is semantic alignment between systems that were not designed to talk to each other. The technical layer (REST, JSON, OAuth) is mostly standardized. The fields, the codes, the business rules, the workflows: those are where the integration work actually lives. Healthcare interoperability is mostly about being patient with vocabulary mismatches.

The work continues. Active areas include deepening the FHIR coverage for newer resource types, expanding the automated test suite into integration scenarios that span multiple subsystems, and exploring where applied ML can produce signal worth surfacing in the dashboards. The healthcare technology surface keeps expanding faster than any one team can cover, which is the part of this work I keep coming back to.

Recognition video from the Mayor's Award: https://www.youtube.com/watch?v=fwg2f29-Qx8