MedTech startup, Jiseki Health, is a concierge service that helps its clients take control of their health and improve their wellbeing. Their major clients include a well-known electric car manufacturer and several large American insurance companies. Jiseki Health is the first and only “Whole-Person Care” provider that specifically caters to disadvantaged individuals and communities. They operate a full-stack, health-equity, multi-tenant marketplace that addresses all the social determinants of health and takes a person-centered approach to care delivery. The company recognizes the risks associated with standardized care and implements strategies for enhancing the delivery of person-centered care, encouraging greater engagement from its members to participate in healthy behaviors. Members can get access to convenient whole-person care through text, video, voice, WhatsApp, web services, and in-person. Jiseki's platform is the infrastructure for a delivery system for personal care that connects members to virtual care, brick and mortar clinics, and community care settings. The challenge Not long before Jiseki’s team reached out to us, they demoed their communication and coordination service, which aimed to provide telehealth services to large numbers of people. When looking for a technological partner, they focused on finding one that could help them make their demo “real”, make some back-end improvements to allow them to scale up the startup, and build some new features. HealthTech But, their primary goal was to build a dashboard solution and a rules engine to control and generate outbound messaging going to their members, patients, and the providers who interacted with them. The business rules engine would be helpful to their users, including the medical specialists and representatives of the companies registered with the service, the epidemiologists and agents, who would set the rules for messaging to be implemented, and the members of the service and patients who would receive messages. Previously, communication, messaging, and notification processes among the members of the platform were realized manually, via regular text messages, but when several other clients partnered with the service, it became necessary to optimize the process using automated messaging systems. The task Jiseki expected to have a large number of users joining the system. As the main service was the text-based solution for whole-person care, the company wanted to reduce the labor costs and resources needed for an outbound text reach-out. They wanted to have automated messages going out, nudging users to follow up with a particular provider or to take a particular action. So, the rules engine would be used to set the requirements for these outbound messages: if this is ‘true’ and this is ‘true’, send ‘this’ and send it X days after X happens. The task was basically to describe and design the technical solution, suggest the architecture and stack for the messaging rules engine, and develop it from scratch, with the potential for future scaling and versatility. Building the rules engine The client came to us with the idea. We defined the requirements, built up the PRD, and after carefully studying the specification and researching the best practices for an automated messaging system for telemedicine apps, we came up with a solution to implement the rules engine in the most convenient way for users. We co-created the solution with the client, prepared the user flow and user scenarios, drew the dashboard mockups, and developed a Python rule-based engine to execute rules according to a particular algorithm. We determined that there should be three main stages of rules engine functionality: setting the rule, performing an action, and scheduling or choosing the runner (the timeline of when the action should be performed). So, this is an example of how it can work. The providers of medical services make a decision that a certain group of patients living in a certain area or state needs to sign up for a regular health check. Then, the epidemiologist uses the rules engine we developed to input the data and set rules that define this group of patients. Then, they set the task to send an automated message to all members of that defined group, for example: send an SMS message to all female employees, ages 20-35, from a certain company, reminding them to sign up for an examination at the clinic in 7 days. The rules engine fulfills all specified rules and actions, and patients automatically receive helpful messages/notifications. The input data is mainly conversation data, but in the future it will be possible to input notes, assessments, EMR encounters, labs, prescription information, and some demographic and financial overlays. The client was using Druid, a distributed column database, to store all the necessary data. Druid is a very flexible engine that allows for fast ad hoc  queries, so we connected the new messaging engine to the Druid analytics system. API-driven architecture development While the messaging engine development seemed to be pretty straightforward, there were a couple of caveats that needed to be handled carefully. Most of them centered around working with the data via API. For example, we had to make all of the data from the EMR accessible via REST API. But, the only export-possible data format in healthcare is HL7, so we had to focus on streamlining the data exchange process with HL7 API. Using the HL7 FHIR API, we converted the data format into an appropriate format for the messaging engine. Our rules engine design sends a call through the REST API to the company’s service, in order for that service to send a text message to a member. The rules engine alone doesn’t have direct connectivity to an SMS service provider or messaging service. The rule execution includes several API calls at the time that the rule is evaluated to be true. For example, if the messaging engine sends a thank you message, “Thank you for filling out our survey. We'll be with you shortly,” the engine also sends an API call to put the member in the priority list (in the agent dashboard) and creates an alert for the agent. We also implemented mechanisms that allow the organization of an analytical dashboard, based on ELK, to understand how well the rules work and view statistics on the implementation of the rules. So, in future versions, the client will be able to use random or controlled testing and determine the outcomes. The messaging engine rules are applied to all user bases, and new users are added into the system automatically. Everything comes in through API, including the appended data, so no information is added manually. In addition, we developed a mechanism for matching user data with the internal structure of the service, to facilitate system maintenance and reduce the need for developers’ help when adding additional data. Rules scheduling The rules can be scheduled to be executed at certain times, or triggered based on specific activities. For example, after a member is activated in the system and onboarded, the messaging engine sends them an invitation to take a particular survey. That survey is always sent on day three. But, immediately after taking the survey, Jiseki can send them a message thanking them for their participation and, depending on the results of the survey, follow up with a message addressing a particular issue after five days. If Jiseki sends a member the invitation for the survey and they don't take it, a follow-up reminder automatically goes out on day seven. Tech Stack The service was implemented using Python, while the REST API for the client was written in Django + DRF. Airflow is used, along with Celery + Redis, to perform tasks and schedule rules. The Admin UI was created using Django, while Postgresql is used for storing data and DynamoDB organizes interaction between service components. Deployment was realized with Docker + Docker Compose for local development, and Kubernetes as a production infrastructure. The system needed to be wrapped into a simple interface which would allow users to set and manage messaging rules, so we made a control interface application using React. Using React and Typescript, we developed an application for managing client notification rules. We didn’t use the global state in this application, instead, the global cache was used with React Query. This allowed us to simplify the application architecture and significantly reduce the amount of code for interacting with the server. HIPAA Compliance One unique challenge we faced during the telemedicine platform development was working with data in accordance with HIPAA regulations. HIPAA sets the standards for sensitive patient data protection. Since the system deals with protected health information, we needed to put security measures in place that would ensure HIPAA Compliance by going beyond the typical security for messaging engines. The most unusual data we worked with was EMR information, since it could only export data with HL7 format. So, we standardized all the data and put it into a HIPAA-compliant database that the rules engine could work from. What are the results? We have fully developed the first version of the product, worked out the business requirements, designed the interface, and formed the technical architecture of the service. When the service goes live, Jiseki expects a user base of 40-60 thousand users. The company essentially wants to be running trials continuously, trying different patterns of interventions, measuring the results, and determining what’s working and what’s not. The plan is to narrow down how the rules are applied. In version one, that we have developed, the rules are universal, but in later versions, more sophistication will be applied to the rules and the rules will be different for each person based on certain statistics and AI models. Jiseki’s continued goal is to better understand their members and tailor the service to meet their specific needs. The Evrone team will be happy to new services and solutions, in order to help Jiseki provide greater person-centered care service delivery. Reach out to us for more information on the best new features in telemedicine apps, or to find out how we can help you with the development of your Medtech startup! continue to implement Previously published at https://evrone.com/jiseki-health. The author of the story is the chief editor at Evrone .

Flow

Elizabeth is a Chief Editor @Evrone.com, a top-notch tech writer, and a programming world celebrities interviewer. 

Here's How We Built a HIPAA-Compliant Rules Engine for a Medtech Startup

Too Long; Didn't Read

Coin Mentioned

Elizabeth Lvova

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...