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.

What metricHEALTH does

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.

Scope and scale

Against that backdrop, 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, and a 30 percent reduction in manual testing effort on the same modules. For clinical operations leadership, the weekly spreadsheet export was retired in favour of live dashboards. The rest of this page is the account of how each of those numbers was earned.

Integrations across the clinical data stack

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 three patterns. The right one depends on the latency budget and on what the source system is capable of, and picking the wrong one is expensive in subtle ways rather than obvious ones.

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.

Automating quality so reliability holds

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 test data was harder than the framework. 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.

Dashboards that surface what matters

The third area of my work has been business intelligence: dashboards in Power BI and embedded BI tools that turn raw clinical and operational data into views a manager can act on. The build is SQL data modeling, DAX measure design, and source-system integration, mixed in whatever proportion the underlying storage forces. The visible outcome is unspectacular, and that is the point: the report is always current, so people who used to ask "where is the report" now look at the report.

The Mayor's Innovation Award

In November 2024, at the City of Barrie's Mayor's Innovation Awards, metricHEALTH received the Research and Innovation Contribution award, tied with Georgian College's Department of Research and Innovation. The award recognised work at the intersection of healthcare technology and applied research.

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.

What this work has taught me

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.

What is next

The work continues. The active thread is extending FHIR coverage to newer resource types and pushing the automated test suite into scenarios that span more than one subsystem. Where applied ML fits in the dashboards is the open question I am working on next.

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