Artifact from the field
School telehealth architecture
A detailed view of authority, record custody, policy decisions, interfaces, exceptions, and handoffs in a hypothetical school-telehealth system.
Provenance
Based on Cole Lyons's individual Johns Hopkins 655.662 final project, submitted August 15, 2025. Original course PDFs, grading material, instructor comments, course prompts, and institutional marks are not reproduced.
Authors: Cole A. Lyons
Ownership: Cole A. Lyons
Version
Architecture v1.0; reviewed July 14, 2026. Trade-study values come from the August 2025 academic project.
The system boundary is the engineering object. The school, family, treating clinician, clinical record, vendors, and applicable law each retain authority that a coordination product cannot absorb. The proposed system must instead name what crosses each edge, which decision remains external, what evidence accompanies the exchange, and where an exception goes.
The design is hypothetical and nondeployed. No school district, school, provider, payer, government agency, vendor, patient population, or pilot participated. The architecture records Cole's August 2025 academic decisions and verification plans; it does not establish legal compliance, clinical safety, production readiness, vendor endorsement, or measured outcomes.
The original academic working title was CommonHealth Philadelphia. This project has no relationship to The Commons Project's unrelated CommonHealth service.
The service boundary covers non-emergency school telehealth. Existing school and clinical emergency procedures, 911, emergency medical services, standing emergency medication orders, and immediate stabilization remain outside the proposed system.
Proposed academic architecture · August 2025
Authority stays at the edges
The coordination layer assembles context, evaluates proposed policy rules, opens the encounter, and records the handoff. It does not become the school, the family, the treating clinician, the clinical record, or the law.
-
External participants
Student and guardian
Provide identity context, symptoms, participation, permission, and communication preferences.
-
School-controlled environment
Health staff, SIS, identity, network, and devices
Supplies the student context, on-site workflow, school identity claims, device observations, and local constraints.
-
Proposed system boundary
Coordination layer
- assembles a source-labeled encounter packet;
- requests policy, eligibility, and responsibility decisions;
- creates the media session and routes device data;
- tracks exceptions, acknowledgements, and handoff status.
-
External clinical authority
Treating clinician and authoritative EHR
The clinician retains professional responsibility. The EHR remains the system of record for the treating organization.
Outside the designed system
Policy and authority decisions
Applicable law, district and provider policy, guardian or student authority, clinician responsibility, and service-specific rules determine what may proceed.
Proposed evidence: the policy version, inputs, decision, reason, and time—not a claim of legal validation.
External infrastructure
Vendor and media services
CPaaS/WebRTC media, messaging, identity services, and telehealth devices operate under their own systems, contracts, and failure modes.
Proposed evidence: session identifiers, delivery receipts, device provenance, service status, and exceptions.
Optional, separately governed pattern
Managed longitudinal record
Durable platform custody appears only if an arrangement assigns legal basis, retention, correction, access, portability, breach response, source authority, and transition responsibility.
- Information path
- Source-labeled intake, encounter context, clinical response, acknowledgement, and follow-up.
- Decision path
- Authentication, authority, permission, assent, treatment consent, disclosure, eligibility, and clinician responsibility remain distinct.
- Exception path
- Denials, missing authority, network failure, unsafe conditions, and incomplete handoffs return to a named human or external procedure.
- Evidence path
- Provenance, audit events, consent records, policy versions, receipts, and verification outcomes show what happened without becoming the underlying authority.
Assumptions, authority, and custody
The table spells out the assumptions behind each connection. “Proposed” describes Cole's academic design. “External authority” identifies the person, institution, record, policy, or source that the system would have to respect. “Verification status” describes a planned test or unresolved deployment obligation; none of these checks were executed in a live environment.
| Domain | Design status | Source authority | Permission or decision state | Record custody | Verification status |
|---|---|---|---|---|---|
| Student and guardian | External participants | Guardian relationship, student identity and service-specific authority would come from applicable records, policy, and law | Advance permission, student assent or participation, minor-consent exceptions, treatment consent, and disclosure authorization remain distinct | No platform custody assumed | Proposed state and exception tests; no real participants or authority decisions |
| School-controlled environment | External operating domain | School identity provider and SIS are proposed sources for identity claims, roster, guardianship context, and enrollment | School role, purpose, service, device, network, and local policy constrain access | School retains only authorized and required school records | Proposed identity, roster, device, network, and failure-path tests |
| Coordination layer | Proposed component | Receives source-labeled inputs; does not originate family, school, clinical, or legal authority | Requests policy decisions and carries the result, reason, policy version, provenance, and handoff state | Coordination evidence only under the default model | Component, integration, system, and acceptance tests were planned, not run in deployment |
| Policy decision point | Proposed component and test target | Current law, district/provider policy, service rules, authority evidence, eligibility, and clinician responsibility | Authentication is separate from guardian authority, assent, treatment consent, disclosure authorization, eligibility, and clinician responsibility | Records the proposed decision evidence; does not create the underlying authority | Jurisdiction-specific legal and policy review plus allow, deny, expiry, revocation, and exception tests required |
| Treating clinician | External clinical authority | Treating organization and responsible clinician | Eligibility and clinician responsibility must be established for the specific service and student location | Professional responsibility remains with the treating clinician | Directory and licensure checks are proposed requirements, not verified facts |
| Authoritative EHR | External record authority | Treating organization's clinical record | Exchange depends on purpose, authorization, role, and receiving-system rules | Remains the authoritative clinical record | Proposed FHIR R4 contract, provenance, acknowledgement, and reconciliation tests |
| Vendor and media services | External infrastructure | Vendor service state, device metadata, contractual evidence, and service documentation | Access depends on tenant, session, role, contract, and policy | Vendors retain only the custody assigned by a future agreement | Availability, media, firewall, quota, security, BAA, portability, and exit tests remain future obligations |
| Optional managed record | Separately governed optional pattern | Assigned district/provider arrangement and source-labeled contributors | Requires an explicit legal basis and rules for retention, correction, access, portability, breach response, and transition | Custody exists only if separately assigned | Not part of the default coordination-only design; would require a new governance and verification plan |
Permission, consent, and representation are different objects
The design keeps concepts separate because each answers a different question:
- Authentication supplies an identity claim; it does not prove guardian relationship or legal authority.
- Guardian or student authority depends on status, jurisdiction, service, purpose, and the authoritative source for that relationship.
- Parental permission and student assent describe participation in an ongoing arrangement and encounter; they are not interchangeable with treatment consent.
- Treatment consent concerns care. Disclosure authorization concerns which information may move, for what purpose, to whom, and for how long.
- Eligibility and clinician responsibility determine whether the service and responsible professional fit this encounter.
- FHIR representation can carry a Consent, Encounter, Observation, Provenance, or AuditEvent. A resource does not itself make the legal or runtime decision.
- Runtime policy decisions apply versioned rules to source-labeled inputs and return allow, deny, or human-review states.
- Provenance and audit events record sources, actors, transformations, access, and outcomes. Record authority still belongs to the relevant school or treating organization.
- Verification outcomes show whether a proposed requirement passed a test; this project contains plans and targets, not deployment validation.
The design draws on FHIR R4 Consent, FHIR Provenance, FHIR AuditEvent, OpenID Connect, SAML 2.0, and the federal FERPA/HIPAA school-health-record guidance. Applying them to a live service would still require legal, policy, technical, and security review.
The August 2025 trade-study record
Cole chose the criteria, weights, evaluative scores, totals, and selections for three academic trade studies. The available project materials include criterion definitions and weights plus final weighted totals and ranks. They do not include a per-alternative criterion score matrix, underlying price sheet, uncertainty interval, or citation mapped to every score.
Each result below is a dated design decision, not current procurement advice. A real procurement would require a new study using current requirements, pricing, security evidence, support performance, roadmaps, contract terms, and stakeholder review.
1. Telehealth hardware and peripheral kits
| Criterion | Weight | August 2025 utility definition or assumption |
|---|---|---|
| Clinical capability and quality | 20% | Highest utility required the specified sensor set plus strong validation evidence; missing required sensors reduced utility. |
| Data quality and reliability | 5% | Detailed device specifications and clinical-grade performance were favored over vague or below-target evidence. |
| Integration and FHIR compliance | 20% | Native FHIR R4 read/write scored above a proprietary API; no programmatic integration scored lowest. |
| Privacy and security | 15% | The rubric looked for explicit healthcare and school-data posture, BAA availability, encryption, and audit capability. These were due-diligence criteria, not findings of compliance. |
| Device management and usability | 10% | Purpose-built hardware, battery life, and centralized fleet management were favored. |
| Three-year total cost | 10% | The source defined inverse-linear normalization from the lowest to highest cost but did not preserve the vendor cost inputs. |
| Training burden and support | 5% | Short training and continuous support scored above longer training or limited support. |
| Availability and lead time | 5% | In-stock delivery under two weeks scored highest; delays and supply risk reduced utility. |
| Vendor viability and experience | 10% | Organizational stability and K–12 experience were favored; maturity and acquisition risk were penalized. |
| Rank | Named alternative | Weighted total | August 2025 disposition |
|---|---|---|---|
| 1 | TytoCare Pro Smart Clinic | 0.916 | Selected academic direction; higher total cost was the principal recorded risk. |
| 2 | AMD Global Telemedicine Deployable Kit | 0.794 | Fallback only if pricing and roadmap commitments changed the decision. |
| 3 | Let's Talk Interactive Medium Rugged Kit | 0.455 | Not selected. |
| 4 | Nonagon Care N9+ | 0.440 | Not selected. |
| 5 | CureCompanion Portable Kit | 0.356 | Not selected. |
The source's ±20% sensitivity sweep on clinical capability and integration kept TytoCare first in the tested scenarios. That result does not address undisclosed cost inputs or every source uncertainty. Cole's rationale favored the strongest recorded combination of clinical capability, standards alignment, and supportability. The mitigation was to negotiate education pricing, standardize spares, and stage rollout. AMD remained conditional on a multi-year roadmap, FHIR depth, support terms, and an exit path.
2. Consent and eligibility engine
| Criterion | Weight | August 2025 utility definition or assumption |
|---|---|---|
| Policy expressiveness | 20% | Dynamic school-health and healthcare policy handling scored above workaround-driven approaches. |
| Audit and log depth | 15% | Built-in append-only or verifiable logging scored above database logging that would require hardening. “Immutable” was a rubric label, not a validated property. |
| Three-year total cost | 15% | The rubric used cost bands from under $200,000 to over $600,000; vendor inputs were not preserved in the surviving table. |
| Implementation time | 10% | Under four months scored highest; more than twelve months scored lowest. |
| Integration effort | 10% | Modern APIs and existing connectors scored above custom adapters or closed integration. |
| Parental experience | 10% | An out-of-box multilingual experience scored above a fully custom interface or no parent-facing capability. |
| Vendor risk | 10% | Lower lock-in and maturity risk scored above high lock-in or immature offerings. |
| Runtime performance | 5% | The academic target favored a policy response below 5 ms at p99; no runtime test was performed. |
| FHIR Consent support | 5% | Native representation scored above an adapter or incompatible approach. |
| Rank | Named alternative | Weighted total | August 2025 disposition |
|---|---|---|---|
| 1 | Buy — CampDoc | 0.805 | Selected academic direction, subject to portability, API, pricing, and policy due diligence. |
| 2 | Buy — OneTrust | 0.640 | Runner-up, conditional on explicit school-record commitments. |
| 3 | Configure — Open Policy Agent with a custom shell | 0.465 | Not selected. |
| 4 | Build in-house | 0.410 | Not selected. |
The source's ±20% sweep on policy expressiveness, audit/log depth, and total cost kept CampDoc first in the tested scenarios. Cole's rationale favored time to implementation, the recorded parent experience, and the study's total-cost judgment. Those are academic evaluations pending current legal, technical, security, and contractual review—not evidence that a vendor satisfied FERPA, HIPAA, performance, or deployment requirements.
3. Telehealth orchestration architecture
| Criterion | Weight | August 2025 design concern |
|---|---|---|
| Video quality and resilience | 15% | Low latency, adaptive media, and recovery from changing network conditions. |
| FHIR read/write depth | 15% | Deep FHIR R4 exchange for encounter, observation, order, and document workflows. |
| SSO and identity alignment | 15% | Separate school and provider identity domains with explicit federation. |
| Firewall traversal and NAT success | 15% | Reliable session establishment in constrained school networks. |
| Administration and observability | 10% | Multi-tenant operations, metrics, logs, quotas, and failure visibility. |
| Total cost over 12–36 months | 10% | Licenses, usage, infrastructure, and internal staffing; the source preserved no cost figures. |
| Implementation time | 5% | Time mattered but remained secondary to architecture fit. |
| Scheduling and licensure features | 5% | Required but expected to need school-specific logic. Licensure remained a proposed check. |
| Compliance and BAA posture | 5% | A binary due-diligence baseline, not a finding of compliance. |
| Vendor and ecosystem risk | 5% | Lock-in, roadmap, quota, and pricing exposure. |
| Rank | Named alternative | Weighted total | August 2025 disposition |
|---|---|---|---|
| 1 | Hybrid — CPaaS media plus custom orchestrator | 0.825 | Selected academic architecture. |
| 2 | EHR-native telehealth API | 0.610 | Not selected. |
| 3 | CPaaS only | 0.460 | Not selected. |
| 4 | Self-hosted WebRTC — Jitsi | 0.285 | Not selected. |
The source's ±20% sweep on video quality, FHIR depth, identity alignment, and firewall traversal kept the hybrid first. The selection bought media and traversal capability while building the school-specific scheduling, consent, SIS/EHR, and dual-identity coordination seam. Recorded mitigations included an EHR adapter with contract tests and version-pinned mappings, plus a media-provider abstraction, tenant quotas, and observability.
What a deployment would still have to prove
The verification plan moved from component tests to integration, system, and acceptance stages: policy decisions and revocation; roster and identity mapping; FHIR contract and provenance; media quality and firewall traversal; device payload attribution; acknowledgement and reconciliation; exception routing; tenant isolation; recovery; and human handoff. The source also proposed a progression from off-network checks to a lab, school sandbox, and eventual pilot.
That sequence is a plan. No school sandbox, clinician integration, student-volunteer exercise, or pilot is represented here as completed. A deployment would also require current counsel, district and provider policy, clinical authority, vendor due diligence, security review, accessibility testing, current interface conformance, and explicit record-custody agreements.