为基于文本的服务公司构建符合HIPAA的规则引擎

MedTech初创公司Jiseki Health是一项礼宾服务，可帮助其客户控制自己的健康状况并改善他们的健康状况。他们的主要客户包括几家美国大型保险公司，由Jiseki构建的解决方案在特斯拉的工厂中使用。 Jiseki是第一个也是唯一的“全人护理”提供者，专门针对弱势的个人和社区。他们经营一个全栈，健康公平，多租户的市场，解决健康的所有社会决定因素，并采取以人为本的方式提供护理。

该公司认识到与标准化护理有关的风险，并实施策略以增强以人为本的护理的提供，鼓励其成员更多地参与健康行为。会员可以通过文本，视频，语音，WhatsApp，Web服务和面对面访问方便的全人护理。 Jiseki的平台是个人护理交付系统的基础架构，该系统将成员连接到虚拟护理，实体诊所和社区护理设置。

在Jiseki的团队与我们联系之前不久，他们演示了其通信和协调服务，该服务旨在为大量人员提供远程医疗服务。在寻找技术合作伙伴时，他们专注于寻找可以帮助他们使演示“真实”，进行后端改进以使他们扩大HealthTech初创企业并构建一些新功能的合作伙伴。但是，他们的主要目标是构建仪表板解决方案和规则引擎，以控制并生成发往其成员，患者以及与他们进行交互的提供者的出站消息传递。

业务规则引擎将对他们的用户有所帮助，包括医疗专家和在该服务注册的公司的代表，流行病学家和代理商，谁将设置要实施的消息传递规则，服务的成员以及谁会收到消息。以前，平台成员之间的通信，消息传递和通知流程是通过常规文本消息手动实现的，但是当特斯拉和其他几个大型客户与该服务合作时，就必须使用自动化消息传递系统来优化流程。

Jiseki预计将有大量用户加入该系统。由于主要服务是用于全人照护的基于文本的解决方案，因此该公司希望减少人工文本外发所需的人工成本和资源。他们希望自动发送消息，促使用户跟进特定提供商或采取特定行动。因此，规则引擎将用于设置这些出站邮件的要求：如果为“ true”且为“ true”，请发送“ this”并在X发生X天后发送。

任务基本上是描述和设计技术解决方案，为消息传递规则引擎建议体系结构和堆栈，并从头开始进行开发，并具有未来扩展和多功能性的潜力。

客户想到这个主意。我们定义了需求，建立了PRD，在仔细研究了规范并研究了用于远程医疗应用程序的自动消息传递系统的最佳实践之后，我们提出了一种解决方案，以最方便的方式为用户实现规则引擎。我们与客户端共同创建了解决方案，准备了用户流程和用户场景，绘制了仪表板模型，并开发了基于Python规则的引擎来根据特定算法执行规则。

我们确定规则引擎功能应分为三​​个主要阶段：设置规则，执行操作以及安排或选择运行程序（应在何时执行操作的时间轴）。因此，这是它如何工作的一个示例。医疗服务提供者做出决定，即居住在特定地区或州的特定患者群体需要报名进行定期健康检查。然后，流行病学家使用我们开发的规则引擎输入数据并设置定义该组患者的规则。然后，他们将任务设置为向该已定义组的所有成员发送自动消息，例如：向某公司的所有20-35岁女性雇员发送SMS消息，提醒他们在以下位置报名参加考试在7天内就诊。

规则引擎执行所有指定的规则和操作，并且患者会自动收到有用的消息/通知。输入的数据主要是对话数据，但是将来可能会输入注释，评估，EMR遇到的问题，实验室，处方信息以及一些人口统计和财务数据。

客户端正在使用Druid（分布式列数据库）来存储所有必要的数据。 Druid是一个非常灵活的引擎，可以进行快速的即席查询，因此我们将新的消息传递引擎连接到Druid分析系统。

尽管消息传递引擎的开发似乎非常简单，但是有一些警告需要仔细处理。其中大多数集中在通过API处理数据上。

例如，我们必须通过REST API访问EMR中的所有数据。但是，医疗保健中唯一可能导出的数据格式是HL7，因此我们必须集中精力使用HL7 API简化数据交换过程。使用HL7 FHIR API，我们将数据格式转换为消息传递引擎的适当格式。

我们的规则引擎设计通过REST API将呼叫发送到公司的服务，以便该服务将文本消息发送给成员。仅规则引擎就无法直接连接到SMS服务提供商或消息服务。

在评估规则为真时，规则执行包括多个API调用。例如，如果消息传递引擎发送感谢消息，“谢谢您填写我们的调查。很快我们将与您同在。”引擎还会发送API调用，以将成员放入优先级列表（在代理仪表板中），并为代理创建警报。

我们还实施了允许基于ELK组织分析仪表板的机制，以了解规则的运行状况并查看规则执行情况的统计信息。因此，在将来的版本中，客户将能够使用随机或受控测试并确定结果。

消息传递引擎规则适用于所有用户群，新用户自动添加到系统中。一切都通过API进来，包括附加的数据，因此无需手动添加任何信息。此外，我们开发了一种机制，可将用户数据与服务的内部结构进行匹配，以方便系统维护并减少添加其他数据时对开发人员的帮助。

可以将规则安排为在特定时间执行，也可以根据特定活动来触发。例如，在系统中激活了一个成员并使其加入后，消息传递引擎向他们发送邀请进行特定调查。该调查总是在第三天发送。但是，在进行调查后，Jiseki可以立即向他们发送一封邮件，感谢他们的参与，并根据调查结果，在五天后跟进一封针对特定问题的邮件。如果Jiseki向成员发送了调查邀请，但他们没有接受邀请，则后续提醒会在第七天自动消失。

该服务使用Python实现，而客户端的REST API用Django + DRF编写。气流与Celery + Redis一起用于执行任务和计划规则。 Admin UI是使用Django创建的，而Postgresql用于存储数据，而DynamoDB用于组织服务组件之间的交互。部署使用Docker + Docker Compose进行本地开发，并使用Kubernetes作为生产基础架构来实现。

该系统需要包装到一个简单的界面中，该界面允许用户设置和管理消息传递规则，因此我们使用React开发了一个控制界面应用程序。

使用React和Typescript，我们开发了一个用于管理客户端通知规则的应用程序。我们不在此应用程序中使用全局状态，而是将全局缓存与React Query一起使用。这使我们能够简化应用程序体系结构并显着减少与服务器交互的代码量。

在远程医疗平台开发过程中，我们面临的一个独特挑战是根据HIPAA法规处理数据。 HIPAA为敏感的患者数据保护设定了标准。由于系统处理的是受保护的健康信息，因此我们需要采取安全措施，通过超越消息传递引擎的典型安全性来确保HIPAA符合性。我们使用的最不寻常的数据是EMR信息，因为它只能导出HL7格式的数据。因此，我们对所有数据进行了标准化，然后将其放入符合HIPAA规范的数据库中，规则引擎就可以使用该数据库。

我们已经完全开发了该产品的第一个版本，制定了业务需求，设计了界面，并形成了服务的技术架构。

当该服务上线时，Jiseki预计将有40-60 000个用户。该公司实质上希望连续进行试验，尝试不同的干预方式，衡量结果并确定有效的方法和无效的方法。该计划是要缩小规则的应用范围。在我们开发的第一个版本中，规则是通用的，但是在以后的版本中，规则将更加复杂，并且基于某些统计信息和AI模型，每个人的规则都将有所不同。

Jiseki的持续目标是更好地了解其会员并定制服务以满足他们的特定需求。 Evrone团队将很高兴继续实施新的服务和解决方案，以帮助Jiseki提供更多以人为本的护理服务。请与我们联系以获取有关远程医疗应用程序中最佳新功能的更多信息，或了解我们如何为您发展Medtech初创公司提供帮助！