PROPELOO

HEALTHCARE APP / HEALTH TECHNOLOGY

Build healthcare software where compliance is built in, not bolted on.

PROPELOO engineers healthcare applications — from patient-facing apps and clinical workflow systems through EHR integration, telehealth infrastructure and the compliance architecture that satisfies HIPAA, HL7 FHIR and regional health data regulations. Healthcare software fails in two ways: poor clinical UX that clinicians work around, and compliance failures that generate regulatory action. We prevent both.

A HIPAA violation costs $100 to $50,000 per violation. A breach affecting 500+ patients requires public reporting and HHS investigation. Healthcare compliance is not optional.

Healthcare data is the most regulated, most sensitive and most targeted category of personal data. A mental health app that syncs patient notes to an unencrypted S3 bucket is a HIPAA violation — even if no breach occurs. An EHR integration that logs patient IDs in application logs violates the minimum necessary principle. A telehealth platform that uses a non-BAA consumer video service violates HIPAA even if the call content is encrypted. These are not edge cases — they are the most common compliance failures in health tech. PROPELOO designs healthcare software where HIPAA compliance is architectural: PHI is identified and protected at the data model level, every third-party vendor has a signed BAA, and access to patient data is logged and auditable.

The healthcare application engineering stack.

Healthcare applications have distinct engineering requirements across clinical, compliance and integration domains.

System Layers

  • Patient Engagement Layer: Patient portal, appointment booking, health records access, secure messaging, push notifications
  • Clinical Workflow Layer: Clinical documentation, care plan management, task assignment, care coordination
  • Telehealth Layer: Video consultation, async messaging, prescription management, remote monitoring
  • Integration Layer: EHR integration (HL7 FHIR/HL7 v2), lab systems, pharmacy, wearables, billing systems
  • Compliance Layer: HIPAA technical safeguards, audit logging, BAA management, breach detection

Core Technical Capabilities

  • Patient Portal & Engagement

    Patient-facing web and mobile app — appointment booking and reminders, health record access (lab results, prescriptions, visit summaries), secure HIPAA-compliant messaging, consent management and health history intake forms.

  • Telehealth Platform

    HIPAA-compliant video consultation via Twilio Video or Daily.co (BAA-available), async video messaging, clinical notes during/after consultation, e-prescribing integration and virtual waiting room with queue management.

  • EHR Integration

    HL7 FHIR R4 API integration with Epic, Cerner, Athenahealth, Meditech and other major EHRs. SMART on FHIR for app authorisation. HL7 v2 messaging for legacy systems. FHIR resources for patients, appointments, observations, conditions and medications.

  • Clinical Workflow System

    Clinical documentation with SOAP note templates, structured data capture (vital signs, lab results), care plan management, task assignment and handoff workflows for multi-disciplinary care teams.

  • Remote Patient Monitoring

    Wearable device integration (Apple Health, Google Fit, Withings, Dexcom CGM), vital sign trend analysis, automated alert generation for out-of-range values and care team notification workflows.

  • HIPAA Compliance Architecture

    PHI inventory and classification, encryption at rest and in transit for all PHI, access controls (role-based, minimum necessary), audit logging for all PHI access, BAA management for all vendors handling PHI and incident response procedures.

How we think about healthcare software.

In healthcare, the cost of a compliance failure is not a refund or an apology — it is regulatory investigation, civil monetary penalties and in severe cases, criminal liability. Design for compliance first.

  • PHI must be identified before it can be protected

    Protected Health Information (PHI) under HIPAA is any individually identifiable health information — name, date of birth, address, account numbers, device identifiers, photographs, and health or payment information. Every field in your data model must be classified: is this PHI? The classification drives encryption requirements, access control granularity, retention limits and audit logging. You cannot protect PHI you have not identified.

    Axiom:

  • Every vendor who touches PHI needs a BAA

    A Business Associate Agreement is a legal contract required by HIPAA for any vendor that processes, stores or transmits PHI on your behalf. This includes: your cloud provider (AWS, GCP, Azure all offer BAAs), your email provider (if you send any PHI in emails), your video conferencing provider, your error monitoring service (if errors include PHI), your analytics platform (if you track any PHI). Using Google Analytics on a page that displays patient names violates HIPAA — Google does not sign healthcare BAAs.

    Axiom:

  • Minimum necessary access is a legal requirement

    HIPAA requires that access to PHI is limited to the minimum necessary for the specific task. A billing clerk should access billing-related PHI, not clinical notes. A nurse should access the patients on their unit, not all patients. A patient should access only their own records. This is not just good security practice — it is a HIPAA technical safeguard requirement. Implement it in the data access layer, not just in the UI.

    Axiom:

  • HL7 FHIR is the future of healthcare data exchange

    The ONC 21st Century Cures Act mandates that healthcare providers and payers support FHIR R4 APIs for patient data access. Building new integrations on HL7 v2 (the legacy messaging standard) creates integration debt. SMART on FHIR provides the authorisation framework for apps to access patient data from EHR systems with patient consent. New healthcare applications should speak FHIR natively.

    Axiom:

The healthcare engineering decisions that define compliance and clinical utility.

Each choice has compliance implications that must be understood before implementation.

  • Cloud infrastructure?

    Impact: AWS for most healthcare applications — most extensive HIPAA-eligible service list, largest healthcare customer base and ecosystem. All three major clouds offer BAAs and HIPAA-eligible service configurations. Self-hosted only for specific regulatory requirements.

    • AWS with BAA — most healthcare-ready, HIPAA-eligible services, largest healthcare ecosystem
    • GCP with BAA — strong for ML/AI health applications, good healthcare tooling
    • Azure with BAA — strong for Microsoft-heavy healthcare orgs (many hospitals run Azure AD)
    • Self-hosted — maximum control, full operational burden, required for some government healthcare contracts
  • Telehealth video infrastructure?

    Impact: Daily.co or Twilio Video for custom telehealth integrations — both offer BAAs and HIPAA-compliant configurations. Zoom for Healthcare for simpler deployments where the Zoom UI is acceptable. Never use consumer Zoom or Google Meet without a BAA.

    • Twilio Video (BAA available) — flexible, HIPAA-compliant, developer-friendly
    • Daily.co (BAA available) — purpose-built for healthcare, simpler API
    • Zoom for Healthcare (BAA available) — familiar UI, higher cost
    • Doxy.me (BAA available) — purpose-built telehealth platform
    • Custom WebRTC — maximum control, significant engineering cost
  • EHR integration approach?

    Impact: FHIR R4 + SMART on FHIR for new integrations — it is the regulatory direction of travel and increasingly available in major EHRs. HL7 v2 for integrations with hospitals that do not yet support FHIR. Epic App Orchard for Epic-heavy target markets where native integration provides better clinical workflow integration.

    • HL7 FHIR R4 API — modern standard, growing EHR support, required for ONC compliance
    • HL7 v2 messaging — legacy standard, still dominant in hospital settings, complex to parse
    • SMART on FHIR — app authorisation layer on top of FHIR, patient-mediated access
    • Direct EHR vendor API (Epic App Orchard, Cerner SMART) — vendor-specific, better support for complex workflows
  • PHI storage approach?

    Impact: Field-level encryption for the most sensitive PHI fields (SSN, MRN, diagnosis codes) within a HIPAA-compliant managed database with encryption at rest. Separate PHI vault pattern for applications that process very sensitive mental health or substance abuse records with additional HIPAA 42 CFR Part 2 requirements.

    • Encrypted database (field-level for sensitive fields) — granular, performance overhead
    • Database encryption at rest (disk-level) — simpler, less granular
    • HIPAA-compliant managed service (AWS Aurora with encryption) — managed, BAA-covered
    • Separate PHI vault — PHI in isolated service, references only in application DB
  • Patient identity management?

    Impact: Healthcare-specific IAM (Okta with BAA or AWS Cognito in HIPAA configuration) for most healthcare apps. SMART on FHIR for clinical apps where EHR authentication is appropriate. Consumer SSO (Google, Apple) only if the provider signs a BAA — check before integrating.

    • Internal patient identity system — full control, requires deduplication logic
    • Healthcare-specific IAM (Okta Health, Amazon Cognito with HIPAA BAA) — managed, HIPAA-eligible
    • EHR-sourced identity (SMART on FHIR) — patient authenticates via EHR, federated identity
    • Consumer identity (Google/Apple SSO) — familiar for patients, BAA availability varies by provider
  • Audit logging granularity?

    Impact: Application-level audit logging to an immutable store (CloudTrail, external logging service) is the minimum HIPAA requirement. Log: who accessed, what patient record, what data, when, from where. Retain for 6 years minimum (HIPAA requirement). Field-level logging for the highest-sensitivity fields (mental health records, HIV status).

    • Application-level logging (who accessed what when) — minimum HIPAA requirement
    • Database-level audit logging — captures all queries, high storage volume
    • Field-level access logging — logs which specific PHI fields were accessed
    • External audit log service (immutable) — tamper-proof, regulatory grade

What PROPELOO builds.

  • Telehealth Platform

    HIPAA-compliant video consultation with waiting room management, clinical notes, e-prescribing integration, patient portal and scheduling — web and mobile.

  • Patient Portal

    Patient-facing portal with appointment booking, health record access (FHIR), lab results, medication history, secure messaging and consent management.

  • Clinical Workflow App

    Clinician-facing mobile and web app for documentation, care plan management, task assignment, handoff communication and outcome tracking.

  • Remote Patient Monitoring

    Wearable integration platform — Apple Health/Google Fit, CGM devices, blood pressure monitors — with alert rules, care team notifications and longitudinal trend display.

  • Health Insurance Platform

    Member portal with benefits display, claims submission and tracking, prior authorisation management, provider directory and EOB download.

  • Mental Health App

    Consumer mental health app with HIPAA-compliant therapy session booking, mood tracking, therapist messaging, crisis resource integration and 42 CFR Part 2 compliant records handling.

The healthcare engineering stack.

Compliance, clinical integration and patient experience each require specific tooling.

  • Core Backend

    Stack: Node.js / Python (FastAPI), PostgreSQL (encrypted at rest), Redis (HIPAA-compliant session), AWS (BAA-covered services), Terraform

  • FHIR & EHR

    Stack: HAPI FHIR (open source server), AWS HealthLake (FHIR repository), Mirth Connect (HL7 v2), SMART on FHIR, Microsoft FHIR Server

  • Telehealth

    Stack: Twilio Video (BAA), Daily.co (BAA), Vonage Video API (BAA), Zoom Healthcare SDK

  • Patient Identity

    Stack: AWS Cognito (HIPAA BAA), Okta (BAA), Auth0 Healthcare, SMART on FHIR OAuth

  • Mobile

    Stack: React Native, Apple HealthKit, Google Health Connect, Expo, Notifee (HIPAA-aware push)

  • Compliance & Monitoring

    Stack: AWS CloudTrail (audit log), Datadog (HIPAA BAA), Sentry (HIPAA config), Custom PHI access logger

Healthcare security is defined by HIPAA technical safeguards — not general best practices.

HIPAA specifies required and addressable technical safeguards. Non-compliance carries civil and criminal penalties.

  • Encryption of PHI

    HIPAA requires encryption of PHI at rest and in transit as an addressable safeguard (required unless you can document a compelling reason not to, which in practice means it is required). AES-256 at rest, TLS 1.2+ in transit. Field-level encryption for the most sensitive PHI. Encryption key management via AWS KMS with separate keys per customer for data isolation.

  • Access Controls

    Unique user identification (no shared logins), automatic session logout after inactivity, role-based access aligned to minimum necessary principle, emergency access procedure documentation and physical access controls for any on-premises components.

  • Audit Controls

    Hardware, software and procedural mechanisms to record and examine activity in information systems containing PHI. Who accessed what patient record, when, from which IP address, what actions were performed. Logs immutable and retained 6 years minimum. Regular audit log review.

  • Transmission Security

    Guard against unauthorised access to PHI transmitted over electronic networks. TLS 1.2+ for all data in transit. No PHI in URL parameters (visible in server logs). No PHI in email bodies without encryption. Secure messaging instead of SMS for PHI communications.

  • Business Associate Agreements

    Every vendor who processes, stores or transmits PHI on your behalf requires a signed BAA. Maintain a BAA inventory. Regularly review vendor BAA status. A BAA does not transfer responsibility — you remain liable for vendor breaches if you did not exercise due diligence in vendor selection.

  • Breach Response

    HIPAA Breach Notification Rule requires notification of affected individuals within 60 days of discovering a breach involving unsecured PHI. Breaches affecting 500+ individuals require simultaneous notification to HHS and media. Breach response plan must be documented and tested annually.

From concept to HIPAA-compliant healthcare app.

  1. 01. Compliance Scoping

    HIPAA applicability assessment, PHI inventory, BAA requirements, cloud infrastructure selection and compliance architecture design.

  2. 02. Security Architecture

    Encryption design, access control model, audit logging specification, BAA vendor list and incident response planning.

  3. 03. Core Application Development

    Backend API, database with PHI encryption, authentication and authorisation with HIPAA-compliant session management.

  4. 04. Clinical Integration

    EHR integration (FHIR R4), HL7 v2 message processing, lab system integration and pharmacy integration.

  5. 05. Patient & Clinician UI

    Patient portal, clinician app, telehealth integration, push notifications and mobile app development.

  6. 06. Compliance Verification

    HIPAA technical safeguard audit, penetration testing, BAA review, audit log verification and documentation.

  7. 07. Launch & Ongoing Compliance

    HIPAA-compliant launch, monitoring, annual risk assessment support and breach response readiness.

Frequently Asked Questions

What makes an app subject to HIPAA?

HIPAA applies to covered entities (healthcare providers, health plans, healthcare clearinghouses) and their business associates (companies that handle PHI on their behalf). A consumer wellness app that does not interact with a covered entity is generally not subject to HIPAA. A telehealth app used by a covered entity provider is subject to HIPAA. An app that connects to an EHR to access patient data is subject to HIPAA. A mental health app that connects users with licensed therapists is subject to HIPAA. If uncertain, assume HIPAA applies — the cost of compliance is far lower than the cost of non-compliance.

What is a BAA and who needs one?

A Business Associate Agreement is a contract required by HIPAA between a covered entity (or business associate) and any third party that processes, stores or transmits PHI on their behalf. You need BAAs with: your cloud provider (AWS, GCP, Azure all offer them), your database vendor if managed, your email provider if you send PHI in emails, your video conference provider for telehealth, your logging/monitoring vendor if logs contain PHI, your analytics platform if you track any PHI. If a vendor refuses to sign a BAA, you cannot use them for any service that involves PHI.

What is HL7 FHIR and why does it matter?

HL7 FHIR (Fast Healthcare Interoperability Resources) is the modern healthcare data exchange standard. It defines a REST API specification and data formats (resources) for healthcare data — Patient, Observation, Condition, Medication, Appointment, etc. The ONC 21st Century Cures Act mandates FHIR R4 API support for EHR vendors, making it the standard path for accessing patient data. New healthcare app integrations should use FHIR R4 where available. SMART on FHIR adds OAuth 2.0 authorisation for app access to EHR data with patient or provider consent.

Can we use AWS for HIPAA-compliant healthcare apps?

Yes. AWS offers a Business Associate Agreement and designates specific services as HIPAA-eligible. Key HIPAA-eligible AWS services: EC2, RDS, S3, Lambda, Cognito, KMS, CloudTrail, CloudWatch, DynamoDB, ECS, EKS, SQS. Not all AWS services are HIPAA-eligible — check the AWS HIPAA compliance page before using any service in a PHI-processing workload. The BAA covers the AWS infrastructure; you are responsible for configuring it correctly (encryption enabled, access controls, logging).