Technology

关于HIPAA

最近因为工作的关系，必须系统的学习一下HIPAA，把学习结果给大家分享一下，如下：

第一部分：什么是HIPAA

特别词汇说明（terms）：
Portability：这里特别说明，根据wiki在社会保险（social security）方面的解释，所谓携带型是保存（preserve）、维护（maintain）和交换（transfer）三个词的合意总称，因为很没有中文对应意思，所以特此解释，后面还是翻译成可携带［1］。

HIPAA，全称Health Insurance Portability and Accountability Act. 是美国关于健康保险的携带和责任的法案。HIPAA的提出，旨在改革健康医疗产业，降低费用，简化管理过程和负担，增强隐私保护和个人信息安全保护。可以说，HIPAA是美国健康卫生领域的基础大法，也是整个相关后续政策的基石。自从1996年HIPAA被正式提出以后，法案经历了5次比较大的更新，分别对医疗卫生领域在保险和医疗管理方面的工作，进行了一系列逐渐细致化和现代化的制约。

在美国2009年更新了HIPAA，引入了美国复苏与再投资法案ARRA（American Recovery and Reinvestment Act），第一次开始引入HITECH（全称Health Information Technology for Economic and Clinic Health Act）。该法案旨在拓展对EHR（Electronic Health Records） 的使用，并开始对ePHI进行了大量升级，详细解释了HIPAA对隐私和安全的保护，同时增加了更多强制实施的内容和相对应的不符合情况下的惩罚措施。该法案与2010年2月强制生效。

之后，在2013年1月，由美国卫生与公共服务部（Department of Health and Human）最终发布了Omnibus Rule，将过去的HITECH和GINA（Generic Information Nondiscrimination Act of 2008）进行了融合，并增加了更多详细的指导细节。虽然作为行政命令，Omnibus Rule并不是法案，但是它更加细则。政令与2013年9月正式施行。所有non-compilance将会收到非常严重的惩罚。

HIPAA会影响到两类组群
A. 健康覆盖实体－医疗健康提供者（如医生、护士）、医疗健康规划者（如保险公司、雇主、政府）、医疗健康数据清洗者
B. 医疗健康业务工作组织－所有为覆盖实体提供服务的第三方合作伙伴（如律师、会计、医疗公司、咨询师等）

第二部分，关于的组成

下图描述了HIPAA的主要结果组成。

HIPAA与所有涉及健康相关的医疗、保险和个人都有直接关系。法案主要分为五个主题，合并为两大部分组成，分别是简化管理（administrative simplification）［2］和保险改革（insurance reform），这两个部分也分别对应了HIPAA的两个关键要求，前者是责任（Accountability），后者对应可携带（Portability）。通常意义上大家所说的HIPAA，都是指的管理责任这部分。如图所示主要包括三个组成子模块儿：
1）事务、代码集和身份识别

  • 关于事务，2002年启用的HIPAA关于事务（Transaction）的规定要求，完整的事物要求包含以下内容：
    提交和收费处信息
    是否任何参与“Health Plan”计划
    准入性、覆盖范围、救济金等
    需要给健康计划提供者的付费内容
    健康保险计划之外的附加费用
    状态请求和相应
    相关证书以及认证

  • 关于代码集（Code Sets）部分，正如HIPAA的初衷，规定代码集大大方便了系统的交互。标准的代码，帮助系统设计之间进行有效的沟通。该部分包含5大集合，主要是为了描述疾病（desease），创伤（injury），症状（Symptoms）和操作行为（Actions）分别是：
    ICD-9-CM 国际疾病分类（International Classification of Disease）
    CPT （Physician Current Procedural Terminology）
    HCPCS HCFA操作代码系统（HCFA Procedural Coding System）包括设备、诊断、治疗、管理疾病等
    CDT 现代牙医术语（Current Dental Terminology）
    NDC 国家药品代码（National Drug Codes）

  • 关于独立标示（Unique Identifiers）用来表明患者、供应商、赔款人和雇主
    ProviderID：给所有健康服务供应商的10位数字ID号码
    EmployerID：所有为健康医疗提供资金的雇主，由9位数字表示（EIN）
    PayerID：所有为健康医疗服务付钱的组织，由9位数字表示（EIN）
    PatientID：所有接受服务的患者，目前尚在国会（congress）讨论中，主要是Social Security Number已经存在，是不是还需要一个独立的ID存在争议。

2）隐私－任何形式下的健康信息保护（PHI）
美国卫生及公共服务部（Department of Health and Human Services）［4］在2000年颁布，2002年修改了个人医疗信息隐私政策，明确了医疗实体禁止使用和披露个人受保护健康信息（Protected Health Information）。要求受保护的内容包括电子病历，纸质病历和口头沟通。同时HIPAA作为联邦政府法案，是各州遵循但不限于的基础。各州有权利要求医疗供应商等遵循更加严格的州法案。

PHI包含所有个人可辨识健康信息，包含任何形式过去、现在和可能未来的健康情况。（纸质电子病历、医疗交费记录，包括抄写副本）, 其中有一个非常重要的部分叫做个人可辨识信息（Individually Identifiable Information）
－姓名（Name）
－住址（Address）
－电子邮件（E-mail）
－日期（Dates）
－账户号（Account Number）
－证书号（Certification Number）
－驾照（License Number）
－车证（Vehicle Number）
－社会保险号（Social Security Number）
－病历号（Medical Record Number）
－健康医疗保险号（Health Plan Beneficiary Number）
－面部信息（Facial Photograph）
－电话号码（Telephone Number）
－网络地址（URLs）
－网络IP地址（IP Address）
－生物身份识别（Biometric Identification）
－其他独立识别码

了解了这个部分，我们就可以明白为什么HIPAA的一个非常有意思的规定，PHI的使用和暴露可以在两种情况下被使用。

  • 被授权情况
  • 祛标示信息情况

也就是说在祛标示信息（De-identity）后，其实所有的数据就可以被Freely的使用不收到太多限制。

3）安全－电子信息形式下的健康信息保护（ePHI）

虽然安全被分成了三个级别，但是作为一个技术同学，我还是重点看了看技术安全的五个方面：

  • 访问控制 （ACCESS Control）
  • 审计控制（Audit Controls（R））
  • 数据完整性（Integrity）
  • 认证（Person and Entity Authentication）
  • 传输安全（Transmission Security）

隐私和安全的区别：
隐私关注个人受保护健康信息（PHI）的控制和使用权力。任何形式的该信息不得在未经授权的情况下进行暴露。
安全特指电子受保护健康信息（ePHI）的防护标准。防止该信息在未经授权情况下被暴露、破坏或丢失
隐私信息部分依赖于安全来确保被保护。

参考文献：
［1］Portability (social security) https://en.wikipedia.org/wiki/Portability_(social_security)
［2］HIPPA http://baike.baidu.com/link?url=FeWuYF_ezrLt1Cg1v94jfq6zb2GfplUzM4FtURhfhMRYmKn3Hmu8erdzR9m7SG0iD9jDZcTM0ARPDOQxY-1QPK
［3］Pre Existing Conditions - Understanding Exclusions and Creditable Coverage http://healthinsurance.about.com/od/healthinsurancebasics/a/preexisting_conditions_overview.html
［4］美国卫生及公共服务部 https://zh.wikipedia.org/wiki/%E7%BE%8E%E5%9B%BD%E5%8D%AB%E7%94%9F%E5%8F%8A%E5%85%AC%E5%85%B1%E6%9C%8D%E5%8A%A1%E9%83%A8

Technology

关于Collection和Set

早上看MongoDB的文档，忽然看到Collection，疑惑了一下为什么起这个名字，于是上网搜寻了一下Collection和Set的区别，主要是看了Stackexchange的一篇文章。

也就是认为Collection代表一个集合，可以放任何东西，是一种总集合。数学上，在提及一个概念的时候，通常正式表带为notion。然后用公立（axioms）来描述这个概念（notion）。如果这个公立被认为不是自相矛盾的，那么就开始根据公立来定义一系列定理（definition）。所谓一个Collection，就是那些适用公立存在的东西（a collection is a notion of something that we can talk about, like a mystery bag）。

那么说Set有什么不同呢？Native Belief，我们本能可以相信Collection就是Set，尤其是对于非数学人士。这里的例外是Collection包含有哪些悖论的存在，而Set是不可以有的。如果是一个Set，那么通过反证也可以推导出是Set的结论。但是悖论不行，如Russell’s Paradox。

这里补充知识，Russell’s Paradox（罗素悖论）也叫理发师悖论
在某个城市中有一位理发师，他的广告词是这样写的：“本人的理发技艺十分高超，誉满全城。我将为本城所有不给自己刮脸的人刮脸，我也只给这些人刮脸。我对各位表示热诚欢迎！”来找他刮脸的人络绎不绝，自然都是那些不给自己刮脸的人。可是，有一天，这位理发师从镜子里看见自己的胡子长了，他本能地抓起了剃刀，你们看他能不能给他自己刮脸呢？如果他不给自己刮脸，他就属于“不给自己刮脸的人”，他就要给自己刮脸，而如果他给自己刮脸呢？他又属于“给自己刮脸的人”，他就不该给自己刮脸。于是产生矛盾。

Collection公式如下

这个就不应该叫做Set了，但是依然可以称之为Collection。本来悖论这个事情，造成了第三次数学危机。不过内涵公里，进行了证明。

Technology

代码也是一种诗

只是为了记住那些你曾经非常容易忽略的。这里也没有什么不一样，只是安静的土地，再来喧嚣 

1
2
3
4
5
6
python manage.py syncdb
python manage.py test
python manage.py migrate
python manage.py runserver
python manage.py inspectdb
python manage.py startapp service
Technology

python_db_basic

有些东西就是放下来记录一下，关于python的。这两天病了，忽然觉得这个事情总是对着有一种箭在弦上不得不发的感觉，所以说什么也要把这几块儿技术上的东西完成。搞完这个，应该可以踏踏实实的看看公司下一步的内部管理要如何做了，现在开始有点疲态的感觉，可能是因为平台接二连三的事故。不过这个我倒是不担心，毕竟一直在运行，一点点小聪明还是可以搞定的，只是，眼看，需要一个系统行的计划了，新的一个半年计划应该要搞一下出来了。

这个title叫python db basic，其实名字不好，主要是记录一下几个主要的命令，如何继续完成我的这个小玩具。

1）Python DB，超简单的东西，Djangle框架和RoR框架一样，基本上对于简单应用就是记住几行命令

在Models里面建立好class

在命令行里面运行，并生成migration脚本

1
python manage.py makemigrations

在命令行里面运行，并生成数据库的内容

1
python manage.py syncdb

在view里面用class直接产生新的obj，然后obj.save()就可以了

2）一个微信的小东西
ngrok用来做本地调试，却是好用截个图，剩下的自己查吧

王哲，CTOin杏树林
紧张的时候，静下来写一写条目，来看看哪些在做，哪些要做，哪些没做

Technology

wechat

开始一些关于微信方面的研究。其实很早就做过，只是这次又捡起来。对这部分的研究起源于那个需求，就是大事件记。作为数据方面的尝试，这是我第一次搞大事件。我希望以此为模型开始不断推演未来数据分析所需要的更方面东西。无论是业务上的，算法上的，应用上的，包括组织形式上的。ok，闲话少说，关于那个的总结以后再写，先说微信。

微信公共平台确实是个对于小商家和小需求型交互非常好的地方。在我看来，他的最大特点就是包含了自然语言交互，和基本的按钮交互，两种功能。一般认为，手机移动端的设计难点就是小小的屏幕如何放很多的交互是一个难题。对于微信公共平台来说，3个按钮（包括附属菜单）组成的基本交互，解决了最急切交互的需求。剩下的交给了自然语言或者有特定标示的自然语言，是非常好的方式，符合人们对于数据需求的认知。

微信包括了企业号，服务号，订阅号。企业号就不说了，服务号理论上比订阅号要高级一些，因为可以支持更多的高级API接口，最最关键的是，可以支持微信支付。更适用于企业用户，而订阅号则没有这个功能。订阅号更多的是适应于自媒体，因为他最大的优势是每天可以发送1条群发消息，这点远好于服务号，每月4条。我的这个查询大事件，想来每次出现大事件的时候，也会群发给我的所有订阅者，因此，我考虑订阅号对我来讲更加有意义，虽然我不能说每天都发生大事件，但一个月有超过4次大事件，在这个快速发展的互联网时代，还是非常有可能。

说到服务API开发，我觉得这方面以前拿ruby写过代码，逻辑上没什么难的。现在就是我的python水平有点垃圾，之前jira－soap的服务，是看别人的python库，而且公司用的con和jira版本是在太低，soap的协议，不支持rest，新的nodejs都没有，哎没办法，上吧。写一个python微信的服务

Technology

python_misc

研究python，发现最大的问题就是中英文的转换，实在是太郁闷了，研究了好久。最主要的还是出在python的encode和decode上面
http://www.jb51.net/article/17560.htm
这篇文章不错，基本上把需要的内容都解释的很清楚了。

在别人代码的基础上做了些修改，现在已经基本可以用了。

这个是该出来的加入的内容
python ./jira -s http://bug.xingshulin.com -u ＊＊＊＊ -p ＊＊＊＊ cat JCTP-9
python ./jira -s http://bug.xingshulin.com -u ＊＊＊＊ -p ＊＊＊＊ comment JCTP-9 “let do something fantastic”
python ./jira -s http://bug.xingshulin.com -u ＊＊＊＊ -p ＊＊＊＊ create -s “this is summary2” -d “nothing special” -p JCTP -t “运维事故” -a “wangzhe” -f “customfield_10200:20/12/14”

有个挺tricky的地方是要把jira里面的时间传输格式进行调整，默认的是d/MMM/yy，但是因为python对中文的支持问题，所以需要被调整成dd/mm/yy

{‘priority’: 3, ‘description’: None, ‘customFieldValues’: [[{‘values’: [[‘2014-12-23’]], ‘customfieldId’: ‘customfield_10200’}]], ‘summary’: ‘Test issue using all available defaults’, ‘project’: ‘JCTP’, ‘assignee’: ‘wangzhe’, ‘type’: 7}
{‘priority’: 3, ‘description’: None, ‘customFieldValues’: [[{‘values’: [[‘2014-12-22’]], ‘customfieldId’: ‘customfield_10200’}]], ‘summary’: ‘this is summary’, ‘project’: ‘JCTP’, ‘assignee’: ‘wangzhe’, ‘type’: 6}

Technology

ocr

最近这两天稍微深入一些研究了一下OCR的系统技术，沟通和研究了几个主流的公司Abbyy、文通、汉王和经纬名片通。大体对这方面的东西有了些了解。写篇blog记录一下。