Goldie Health is a digital health platform created to support agencies identifying and engaging individuals at risk of opioid overdose. The platform helps response teams deliver personalized care by integrating with electronic patient care reports (ePCRs), electronic health records (EHRs), local community referral networks. It addresses barriers to treatment by factoring in social determinants of health such as housing instability and financial constraints. By offering tailored, adaptive care pathways and ensuring compliance with HIPAA and 42 CFR Part 2 regulations, Goldie enables secure data sharing and collaboration among healthcare providers and social service organizations.
100%
Multi
100%
Opioid response teams lacked a standardized, digital solution for managing caseloads and tracking interventions. Many relied on spreadsheets and paper records, limiting their ability to measure what works and improve outcomes. Without centralized systems, policies couldn't be tested at scale, and data remained fragmented across counties.
Goldie needed to centralize critical workflows into a single secure platform that would work reliably both online and offline, support regional differences, and maintain full HIPAA and 42 CFR Part 2 compliance.
Akveo handled end-to-end development including system architecture, backend and frontend development, real-time messaging, mobile offline sync logic, and infrastructure deployment on AWS.
To achieve HIPAA compliance the application follows these key practices:
The application supports data segregation at the company (tenant) level. This segregation makes it impossible for users from one tenant to access data from another tenant.
The tenant to which a user belongs is determined at of authentication.
Logical data separation is implemented at the database level: each connection is established separately for each tenant and access to foreign data is restricted both at the API level and at the database level. At the API level, it is verified whether the user belongs to the requested tenant. At the database level, restrictions are enforced through separate connections and access control mechanisms.
For file storage the application uses AWS. Data segregation at this level is ensured by a strict storage structure. Tenant file access rights are verified at the API level.
The application is based on the offline-first principle. This means that the app should work offline. Data synchronization with the global system state occurs when an internet connection is available.
To implement this approach, it was decided to divide the API into two types: read and write APIs.
The read API works only online. It loads up-to-date data onto the user's mobile device, where the data is stored in a local database. This ensures that the information remains accessible regardless of internet availability, allowing the app to work in offline mode. To optimize performance when handling large amounts of data, partial synchronization is used: with each subsequent request, only the changes that occurred in the global system state while the device was offline are downloaded.
The write API is designed to collect and store user actions while offline. These actions are recorded in the device’s database in the same order they were performed. As soon as the application connects to the internet, all saved operations are sent to the server and executed sequentially. If the application is online, data is sent directly to the server without being stored locally.
SMS chat per tenant (with real-time updates), email sending on behalf of tenants, and push/in-app notifications for status changes and task assignments.
For data analysis, the application integrates with third-party services, providing access to data in a format suitable for analysis. These systems use the provided data to visually display various business process metrics.
.png)
We have helped over 200 businesses grow their value and improve how they work through better software.
