北京
Epic系统覆盖了美国约38%的医院。做医疗数据工程久了，早晚会碰到Epic Clarity这个模块。简单说，Clarity是Epic EHR生态里的关系型报表数据库，每晚从底层运营数据库Chronicles抽一份只读副本过来，包含临床、行政、运营数据。
Chronicles用的是私有列式存储格式，得配Epic专用工具才能碰。Clarity不一样，它跑在微软SQL Server上，是标准关系型架构，会写SQL的数据工程师就能查询。正因如此，各家医疗系统的分析团队想往Snowflake、Databricks、BigQuery上搭数据仓库时，Clarity就成了主要的数据抽取口。
真要上手之前，先搞清Epic数据架构的四层关系：Chronicles是底层运营库，Clarity是报表库，Cogito和Caboodle各有各的定位。不把这四层分清楚，后续搭管道或出报表很容易踩坑。
Clarity表有几千张，但日常数据工程主要围着几类核心表转。它的命名规范也很特别，和ISO-11179标准差别很大。比如_C后缀表示类别字段，像PAT_CLASS_C、ENC_TYPE_C、SEX_C这类字段，查询时必须连到ZC_开头的表做解码。举个例子：查PAT_CLASS_C，要LEFT JOIN ZC_PAT_CLASS才能把数字码转成门诊、住院、急诊这些可读分类。
_ID后缀是标识符字段，记住一个坑：全部存成VARCHAR，不能设为INTEGER。比如PAT_ENC_CSN_ID就是每次就诊的唯一标识。ZC_前缀是码表，专门解码_C字段的数字编码。CLARITY_前缀是主数据或参考表，比如CLARITY_EDG是诊断表，CLARITY_EAP是手术操作表，CLARITY_SER是服务提供者表，通常连到事实表上查描述信息。还有一个LINE字段，是序列号，在多值表里聚合时GROUP BY和ORDER BY都要带上，漏了这个查询结果可能不对。
实际写SQL时有个典型场景：拉取过去一年已结账的患者就诊记录，同时带上主诊断、科室、接诊医生。主表PAT_ENC连科室表CLARITY_DEP，就诊类型解码连ZC_ENC_TYPE，诊断信息通过PAT_ENC_DX取LINE=1的主诊断，再连CLARITY_EDG拿诊断描述，医生信息从CLARITY_SER取。WHERE条件限定CONTACT_DATE近12个月且ENC_CLOSED_YN=‘Y’，结果按就诊日期降序排列。这个查询模板基本是医疗数据分析的起手式，改改字段就能复用。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
