远程医疗最小可行产品（MVP）应该做好五件事：预约就诊、进行可靠的视频咨询、开具有效的电子处方、收取费用以及保存完整的医疗记录。其他一切都可以稍后再做。真正不能拖延的是那些日后更改成本高昂的决策：数据存储位置、如何记录知情同意和身份信息，以及数据模型如何与临床标准相匹配。在MVP阶段就把这些都做好，后续的功能就只是锦上添花，而不是重新构建。
快速回答
- 先从单一专业领域和一个市场入手。
- 构建五大核心功能：预约、视频、电子处方、支付、记录。
- 在第一天就确定托管区域、身份、授权存储和数据模型。
- 人工智能、远程监控、保险和交易所集成等功能可以留到以后的版本中实现，但设计时要考虑到这些功能能够融入其中。
远程医疗应用的最小可行产品（MVP）必须包含哪些内容
- 预订。
医生出诊时间、时区、提醒、取消和退款规则。 - 视频。
即使在网络信号较弱的情况下，也能进行远程会诊，并配备音频备用方案。我们关于使用 WebRTC 实现可靠远程医疗视频通话的文章对此进行了深入探讨。 - 电子处方。
结构化药品录入、医生注册号和签名，以及对您所在市场无法远程处方的药品进行限制。 - 付款。
本地支付网关、收据和退款。 - 记录。
一份会诊记录、附件和病史，供医生下次查看。
有两个辅助部分很容易被忽略：医生端的工作流程和用于验证医生执照的管理面板。
从小规模做起：先专注于一个专业领域，一个市场
监管因市场而异。在迪拜，远程医疗平台必须获得迪拜卫生局 (DHA) 的批准才能上线，并且必须按照DHA 制定的《远程医疗服务标准》将其记录与 NABIDH 系统对接。在印度，咨询服务遵循 2020 年《远程医疗实践指南》，而《数据保护和数据保护法》(DPDP Act) 则增加了数据保护义务。同时在两个市场推出服务意味着工作量翻倍。
专业领域也很重要。皮肤科需要良好的图像上传功能。心理健康科需要更长的诊疗时间和更高的隐私保护。全科需要快速开处方。选择一个领域，从实际诊疗中学习，然后再拓展。
关于商业和许可方面，请参阅如何在阿联酋开办远程医疗业务。
一个示例 MVP 技术栈
没有唯一正确的堆栈。这只是一种常见且经过充分验证的组合。
- Flutter iOS 和 Android 平台上的患者和医生应用程序，均基于同一代码库。
- Laravel 适用于 API、管理面板和后台作业。
- PostgreSQL的 用于结构化临床和预约数据。
- 视频服务：您自己的 WebRTC 堆栈（带 TURN 服务器），或者带区域内托管的托管视频 API。
- 本地支付网关 针对您的市场。
根据团队技能和托管需求进行选择。使用通过其他国家/地区路由呼叫的托管视频 API 可能会违反阿联酋或沙特阿拉伯的数据本地化规则。
尽早决定这些事项
有些决策日后更改成本不高，而另一些则意味着数据迁移或核心服务重写。
以后很难更改：
- 托管区域。
发布会后，在各国之间传输健康数据既缓慢又有风险。 - 数据模型。
将诊断、药物和观察结果以编码的结构化数据形式存储，这些数据可以映射到 FHIR 标准。这使得后续与 NABIDH、Malaffi 或 ABDM 的集成更加容易。 - 同意记录。
记录首位患者的每份知情同意书的版本和时间戳。 - 身份
阿联酋使用Emirates ID，印度使用ABHA。从一开始就规划好字段和验证方式。
以后可以轻松更改：用户界面主题、通知文字、引导页面、定价方案。
MVP中的合规基础
先构建基础架构，再开发功能。发布当天不需要所有证书，但架构本身也不应该阻碍证书的获取。
- 境内托管 并在同一国家/地区设有备份。
- 加密 运输途中和休息时。
- 同意与身份 已正确捕获和存储。
- 审核日志 查看或更改记录的人。
我们的《远程医疗应用安全云架构指南》详细介绍了这些内容。
v1 和 v2 版本需要保留哪些内容？
- 人工智能医疗记录员。
很有价值，但它需要自己的同意流程和验证机制。 - 远程病人监护。
设备集成和全天候警报处理本身就是一个项目。 - 保险。
在任何市场，资格认定和理赔整合都需要时间。 - 健康信息交换同步。
某些市场（例如迪拜）需要此功能，因此请在 MVP 中检查您的发布市场是否需要此功能。
如需了解完整的功能集和成本范围，请参阅我们的远程医疗应用开发指南和海湾合作委员会(GCC) 远程医疗概览。如果您正在权衡白标产品和定制开发方案，请阅读阿联酋定制远程医疗平台的相关内容。
常见错误
- 推出时专业方向过多。
它们各自的工作流程都不同。 - 自由文本形式的诊断和药物信息。
它们会阻碍后续的集成。 - 使用海外主机以节省成本。
后期迁移成本更高。 - 忽略医生方面的意见。
医生们弃用缓慢笨拙的工具。 - 医生无需进行执照核查。
监管机构和患者都对此有所期待。 - 视频无备用方案。
网络质量差是常态，并非个别现象。
常见问题解答
远程医疗最小可行产品（MVP）应该具备哪些功能？
预约、视频咨询、电子处方、支付和医疗记录，以及医生工作流程和用于医生验证的管理面板。
开发一款远程医疗应用的最小可行产品（MVP）需要多长时间？
这取决于应用范围、市场和集成需求。监管审批和集成（例如 NABIDH）所需的时间可能比应用本身的开发时间还要长，因此从一开始就应该将它们纳入时间表。
MVP版本是否应该包含人工智能功能？
通常不需要。只有在核心咨询流程稳定、知情同意和审核流程到位后，才能添加人工智能，例如环境记录员。
我们能否仅凭一个最小可行产品（MVP）就在阿联酋和印度推出产品？
理论上可以，但托管、身份验证、处方和同意规则各不相同。先在一个市场推出更快更安全。
