Hubble是什么
Hubble 是由 Hubble Health 团队打造的患者记录检索层平台，官方定位为「The records layer for healthcare」，即打通电子病历（EHR）与支付方（payer）系统的统一患者记录获取层。Hubble 基于患者访问权（patient right of access）构建，通过授权即取数的模式，能够触达 Epic、athenahealth、UnitedHealthcare、Aetna 等主流系统，并覆盖网络型 API 遗漏的长尾数据源，包括通过浏览器代理和语音代理获取分散记录。平台同时支持患者介导访问（Patient-Mediated Access）与提供者介导访问（Provider-Mediated Access）两种模式，前者面向患者授权的记录拉取，后者面向医疗机构已使用的 EHR 和支付方门户进行授权读写。Hubble 已投入生产环境，连接超过 70,000 个系统，提供结构化输出、确定性 ID 和完整审计追踪，并承诺从第一天起即符合 HIPAA 合规要求。其商业模式为企业级 API 服务，通过 Booking a Demo 的销售流程对接客户，核心卖点是无需逐家供应商签约即可跨系统取数。
Hubble的主要功能
- 患者介导访问利用患者自身的访问权，跨 EHR 和支付方检索患者记录，授权进入、记录输出，无需与每家医疗机构单独签订数据协议。
- 提供者介导访问面向已在使用特定 EHR 和支付方门户的医疗机构，提供授权读写能力，与患者介导访问共用同一平台和 API。
- 长尾数据触达通过同意 API、浏览器代理和语音代理，覆盖网络型 API 无法触达的分散数据源，包括传真和难以自动化的记录系统。
- 结构化输出与确定性 ID返回统一格式的结构化记录，每条数据带有确定性标识，确保跨系统数据关联的准确性和可追溯性。
- 全审计追踪每一次数据访问操作均被记录，形成完整审计日志，在合规审查提出前就已具备可交付的审计报告。
- 多源数据聚合从 EHR、支付方和 HIE 网络同时拉取数据，最终组装为单条综合记录，每条字段值都标注来源系统。
- 实时资格与福利查询提供实时保险资格、福利和预授权信息查询，适用于提供者介导访问场景。
- 排程、理赔与文档上传支持预约排程、理赔处理和文档上传操作，覆盖临床与行政流程的完整闭环。
- HIPAA 合规保障从部署第一天起即符合 HIPAA 标准，所有操作均经过权限控制并记录日志。
- 统一 API 平台患者介导与提供者介导两种模式共用同一套 API，一次集成即可获得两种访问能力。
- 生产环境验证已在 Epic、athenahealth 及全国性网络环境中实际运行，非概念验证阶段产品。
- 语音与传真代理针对网络无法覆盖的硬性记录，通过语音和传真代理完成检索，补齐数据缺口。
如何使用Hubble
- 预约演示访问官网点击 Book a Demo，携带真实业务场景与团队沟通，官方会在 20 分钟内演示针对该场景的记录检索流程。
- 确认访问模式根据业务需求选择患者介导访问（面向患者授权拉取）或提供者介导访问（面向医疗机构读写），两者共用同一平台与 API。
- 一次连接通过 Hubble 平台完成与 EHR、支付方及 HIE 网络的单一对接，无需与各数据源分别谈判和签署数据协议。
- 配置权限与治理策略在平台中设定数据访问范围、权限策略和操作日志规则，确保每一步操作均被记录且符合 HIPAA 要求。
- 发起记录检索通过 API 提交患者授权信息，Hubble 自动路由至相关系统，必要时调用浏览器代理或语音代理触达长尾数据源。
- 接收结构化记录获取组装完成后的单条综合记录，每条字段值均带有来源系统标注，可直接用于业务系统集成。
- 审计与合规交付从平台导出完整审计日志，满足内部合规审查或外部监管要求，无需额外开发审计功能。
Hubble的核心优势
- API 遗漏数据的覆盖能力网络型 API 只能触达已接入的数据源，Hubble 通过浏览器和语音代理补充长尾数据，解决 FHIR API 覆盖不全的痛点。
- 无需逐家供应商签约利用患者访问权实现授权即取数，省去与每家医疗机构和支付方单独谈判数据协议的漫长周期。
- 单条记录全源可追溯所有数据字段标注来源系统，从 Epic 到 Aetna 的数据一目了然，便于临床决策和合规审计。
- 数周内上线官方承诺「Connect once, go live in weeks, not months」，相比传统集成项目的数月周期大幅缩短交付时间。
- 审计就绪的合规架构每一步操作均被权限化、日志化，HIPAA 合规从第一天生效，审计报告在合规部门提出要求前就已备好。
- 双模式统一 API患者介导与提供者介导共用同一平台和 API，一次集成同时获得两种访问能力，避免重复开发。
- 规模化生产验证已连接 70,000+ 系统，在 Epic、athenahealth 和全国性网络中实际运行，团队背景包括 Amazon One Medical 和 Grow Therapy 的核心技术负责人。
Hubble的适用人群
- 数字健康应用开发商需要跨 EHR 和支付方获取患者完整记录的 SaaS 产品团队，可借助 Hubble 避免与每家数据源逐一对接。
- 医疗机构 IT 部门医院和诊所的信息化团队需要整合 Epic、athenahealth 等系统的数据，同时满足实时资格查询和预授权流程。
- 保险科技公司需要实时获取保险资格、福利和理赔信息的平台，可通过 Hubble 的提供者介导访问直接读写支付方门户。
- 临床研究机构需要汇总跨系统患者数据用于研究的团队，可利用 Hubble 的结构化输出和确定性 ID 保证数据一致性。
- 远程医疗平台需要跨机构获取患者历史记录以支持远程诊疗的服务商，可借助患者介导访问快速补齐数据缺口。
- 医疗数据聚合服务商面向下游客户提供患者记录汇总服务的公司，可利用 Hubble 的审计追踪功能满足合规交付要求。
效果点评
Hubble 的核心价值在于解决了医疗数据互操作中「API 覆盖不全」这一真实痛点，通过患者访问权叠加浏览器和语音代理，将数据获取范围从主流 EHR 扩展到长尾系统。其「一次连接、数周上线」的交付承诺对研发资源有限的团队极具吸引力，而 70,000+ 连接系统和生产环境验证则提供了可信的落地背书。结构化输出加来源标注的设计，让数据质量可追溯，审计日志从第一天就绪，对合规敏感的采购方是显著加分项。双模式共用同一 API 的架构降低了集成复杂度，适合同时需要患者授权取数和机构门户读写的场景。目前官网未公开定价细节，企业用户需通过销售流程获取报价，透明度和自助体验方面仍有提升空间。
常见问答
Hubble 与 FHIR API 有什么区别？
FHIR API 只能访问已接入网络的数据源，而 Hubble 在 API 基础上增加了浏览器代理和语音代理，能够触达网络型 API 遗漏的长尾数据。同时 Hubble 基于患者访问权构建，无需与每家数据源单独签约。
Hubble 是否支持患者介导和提供者介导两种模式？
支持。患者介导访问面向患者授权拉取记录，提供者介导访问面向医疗机构进行授权读写，两者共用同一平台和 API，一次集成即可获得两种能力。
Hubble 数据安全合规吗？
Hubble 从部署第一天起即符合 HIPAA 标准，每一步操作均经过权限控制并记录日志，审计追踪完整，可随时交付合规审查。
Hubble 支持哪些 EHR 和支付方系统？
Hubble 已连接 70,000+ 系统，包括 Epic、athenahealth、UnitedHealthcare、Aetna 以及 HIE 网络，并通过语音和传真代理覆盖网络无法触达的硬性记录。
Hubble 集成需要多长时间？
官方承诺「Connect once, go live in weeks」，一次连接即可触达 EHR 和支付方，数周内完成上线，而非传统集成项目的数月周期。
