随着电子数据资源的增多，把不同来源的数据进行标准化，便于重复验证以往工作成果或与他人交流，变得十分重要。在过去几年的工作经验中，有些心得，算是个人对数据标准化起步阶段的经验总结。都是大白话，不严谨的地方请多包涵、指证、共同探讨。
一些所谓的经验背景：个人思考基于大量医疗保险数据、部分电子病历数据、部分问卷调查类数据。整理过的数据会被应用于科研。有些细节不是所有项目都必须的。
-
对于起步阶段，通用性可以停留在把不同来源的数据的变量名搞一致，变量类型都变成字符型就够了，变量长度都不用统一。
这种做法可以最快把收来的数据整合，然后分发给各个项目组根据自己需要去进一步清理。我在工作最初就跟老板提过这个方法，但老板认为这太粗糙，需要我进一步清理，然后再提供给分析师。结果就是，我标准化过的数据，倒是够准确和通用了，但时程很长，而且一旦我某个处置不当，会导致下游分析的错误，所以压力极大。而且如今有多个不同来源的数据压在我手头不能完成标准化提供使用。我的窘境源于我们只是小科研组，不是大公司有多个人做我同样的工作，但我仍认为我建议的起步阶段设定足以。比如，常用基础变量名（医疗类）就可以设定为几大块儿：- 可适度参考用ID （除 PID 病人代号外），DATE 等常用可归类的key词作为变量前缀，便于批处理一系列变量，比如：ID_DEPT (医院科室对应代码）， ID_HOSP（医院对应代码）等。
以下为一些信息类型的数据粗框： 建议注意以下细节：
- PID 要唯一，各数据表通用；
- ID_CASE 可以用病例号，但建议相关实验室检查和影响检查等，均可联系到对应的病历号。
- 实验室检查需要记录病人样品的采集时间，检测时间，出结果时间等，便于质检其实验室结果的可靠性。
基本信息类：（所谓的Demo table；此中信息均为PHI，个人健康信息，需加密）
| PID（病人代号） | DOB（生日） | SEX | RACE/ETHNICITY | CITY | STATE（州/省） |
|---|
病史记录类： （所谓的DX table）
| PID | DXDATE（就医诊断日期） | DX（诊断代码ICD10 甚至直接是医生手写诊断的电子录入） | ID_CASE（病例记录号） | ID_DEPT（就诊科室） | ID_HOSPITAL（就诊医院） | TREAT_SUG（医嘱、建议治疗方法） |
|---|
治疗记录类： （所谓的RX table）
| PID | DATE_TRT（治疗处置日期） | ID_CASE | TRT（治疗/用药的名称/代码/手写记录） | TRT_QT（治疗用药剂量） |
|---|
随访记录类： （略）
实验室诊断类： （略）
图像诊断类： （略）
保险信息类： （略）
临床实验类： （略）
问卷调查类： （略）
以上的变量项目都用字符型，把所有来源的数据都套用进去，然后分给各个分析师自己清理细节。
-
尽量用带码表示字符类名称：
比如医院名称，xx大学xx附属医院，在收集中把这些字符类名称做个1对1列表，节省空间。全国医院就算100万家，7位数就够了。但注意不要重复。并且也不必强调按字母顺序，因为你不知何时会在哪里加入新医院，不如就随着增加，给它个新代码。
实际上有很多Code System可以借鉴，像ICD9系统就是为了标准化医生诊断用的，省略的很多书写。（当然某一系统未必适合不同国家，但借鉴设定规律便于创建自己的系统），比如：- ICD-9 / ICD-10 code：国际临床诊断代码；
- NDC code：美国国家药品代码；
- CPT / HCPCS code：临床处置操作代码；
- LOINC code：实验室检查相关代码；
- NPI code: 职业医师代码；
- 医院代码：建议自己创建；
- 科室类代码：建议自己创建；
避免过度加密不必要的信息。
有些数据公司为了省事儿，把所有名字里带ID的都给加密了，然后拆分出许多CODEBOOK （就是集中列出加密CODE对应的真实CODE的列表）。这样虽然简单粗暴地符合了PHI（个人健康信息）要保密的相关规定（：凡是疑似ID的东西都要严查，万一跟个人相关，必须加密），但像一些医院ID，科室ID，医生ID（因为是医生，在医疗资料里其姓名、性别、年龄、学历、工作年限都是不须保密的），药物名称ID，等等，都没必要加密再做出CODEBOOK连接，直接用就行了。当然这个过程要小心，别把某些能连到病人个人的真实ID（比如身份证号，电话号，住址等）直接列出来就行了。加密通常都把记录长度放大了若干倍，导致连接、索引、读写所耗的资源大大增加，没必要。
。。。不断完善中。。。有问题欢迎留言探讨。。。
