Created by Ping192

MedCloud is a working reference architecture for medical professionals, practices, and clinics evaluating modern, secure, and compliance-conscious cloud infrastructure.

It demonstrates how patient data, appointments, prescriptions, laboratory results, telehealth workflows, billing, physical security, IoT devices, and immutable audit logging can operate together on AWS through a carefully designed architecture.

MedCloud is not presented as a generic software package or a one-size-fits-all product. It is a showcase of the infrastructure patterns Ping192 builds and adapts for clinics, surgical centers, dental practices, veterinary offices, and multi-site medical groups.

Why MedCloud Exists

Many medical practices still rely on disconnected systems, aging servers, outdated access-control equipment, and physical infrastructure that receives little visibility or monitoring.

A typical clinic may have:

• An electronic health record system that functions as a black box.

• Door-access systems running on aging local machines.

• Camera systems writing to a DVR that is rarely reviewed.

• Patient data distributed across several disconnected applications.

• Manual workflows for prescriptions, lab results, billing, and reporting.

• Limited audit visibility when sensitive records are accessed.

MedCloud demonstrates what a modern practice environment can look like when infrastructure, security, compliance, and physical devices are treated as one connected system.

The reference design is built around several principles:

• Patient-record access is logged and encrypted.

• Audit data is append-only and retained according to the design requirements.

• Doors, sensors, dispensers, cameras, and lab gateways are treated as first-class network devices.

• Actions are represented as events that can be traced, audited, and reviewed.

• Access is restricted through least-privilege permissions.

• High-risk workflows fail closed instead of silently proceeding.

• Costs are managed without sacrificing operational visibility.

The reference production environment is estimated at approximately $738 per month in AWS infrastructure costs, although actual costs vary based on region, usage, data volume, retention, traffic, device count, and service configuration.

What MedCloud Demonstrates

MedCloud is designed for a small-to-medium medical clinic. It models infrastructure for:

• Patient records.

• Appointments.

• Prescriptions.

• Laboratory results.

• Telehealth workflows.

• Billing and insurance claims.

• Physical access control.

• Pharmacy dispensers.

• Occupancy monitoring.

• Environmental sensors.

• Camera and video workflows.

• Immutable compliance records.

• Emergency response procedures.

The architecture is built within an AWS environment using strict identity boundaries, private networking, encrypted storage, event-driven workflows, and controlled access to protected health information.

The design targets three major constraints:

1. HIPAA-conscious architecture: Protected Health Information (PHI) must be encrypted, access-controlled, logged, and auditable.

2. Connected physical infrastructure: Doors, sensors, dispensers, cameras, and lab machines must be treated as part of the overall system.

3. Cost-aware operations: The production AWS environment is designed to remain below approximately $1,000 per month under the stated reference workload.

The reference implementation includes approximately:

• 40 distinct operations.

• 18 Lambda functions.

• 5 customer-managed KMS keys.

• 8 DynamoDB tables.

• 22 EventBridge rules.

• 156 registered IoT devices.

• Production and development cost models.

• Security, compliance, deployment, and operations documentation.

Architecture Principles

Every Action Is an Event

Nothing important should happen without an observable event. EventBridge provides a central event bus for patient access, prescriptions, lab results, emergencies, appointments, device activity, and other operational domains.

This approach creates:

• Consistent audit trails.

• Replayable workflows.

• Clear event ownership.

• Easier troubleshooting.

• Better incident analysis.

• A shared model for understanding system behavior.

Audit Is Append-Only

The audit ledger is deliberately separated from ordinary application data.

The compute role can append records to the audit ledger but cannot read them back. A separate auditor role is required to query audit history. This reduces the impact of a compromised application role and limits the ability of application workloads to alter or conceal their own history.

Audit information is also archived to Amazon S3 with Object Lock in compliance mode for the required retention period.

Physical Infrastructure and Cloud Infrastructure Are One System

Door controllers, occupancy sensors, pharmacy dispensers, environmental sensors, and lab gateways are connected through AWS IoT Core using per-device certificates and mutual TLS.

These systems are not treated as secondary equipment. They are part of the security, safety, and operational model.

Optimize for Operational Sanity

Cost optimization matters, but the goal is not to reduce every line item at the expense of reliability or visibility.

MedCloud prioritizes:

• Clear ownership.

• Observable workflows.

• Practical security controls.

• Maintainable infrastructure.

• Reasonable operating costs.

• Documented recovery procedures.

Fail Closed

If a high-risk validation step fails, the workflow stops.

Examples include:

• No prescription when controlled-substance validation is unavailable.

• No emergency evacuation authorization without the required second confirmation.

• No access when role or MFA validation fails.

• No unlock when the two-person rule cannot be satisfied.

Failing closed prevents infrastructure failures from silently becoming security or safety failures.

Network Topology

The reference design uses:

• A VPC with the CIDR range 10.0.0.0/16.

• Three availability zones in production.

• Private subnets for compute workloads.

• NAT Gateway access for approved outbound integrations.

• VPC endpoints for AWS services such as S3, DynamoDB, KMS, Secrets Manager, and CloudWatch Logs.

• AWS WAF protecting the operator API.

• Facility CIDR allowlists for restricted administrative access.

• No public compute resources.

External APIs—such as payment, insurance, or regulatory integrations—are routed through controlled egress paths rather than allowing unrestricted network access from application workloads.

AWS Services

Compute

Data Stores

Eventing

Identity and Security

Patient Record Access

When an authorized clinician views a patient record, the request follows a controlled sequence:

Clinician selects a patient record
        ↓
AWS WAF checks the source IP
        ↓
API Gateway validates the JWT
        ↓
Lambda validates role and access rules
        ↓
DynamoDB retrieves the record
        ↓
Audit event is appended
        ↓
AppSync subscription updates the console

The access-control model is enforced server-side rather than in the user interface. This means removing a button from the UI is not treated as a security control.

The system also supports role-based field redaction:

• Doctors may access clinical information based on their role.

• Nurses may access permitted clinical and vital information.

• Administrators may access approved operational and billing fields.

• Auditors may review audit records but cannot view clinical records through the application role.

Access denials are logged as auditable events. A failed attempt to view restricted information is treated as important as a successful access.

Immutable Audit Logging

The audit trail is the central accountability mechanism in MedCloud.

Each relevant event is written to:

1. An encrypted DynamoDB audit ledger.

2. An S3 archive protected with Object Lock in compliance mode.

The audit writer is intentionally restricted:

• It can append records.

• It cannot query the audit ledger.

• It cannot decrypt the audit KMS key.

• It cannot modify or delete existing history.

• Only the separate auditor role can read audit records.

A simplified permissions model looks like this:

Combined with S3 Object Lock and CloudTrail monitoring, this design creates a stronger audit boundary than simply storing application logs in the same database used by the application.

Prescription Workflow

Prescription processing follows a fail-closed model.

When a clinician submits a prescription:

1. The system verifies that the user has a prescribing role.

2. The medication is checked against the controlled-substance list.

3. DEA or equivalent authorization validation runs before the prescription is written.

4. If validation fails or the external service is unavailable, the prescription is rejected.

5. If approved, the prescription is stored.

6. The pharmacy is notified.

7. An IoT dispenser command may be issued where applicable.

8. The workflow is audited.

The most important design rule is that validation occurs before persistence. If authorization fails, no incomplete prescription remains in the database requiring cleanup.

The system also stores whether an item was classified as controlled, allowing compliance teams to query and review controlled-substance activity efficiently.

Any production deployment would require validation of the applicable regulatory process, external integrations, medical governance, and legal requirements. The example architecture is not a substitute for regulatory approval or professional compliance review.

Critical Laboratory Results

Laboratory devices can publish results through AWS IoT Core. A processing function then:

1. Parses the incoming laboratory result.

2. Stores the raw result in encrypted Amazon S3.

3. Compares the value with configured critical thresholds.

4. Sends urgent notifications when a critical value is detected.

5. Writes a dedicated critical-value event.

6. Writes a standard result-received event.

Critical alerts can be routed to:

• PagerDuty.

• SMS.

• Email.

• Staff dashboards.

• On-call teams.

• Other approved notification systems.

The raw result is stored before alert processing so that the original data is preserved even if a later notification or processing step fails.

Thresholds are intended to be configurable through a controlled configuration store, allowing approved clinical or compliance personnel to update them without requiring an application deployment.

Emergency Code Blue Workflow

Emergency workflows require rapid communication and strong authorization controls.

When an authorized staff member triggers an emergency event:

1. MFA is verified again in the Lambda function.

2. A second confirmation is required for evacuation events.

3. The second confirmation must come from a different user.

4. An IoT emergency message is published to facility devices.

5. Staff receive alerts through SNS.

6. A virtual conference bridge is created.

7. The complete event is written to the audit ledger.

A dead-letter queue and retry policy are used for the EventBridge target so that failures are visible and recoverable.

The two-person rule is enforced in backend code—not only in the user interface. This ensures a user cannot bypass the requirement by manipulating the client application.

Atomic Appointment Booking

Appointment creation uses DynamoDB transactional writes to ensure that the appointment and patient record are updated together.

The process includes:

• Availability checking.

• Conditional appointment creation.

• Updating the patient’s next appointment.

• Conflict handling if another user books the same slot.

• Notification of the patient and provider.

• Audit logging.

If two users attempt to book the same appointment slot simultaneously, the conditional transaction allows only one operation to succeed. The other receives a conflict response.

This prevents:

• Double-booked appointment slots.

• Orphaned patient references.

• Appointment records without corresponding patient updates.

• Inconsistent scheduling state.

HIPAA-Oriented Controls

These controls are architectural measures, not a claim that the system is automatically HIPAA compliant.

Compliance depends on the complete environment, including:

• Policies and procedures.

• Workforce training.

• Risk assessments.

• Vendor agreements.

• Business Associate Agreements.

• Incident-response procedures.

• Access reviews.

• Physical controls.

• Configuration management.

• Ongoing monitoring and audits.

IoT Device Security

MedCloud models 156 connected devices across the clinic.

Every device receives its own certificate. Shared credentials are not used.

Door Controllers

Door controllers are treated as high-risk devices. The design includes:

• Per-device mutual TLS certificates.

• Backend enforcement of the two-person rule.

• Hardware-level fire-alarm override.

• Automatic release after a defined period without renewal.

• Audit events for every unlock.

• Restricted command topics.

• Device-level identity and authorization.

Occupancy Sensors

Occupancy data can be aggregated through EventBridge and Lambda, stored in DynamoDB, and displayed through an AppSync subscription for near-real-time operator visibility.

Pharmacy Dispensers

Pharmacy dispensers receive MQTT commands after an authorized prescription is written.

The workflow includes:

• Prescription persistence before the command.

• Device acknowledgement.

• QoS 1 delivery.

• Idempotency using the prescription identifier.

• Audit events for successful and failed commands.

Security Controls

IAM Boundaries

The application compute role is deliberately limited:

• It may append audit events.

• It may not read the audit ledger.

• It may not decrypt the audit key.

• It may use only the encryption operations required for its assigned data.

• It may not alter key policies.

• It may not administer identity or infrastructure resources.

WAF Configuration

The operator API uses a default-block posture with:

• Facility CIDR allowlisting.

• Rate limiting.

• AWS-managed core rules.

• SQL injection protection.

• Known-bad input protection.

• Logging and alerting for blocked requests.

VPC Endpoints

AWS service access is routed through private VPC endpoints where practical, including:

• Amazon S3.

• DynamoDB.

• AWS KMS.

• Secrets Manager.

• CloudWatch Logs.

• Amazon SNS.

• EventBridge.

NAT Gateway access is reserved for approved external APIs, such as payment, insurance, or regulatory integrations.

Estimated AWS Costs

The following is a reference estimate for the production environment:

Actual costs will vary depending on region, volume, retention, network traffic, device count, video processing, log volume, and usage patterns.

The Rekognition Sampling Decision

Video analysis is one of the largest potential cost drivers.

At one frame every five seconds across 24 cameras, the estimated Rekognition cost is approximately $180 per month.

At 24 frames per second across the same 24 cameras, the estimated cost could rise to approximately $18,000 per month.

That represents a potential 100x difference. Sampling is therefore one of the most important cost decisions in the reference architecture.

Build and Operating Costs

The AWS infrastructure bill is only one part of the total cost of ownership.

Reference estimates include:

• Architecture and compliance scoping: 4–8 weeks.

• Reference implementation: 3–6 months.

• Integration with cameras, doors, PBX systems, and existing software: 2–4 months.

• Typical one-time build range: $250,000–$600,000.

• 24/7 monitoring and incident response: $80,000–$200,000 annually.

• HIPAA compliance audits: $20,000–$50,000 annually.

• Firmware and integration maintenance: $40,000–$120,000 annually.

The AWS bill may represent only a small portion of the total ownership cost. People, compliance, clinical governance, physical integration, support, and maintenance generally account for the majority of the operational investment.

Deployment

The reference repository includes manual deployment instructions and partially scaffolded Infrastructure as Code directories.

A typical deployment order is:

1. Create KMS keys.

2. Create S3 buckets and enable Object Lock on the audit bucket.

3. Create DynamoDB tables with Point-in-Time Recovery.

4. Configure the Cognito user pool and groups.

5. Create IAM roles for compute, readers, and scheduling.

6. Deploy Lambda functions.

7. Configure EventBridge buses and rules.

8. Register IoT devices and policies.

9. Deploy API Gateway and WAF.

10. Configure the AppSync GraphQL API.

11. Create CloudWatch dashboards and alarms.

12. Configure the HealthLake datastore.

13. Validate logging, access controls, backups, and recovery procedures.

Terraform modules and AWS CDK stacks are included as planned or partially scaffolded components and require completion, review, testing, and adaptation before production use.

Operations and Runbooks

The reference architecture includes operational runbooks for:

• Emergency Code Blue response.

• Audit-log queries.

• KMS key rotation.

• Incident handling.

• Access review.

• Recovery procedures.

• Post-incident validation.

Each runbook should document:

• When to use the procedure.

• Who is authorized to execute it.

• Required commands and approvals.

• Rollback steps.

• Escalation contacts.

• Post-incident checks.

• Required audit records.

A reliable cloud architecture is not complete when the deployment succeeds. It is complete when qualified operators can understand, maintain, troubleshoot, and recover it.

What MedCloud Is Not

MedCloud is:

• Not a commercial software product.

• Not a turnkey EHR.

• Not automatically HIPAA compliant.

• Not a substitute for legal or compliance review.

• Not production-ready without facility-specific adaptation.

• Not a replacement for clinical governance.

• Not a guarantee of regulatory approval.

• Not necessarily suitable for every practice or workload.

HIPAA compliance is a shared responsibility. A clinic would still need appropriate policies, audits, risk assessments, workforce training, vendor agreements, BAAs, incident-response processes, and legal review.

The architecture is a working reference designed to demonstrate patterns, tradeoffs, and implementation approaches.

Who This Is For

Ping192 built MedCloud as a showcase for:

• Clinic owners evaluating cloud modernization.

• Practice managers planning a technology migration.

• CTOs and technical leads at medical groups.

• Compliance officers reviewing technical controls.

• Surgical centers.

• Dental practices.

• Veterinary clinics.

• Pharmacies and specialty-care facilities.

• Multi-site medical organizations.

• Healthcare operators managing connected physical infrastructure.

If your organization is tired of aging systems, disconnected applications, weak audit visibility, or manual workflows, MedCloud provides a starting point for a more modern infrastructure discussion.

Ping192 can adapt the reference design to your:

• Facility.

• EHR.

• Cameras.

• Doors.

• Pharmacy equipment.

• Lab systems.

• State-specific requirements.

• Compliance posture.

• Budget.

• Operational model.

Visit Ping192 on GitHub to explore the project and discuss a facility-specific implementation.

Contributing

MedCloud is a reference architecture. Security, compliance, documentation, and design feedback are welcome.

Potential areas for improvement include:

• Terraform and AWS CDK Infrastructure as Code.

• Door-controller firmware examples.

• Integrations with common EHR platforms.

• Multi-region failover.

• Larger-clinic cost optimization.

• Additional healthcare interoperability patterns.

• Expanded incident-response documentation.

• More comprehensive device simulations.

The project is intended to improve through review, testing, and practical feedback from engineers, clinicians, compliance professionals, and healthcare operators.

License

MedCloud is released under the MIT License. It may be used, forked, and adapted. Attribution is appreciated but not required.

Acknowledgments

MedCloud was created by Ping192 with input from clinicians, compliance professionals, and AWS solutions architects. The design reflects practical lessons from building and operating secure, event-driven, cloud-connected systems.

Created by Ping192 · Showcase for medical professionals and practices · Version 1.0 · Last updated September 14, 2026

Meta Description

MedCloud by Ping192 is a cost-aware AWS reference architecture for modern medical clinics, featuring HIPAA-oriented controls, encrypted PHI, immutable audit logging, IoT devices, secure workflows, and event-driven infrastructure.

#MedCloud #Ping192 #AWSHealthcare #MedicalCloud #HealthcareCloud #HIPAACompliance #HIPAACloud #HealthcareCybersecurity #PatientDataSecurity #PHISecurity #ProtectedHealthInformation #ImmutableAudit #AuditLogging #AWSHealthLake #AWSLambda #AmazonDynamoDB #AmazonS3 #S3ObjectLock #AWSIoT #MedicalIoT #HealthcareTechnology #ClinicCloudMigration #EHRInfrastructure #HealthcareDevOps #DevSecOps #DataEncryption #AWSKMS #CognitoMFA #IAM #LeastPrivilege #EventDrivenArchitecture #EventBridge #MedicalAppointments #PrescriptionManagement #CriticalLabAlerts #CodeBlue #HealthcareEmergencyResponse #PharmacyAutomation #HealthcareObservability #HIPAAAudit #IncidentResponse #AWSWAF #PrivateVPC #CloudCostOptimization #HealthcareCompliance #TelehealthInfrastructure #MedicalPracticeTechnology #SecureCloud #HealthcareInfrastructure #CloudSecurity