School Telehealth as a Systems Engineering Problem

1. Assignment and initial framing

I developed this design as my individual final project for Johns Hopkins 655.662 — Introduction to Healthcare Systems Engineering in Summer 2025 and submitted it on August 15, 2025. Dr. Matthew Montoya instructed the course and iteratively reviewed and refined the work, while I authored the requirements, architecture decisions, trade-study criteria, weights, scores, and verification plan.

The assignment gave me a broad access problem: imagine a Philadelphia citywide public-health environment where schools could help families coordinate ordinary primary-care collaboration, non-emergency clinician consultation, chronic monitoring, and condition-specific follow-up. Then engineer the system that would have to make an encounter possible. The purpose was to address health needs that distract students, contribute to absence, burden families, or fragment routine and chronic care—without turning those motivations into modeled outcomes.

My first pass underdeveloped the trade study and struggled to identify where the system began and ended. Dr. Montoya’s instruction pushed me to express the boundary as engineered inputs, outputs, constraints, and environmental conditions, shifting the project toward a more demanding question: what does each student, guardian, school, clinician, EHR, media vendor, and applicable policy know, control, and retain?

This is a hypothetical, nondeployed academic design. No school district, school, provider, payer, government agency, vendor, patient population, or pilot participated. It does not report implementation, patient care, measured outcomes, or institutional endorsement.

2. Non-emergency student and family environment

A student cannot simply open a room and become a telehealth encounter. The school first has its own duty of care, emergency procedure, identity environment, records, devices, network, staff roles, and family relationships. The treating organization has separate professional responsibility, eligibility rules, clinical workflow, and record custody. The family brings authority and participation questions that a school roster or authenticated account cannot settle by itself.

Non-emergency operating environment

Four domains, four kinds of authority

1. 01

   Student and family

   Identity, guardian relationship, permission, assent, and questions enter from outside the designed system.

2. 02

   School environment

   Staff, devices, network, SIS, emergency procedures, and authorized school records remain school-controlled.

3. 03

   Coordination layer

   Source-labeled context, policy results, provenance, session state, exceptions, and handoff status move through the proposed service.

4. 04

   Treating clinician

   The responsible clinician evaluates and treats; the treating organization’s EHR remains the authoritative clinical record.

Emergency response, 911, emergency medical services, standing emergency orders, and immediate stabilization stay outside this proposed service.

The proposed service therefore covers scheduled and unscheduled non-emergency coordination. Emergency response, 911, emergency medical services, standing emergency medication orders, and immediate stabilization remain outside its boundary. That exclusion is an interface requirement: the designed path must recognize when it no longer owns the next action.

3. CONOPS and engineered system boundary

The concept of operations places a school health staff member with the student and a treating clinician at the other end of a mediated visit. The coordination layer assembles source-labeled context, requests a policy decision, creates a session only after the relevant gates pass, carries device and encounter state, and records whether the clinical handoff was acknowledged.

CONOPS and system boundary

The coordination layer carries evidence; it does not inherit authority

Inputs

Identity claims, guardian context, school role, service request, device provenance, eligibility, clinician responsibility, policy version, and network state.

Proposed system of interest

Coordinate a permitted session, preserve the source of every assertion, record decisions and exceptions, and hand clinical output to the treating organization.

Outputs and handoffs

Allow, deny, or human-review result; session state; source-labeled observations; family communication state; clinical handoff acknowledgement; provenance and audit events.

Clinical record

Treating clinician EHR

School record

Only authorized school records

Coordination record

Permissions, provenance, decisions, exceptions, and handoff status

The default record model is deliberately narrow: the treating clinician’s EHR remains the authoritative clinical record, the school retains only the school records it is authorized to hold, and the coordination layer carries permissions, provenance, policy results, session and exception evidence, and handoff status without becoming the clinical chart.

A managed longitudinal record is a possible separately governed pattern, not part of the default design. It would need an assigned custodian, legal basis, access and correction rules, retention schedule, breach response, portability, transition plan, and a new verification program before it could enter an architecture decision.

4. Parental permission, student assent, and authority states

The first architecture drafts made it too easy to collapse every precondition into “consent.” The review work sharpened a more useful model: each state answers a different question, comes from a particular authority, can expire or be revoked on different terms, and needs its own exception path.

Authority-state review

A successful login answers only the first question

1. 1

   Authentication

   Who presented an identity claim?

2. 2

   Authority

   Who may act for this student, for this service, here and now?

3. 3

   Permission + assent

   May the student participate in the school arrangement and encounter?

4. 4

   Treatment consent

   May the clinician provide the proposed care?

5. 5

   Disclosure authorization

   Which information may move, to whom, for what purpose and duration?

6. 6

   Eligibility + responsibility

   Is the service available, and which clinician owns the encounter?

FHIR can represent Consent, Encounter, Observation, Provenance, and AuditEvent. Representation is separate from the runtime policy decision, record authority, and verification outcome.

Authentication supplies an identity claim without establishing guardian relationship or student authority. Parental permission and student assent govern participation in an arrangement and encounter, with service-specific minor-consent exceptions remaining possible; treatment consent concerns care, while disclosure authorization controls information movement. Condition-specific clinical orders or an Individualized Healthcare Plan can shape the school context without replacing encounter-specific treatment authority, and eligibility and clinician responsibility add further gates.

Every encounter therefore has to reevaluate the student, requested service, current guardian or student authority, permission and participation state, responsible clinician, disclosure purpose, and destination record. FHIR resources can represent some of this evidence, while a runtime policy decision applies versioned rules to the actual encounter. Provenance and audit events record what happened; neither makes a school or clinical record authoritative.

These are August 2025 design assumptions and proposed control requirements. The project does not claim HIPAA or FERPA compliance, verified licensure, immutable audit, safety, production readiness, or deployment validation.

5. Inspecting the architecture

School, family, clinical, policy, record, and vendor authority meet at contested edges. Each exchange has to identify what enters, who supplied it, what decision may be made from it, what evidence travels with it, who owns the receiving record, and what happens when the exchange fails.

Supporting documents

Inspect the boundary as an engineering object

The school, family, coordination layer, policy function, clinician, EHR, and vendors retain different authority. Each exchange names its assumptions, custody, verification status, evidence, exceptions, and handoffs; the trade studies include every value available from the August 2025 project.

Architecture and trade studies

School telehealth architecture

Trace family, school, coordination, policy, clinician, EHR, optional record, vendor, evidence, exception, and handoff boundaries without reproducing course-controlled material.

Inspect the architecture →

6. August 2025 trade study

I ran three weighted trade studies as dated academic decisions. The available project materials include every criterion, weight, named alternative, weighted total, rank, rationale, assumption, and sensitivity note shown here. They do not include a per-alternative criterion matrix, vendor price sheet, or uncertainty interval.

The recorded sensitivity sweeps changed the highest-weight criteria by plus or minus 20 percent. The leading alternative remained first in all three studies. That is robustness within Cole’s August 2025 scoring model, not current procurement advice. A real decision would require current requirements, pricing, security evidence, roadmaps, contracts, support performance, and stakeholder review.

7. Risks, interfaces, and staged verification

The interface register is where architecture promises become testable: school identity and roster inputs need source and freshness rules; device observations need timestamps and provenance; policy responses need the rule version, inputs, result, reason, and review state; and FHIR exchange needs contract, acknowledgement, reconciliation, and failure behavior. Media services likewise need firewall, quality, tenant, quota, and exit tests, while family communication needs a defined purpose, destination, delivery state, and exception owner.

Staged verification plan

Increase environmental realism without skipping a gate

1. 01

   Component

   Exercise identity, policy, consent, provenance, and interface behavior in isolation.

2. 02

   Integration

   Test device, media, policy, school-network, and sandbox EHR contracts together.

3. 03

   System

   Run allow, deny, expiry, revocation, outage, exception, reconciliation, and handoff scenarios.

4. 04

   Acceptance

   Require named owners and evidence before any future go/no-go decision; this project reached planning, not deployment validation.

Planned scenarios included denial before room creation, expiry and revocation, student or guardian exceptions, clinician-responsibility failure, school-network degradation, device-data mismatch, unavailable media infrastructure, failed EHR acknowledgement, reconciliation, and human handoff. A failed gate remains failed; the plan does not treat a successful video connection as evidence that the encounter was authorized or correctly recorded.

Risks were likewise assigned to boundaries: mistaken authority, stale eligibility, unverified clinician context, data in the wrong record, vendor dependency, school-network limits, inaccessible family communication, ambiguous exception ownership, and loss of provenance during transformation. These are design risks and test targets, not findings from a deployed service.

8. The lesson: boundaries reveal omissions

My main lesson was that a system boundary is an omission-finding tool. Put the student, family, school, clinician, EHR, vendor, and law on one page and the unanswered questions appear at the edges: who may decide, which source is authoritative, what evidence crosses, who receives an exception, and how the next system confirms the handoff.

The trade-study process applied the same discipline to choice and exposed criteria I had initially missed: security, replaceability, sustainability, vendor lock-in, supportability, and failure handling. Weighting those criteria made my assumptions and omissions inspectable within a dated academic model whose scores were never meant to be timeless.

That changed how I understand systems engineering. The strongest architecture admits what the coordination layer cannot decide, preserves the authority of surrounding institutions, and makes the transfer between them inspectable.

The project’s original working title, CommonHealth Philadelphia, is unrelated to The Commons Project’s CommonHealth service. Its enduring work is the boundary argument: coordinating an encounter does not confer authority over it.