https://github.com/pendekardata/hipaa/releases
Welcome to the hipaa repository. This project provides a HIPAA and GDPR compliant, ready-to-run parse-server setup that works with PostgreSQL or MongoDB. It includes a modern admin dashboard (parse-hipaa-dashboard) and is designed to be compatible with ParseCareKit. The goal is to give developers a solid base for building BaaS apps that handle sensitive health data with strong governance and clear data flows.
Key ideas
- A secure Parse Server core that can store data in PostgreSQL or MongoDB.
- A HIPAA-ready dashboard for governance, auditing, and user access control.
- A smooth pathway to include ParseCareKit integrations.
- Thorough guidance for deployment in Docker, cloud, or on-prem environments.
Why this project matters
- HIPAA and GDPR demand strict controls on data access, auditing, encryption, and data lineage.
- A ready-to-run platform helps teams accelerate compliant health apps while reducing boilerplate work.
- The design favors clear data boundaries, explicit access rules, and observable behavior.
Embracing the topics that drive this project
- backend-as-a-service, carekit, cloud, docker, gdqr, graphql, mbaas, mongodb, parse-dashboard, postgre, singularity
Overview of the project
- Core: A Parse Server instance configured to use either PostgreSQL or MongoDB as the primary data store. It includes hooks and policies to help enforce privacy and security requirements.
- Admin: A web-based dashboard named parse-hipaa-dashboard. It provides roles, permissions, data access request management, and activity auditing.
- API surface: A GraphQL layer (where applicable) to enable flexible queries and efficient data access patterns.
- Compliance layer: Features to support HIPAA and GDPR obligations. Examples include access controls, audit trails, data export, and secure data handling.
Releases
- The Releases page hosts builds and assets for various platforms. See the Releases page for installers, image tags, and upgrade notes. Visit the Releases page for assets and download instructions: https://github.com/pendekardata/hipaa/releases
Table of contents
- Quick start
- What you get
- Architecture and design
- Data models and privacy controls
- Compliance and security posture
- ParseCareKit integration
- Deployment patterns
- Development guide
- Testing and quality
- Observability and monitoring
- Extending and customizing
- Roadmap and future work
- Contributing
- Licensing and governance
- FAQ
Quick start
A pragmatic path to a running instance
-
Prerequisites
- Docker or Docker Compose installed on your host
- Access to a PostgreSQL or MongoDB server
- Node.js is optional for local development, but Docker is recommended for first run
-
Single-node quick start (Docker)
- Create a simple docker-compose.yml that wires Parse Server to a database and the dashboard to the server.
- Bring up the stack and wait for the services to become healthy.
-
Multi-node patterns
- Use a managed PostgreSQL or MongoDB service in the cloud for production deployments.
- Run Parse Server and the dashboard as separate services for scalability and isolation.
-
Basic workflow
- Start services
- Create an admin user for the dashboard
- Connect a client app to the Parse Server
- Verify that operations on PHI data are logged and auditable
Sample docker-compose snippet
- This is a minimal, illustrative example to help you get started. Adjust environment variables and volumes to fit your environment.
services: postgres: image: postgres:15 container_name: hipaa-postgres environment: POSTGRES_USER: hipaa POSTGRES_PASSWORD: securePass123 POSTGRES_DB: hipaa volumes: - postgres-data:/var/lib/postgresql/data
mongodb: image: mongo:6 container_name: hipaa-mongo volumes: - mongo-data:/data/db
parse-server: image: pendekardata/hipaa:latest container_name: hipaa-parse-server environment: - PARSE_SERVER_DATABASE_URI=postgresql://hipaa:securePass123@postgres:5432/hipaa - PARSE_SERVER_DATABASE_ADAPTER=typeorm - PARSE_SERVER_MASTER_KEY= masterKeyHere - PARSE_SERVER_APP_ID=hipaa - PARSE_SERVER_JAVA_SCRIPT_KEY=jsKey depends_on: - postgres ports: - "1337:1337"
parse-hipaa-dashboard: image: pendekardata/hipaa-dashboard:latest container_name: hipaa-dashboard environment: - HIPAA_DASHBOARD_APP_ID=hipaa-dashboard - HIPAA_DASHBOARD_SERVER_URL=http://parse-server:1337/parse depends_on: - parse-server ports: - "8080:8080"
volumes: postgres-data: mongo-data:
If you want a guided, production-grade setup, consult the documentation in the repository and tweak the compose file to add:
- TLS termination for Parse Server and the dashboard
- Separate persistence for logs and audit trails
- Secrets management for credentials
- Health checks and restart policies
Architecture and design
High-level view
- Parse Server core
- Database adapters: PostgreSQL and MongoDB
- Core business logic for data modeling, permissions, and hooks
- Cloud Code (server-side logic) support
- GraphQL layer (optional)
- A GraphQL gateway that surfaces common read patterns and reduces the risk of overexposure
- Admin dashboard (parse-hipaa-dashboard)
- Role-based access control (RBAC)
- Data access requests (DAR) workflow
- Audit trails and event logging
- Export and data minimization tools
- Compliance and security features
- Encryption at rest (leveraged by underlying databases)
- TLS in transit
- Fine-grained access controls for PHI
- Auditable changes and immutable logs
- CareKit compatibility
- Data models and endpoints aligned to support health data flows used by ParseCareKit
- Sync patterns that ease integration with care coordination apps
Key components in detail
- Parse Server core
- Modular design to swap out the database adapter without large rewrites
- Hooks and triggers for data access, validation, and privacy checks
- Webhooks for external systems and care workflows
- Admin dashboard (parse-hipaa-dashboard)
- Graphical interface for managing users, roles, and permissions
- Workflows for approving access requests to PHI
- Dashboarding that reveals who accessed what data and when
- Compliance layer
- Data minimization by default; only the needed fields are exposed to clients
- Data export tools for subject access requests
- Audit logging that covers reads, writes, and administrative actions
- API surface
- REST/Parse Server endpoints for mobile and web apps
- Optional GraphQL layer to support advanced querying
- Clear separation between app data and meta data
Data models and privacy controls
Foundational data governance
- PHI and PII handling
- Sensitive fields are treated with extra care. Access to PHI is logged and constrained by roles.
- Data masking strategies for user interfaces when full PHI is not needed.
- Access control model
- Roles: admin, clinician, researcher, data subject, auditor
- Permissions: read, write, delete, export, grant-access, revoke-access
- Data subjects can request data access or deletion under policy
- Auditing and logging
- Every create, read, update, delete (CRUD) operation is recorded with a timestamp and actor
- Logs are stored in an auditable store and can be exported to a secure SIEM if needed
- Data export and deletion
- Subject Access Requests (SAR) can be fulfilled with a portable export
- Data deletion respects retention policies and ensures traceability of deletions
- Encryption and key management
- Data at rest relies on database-level encryption features
- Data in transit uses TLS and secure certificates
- Key management strategies for rotating keys and revoking access
Compliance posture: HIPAA and GDPR
HIPAA-oriented features
- Access control
- Role-based access to PHI
- Minimal-privilege model for every client and service
- Auditability
- Audit logs capture who accessed PHI and what was done
- Tamper-evident log storage for integrity
- Data integrity
- Operation validation, checks, and reconciliation mechanisms
- Breach readiness
- Logging and alerting for suspicious access patterns
- Secure incident response workflows
GDPR-oriented features
- Data subject rights
- Data access, correction, portability, and erasure workflows
- Data minimization
- Only necessary data is stored and exposed
- Data transfers
- Clear boundaries for cross-border data movement and transfer safeguards
- Accountability
- Clear ownership and traceability of data handling actions
ParseCareKit compatibility
How to connect and use with care workflows
- Data models
- Align patient entities, encounters, observations, and care plans with ParseCareKit schemas
- Sync and events
- Set up event triggers to sync necessary data to care apps
- Use webhooks to notify care coordinators about changes in care plans
- Security alignment
- Ensure that care workflows respect RBAC and data minimization
- Audit care activities and export data when required
Deployment patterns
Docker and container-first deployment
- Build and run
- Use the provided Docker images for Parse Server and dashboard
- Mount persistent volumes for data stores
- Use environment variables to configure database connections and keys
- Compose-based orchestration
- A single docker-compose.yml can stand up the stack for development and testing
- For production, split services into separate stacks and add TLS, secrets, and monitoring
Cloud-native deployment
- Kubernetes
- Deploy Parse Server as a Deployment or StatefulSet
- Use a managed database service for PostgreSQL or MongoDB
- Ingress/TLS termination for external access
- RBAC and network policies to enforce least privilege
- Serverless and managed services
- Use managed databases and app runners to reduce maintenance overhead
- Integrate with CI/CD pipelines for automated testing and deployments
Development patterns
Local development
- Use a local MongoDB or PostgreSQL instance
- Run Parse Server and dashboard in separate processes
- Use mock data for PHI fields to test privacy controls
- Validate that access controls work as intended and that audit logs capture all actions
Testing and quality
- Unit tests for core business logic
- Integration tests for database adapters
- End-to-end tests covering user flows in the dashboard and data access requests
- Linting and style checks to keep code readable and consistent
Observability and monitoring
What to monitor
- Event rate and API latency
- Error rates for data access and export operations
- Security alerts such as unusual access patterns
- Resource usage (CPU, memory, I/O) for the Parse Server and dashboard
Tools to use
- Prometheus for metrics
- Grafana for dashboards
- Centralized log collection for audit trails
- SIEM integration for security incidents
Extending and customizing
Adding new features
- Add a new Parse Cloud Code function to enforce a business rule
- Extend the dashboard with new RBAC roles or extra compliance controls
- Introduce a new data export format for SAR requests
Integrating with other systems
- Connect to external health data sources via webhooks
- Use GraphQL to expose specific, aggregated views to client apps
- Build adapters to support other databases beyond PostgreSQL and MongoDB
Security considerations
Security posture
- Enforce least privilege for every service
- Protect PHI with strict access controls
- Audit all data operations
- Encrypt data at rest and in transit
- Keep dependencies up to date and track CVEs
Common security patterns
- Role-based access control (RBAC) for dashboard and API
- Authorization checks at every data access point
- Clear separation of duties for administrators and clinicians
- Regular rotation of credentials and keys
- Secure logging and tamper-evident logs
Detailed setup and configuration
Database options
- PostgreSQL
- Reliable, relational data model support
- Strong encryption options at rest
- Rich tooling for backups and restores
- MongoDB
- Flexible schema for evolving data models
- Built-in encryption at rest and in transit
- Scales well for writes and reads in distributed setups
Environment variables and configuration
- PARSE_SERVER_DATABASE_URI
- For PostgreSQL: postgresql://user:password@host:port/db
- For MongoDB: mongodb://user:password@host:port/db
- PARSE_SERVER_DATABASE_ADAPTER
- 'typeorm' for PostgreSQL, 'mongoose' for MongoDB
- PARSE_SERVER_MASTER_KEY
- Strong, kept secret
- TLS and certificates
- Provide TLS certificates to ensure encrypted traffic
- CORS and allowed origins
- Restrict origins to trusted clients
Admin dashboard capabilities
What the dashboard offers
- User and role management
- Data access request (DAR) workflows
- Audit trail exploration with filters
- Data export and import helpers
- Health checks for services
- Configured alerts for unusual activity
Using the dashboard
- Start the dashboard after Parse Server is ready
- Create an admin account and assign roles
- Define a policy for PHI access
- Review access requests and grant or deny access
- Use export tools to satisfy SAR requests
Migration and upgrade guidance
Keeping things current
- Review release notes for breaking changes
- Preserve database migrations and schema changes
- Test upgrades in a staging environment before production
- Back up data before performing upgrades
- Validate all critical workflows post-upgrade (login, access controls, data export)
Migration steps
- Back up both PostgreSQL or MongoDB data
- Update container images to the new tag
- Apply any database migrations required by the new release
- Re-run integration tests and security checks
- Redeploy with minimal downtime and verify connectivity
Contributing
How to contribute
- Follow the project’s contributing guidelines
- Open issues to discuss major changes before coding
- Write tests for new features
- Document new behavior in the README or docs
- Maintain backward compatibility where possible
Code quality
- Write clear, maintainable code
- Add unit and integration tests
- Keep dependencies up to date
- Document public APIs and key design decisions
Documentation and learning resources
Where to find more
- In-repo docs: guides on deployment, security, and usage
- API references for Parse Server, GraphQL surface, and dashboard APIs
- Tutorials showing end-to-end flows with ParseCareKit
Roadmap and future work
What’s ahead
- More granular access controls for PHI fields
- Enhanced SAR workflows and automation
- Expanded GraphQL capabilities for common health workflows
- Better integration with care coordination platforms
- Improved observability and anomaly detection
Licensing and governance
Code governance
- Licenses used in dependencies
- Compliance with security advisories for third-party libraries
- Clear guidelines for contribution and usage
FAQ
Common questions
- Is this project suitable for production?
- Yes, with proper deployment, monitoring, and policies in place.
- Can I use PostgreSQL or MongoDB interchangeably?
- The core supports both; choose the adapter and connection that fit your needs.
- How do I export data for SAR requests?
- Use the dashboard export tools and ensure data is delivered in a portable format.
Releases and assets
Downloads from the Releases page
- The official releases page hosts build artifacts for different environments. You can download the assets suitable for your platform from the Releases page. See the Releases page for assets and upgrade notes: https://github.com/pendekardata/hipaa/releases
Further notes
- Explore the repository’s examples and test data to speed up your setup.
- The dashboard and server are designed to work together, but you can swap components with your own implementations if needed.
- Ensure that you apply your organization’s security policies and regulatory requirements to any real deployment.
Appendix: example commands and tips
Helpful commands
- Start services with Docker Compose
- docker-compose up -d
- View service logs
- docker-compose logs -f
- Stop services
- docker-compose down
- Test database connectivity
- docker exec -it hipaa-postgres psql -U hipaa -d hipaa -c 'SELECT 1;'
- Validate that the dashboard is reachable
- Open http://localhost:8080 in your browser
Tips for robust deployments
- Use secrets management for credentials
- Enable TLS termination at a load balancer or ingress
- Harden Postgres or MongoDB with proper access controls
- Regularly audit logs and alert on anomalous access
- Maintain a tested backup and disaster recovery plan
Images and visuals
- Visuals help explain the data flow and governance model. Consider including:
- A diagram of the data flow from client to Parse Server to the database
- A diagram showing the access control model
- A screenshot of the dashboard with RBAC and DAR features
- For visuals, you can reference publicly available healthcare data flow diagrams or create your own diagrams that reflect the architecture described here.
Note on maintenance
- The project is designed to evolve with compliance needs and platform changes.
- Regular updates to dependencies and security patches help keep the system resilient.
- Community feedback guides improvements in the dashboard, APIs, and integration points.
Appendix: glossary
- HIPAA: Health Insurance Portability and Accountability Act, a US regulation governing PHI protection.
- GDPR: General Data Protection Regulation, a European privacy law affecting data handling and subject rights.
- PHI: Protected Health Information, any information about health status or health care that can identify an individual.
- PII: Personally Identifiable Information, data that can identify a person.
- SAR: Subject Access Request, a request to access, correct, or delete data.
Final notes
- The repository delivers a ready-to-run Parse Server environment with a HIPAA- and GDPR-focused governance layer, suitable for healthcare applications and care coordination tools.
- It is built to be compatible with ParseCareKit workflows and to integrate with modern cloud and container ecosystems.
- For updates, upgrades, and new assets, see the Releases page: https://github.com/pendekardata/hipaa/releases
Relevant links
- Releases: https://github.com/pendekardata/hipaa/releases
- Documentation and guides (in-repo): see the docs directory within the hipaa repository for deeper dives into deployment, security patterns, and data models.