聊聊技术驱动互联网+医疗三个争论

前段时间和一个医生朋友吃饭,聊到他最近几个月开始接触病历夹,觉得超级好用。我问他哪里好用,他给我讲述了他,做为多点执医的工作,要经常到处跑,使用OCR和语音录入快速整理病历,有效跟踪病人的经历。这里有个背景交代一下,作为一个技术工匠,我自己不是一个很擅长推销的人。所以身边好朋友即使知道我在做什么,也知道我的性格,如果他们自己没有发现优势,是不会推荐他们用的。这次和我这个朋友吃饭,他夸的我自己都有点不好意思。但今天回想起来,心里却是觉得美滋滋的,一种功夫不负有心人的感觉。做为工匠,我理解最重要的是对“完美”的追求。在病历夹过去的2年时间里,身为技术的负责人,在语音识别和图片识别方面投入了巨大的精力。从寻找合作商,到研习友商和国内、国际上的方法,再到如今,一步一步在公司一群兄弟的“打骂”中,一点点优化系统。从最开始大量的人工识别,全病历识别到如今,经历2.5次大规模的系统更迭,几十个迭代上线,杏树林的识别系统已经初步实现了自动化分类分拣、中转流程自动化、以病历信息安全为基础的碎片化处理、信息的预OCR处理+分角色人工录入校验的一体化系统。这一系列的工作,不是一蹴而就的,也不是靠纸面能想出来的。它是一种工程技术和识别科学技术相结合的体系化工程。它是一种从实践到优化再到实践到优化持续不断的过程。可以说,强大的健康医疗类数据处理能力,在成立5年后的今天,已经成立杏树林站在大数据风口上的重要核心力量。因为这样的能力,我们那个月处理几千万字符的医疗健康数据。因为这样的能力,我们积累了中国可能少有的动态标准化医疗数据库,希望有朝一日成为国内最大的标准化数据库。因为这样的能力,我们为数据分析和研究打下了坚实的结构化数据基础,并且在持续的算法和人工清洗中,让数据称为进行精准化医疗基石。这里必须多说一句,感谢陪我走过这艰苦日子兄弟们,一起加班加点工程师、把我主持的一个个系统说的体无完肤数据分析师、争执争吵不停的算法工程师们。

说了些自夸的话,主要想顺着这个话题聊聊技术驱动医疗这个事情。互联网的发展,让越来越多的人们认识到技术在现代社会发展中起到的重要作用,工程师文化在成为了越来越多企业津津乐道的话题。那么针对医疗,是否真的能再次摇动起信息技术驱动的大旗让医疗进入新阶段吗?

  • 互联网+医疗的门槛-医疗信息化vs信息化医疗
    见过不少的HIS系统(Hospital Informatioin System),也曾经以前作为咨询师参与过朋友HIS的系统分析工作。就我所看到的,大量的医疗信息化系统,都是基本上完全照搬的现有医疗的实际工作方法或者工作模式。更多的人把计算机信息化当作了服务于原始工作的一种手段和工具。所以,曾经有一段时间,不光是医疗领域,在很多领域都流行一个词,叫做信息化或者数字化。而HIS也是在这段时期应运而生。但HIS本身,过分强调将已有医疗进行数字化,强调还原所谓的“医疗习惯”,因此造就了一系列其实很严重的数据结构。

    如上图,数据因为不符合关系型数据的存储,造成了大量医学统计上的困难。这种怪异的表格设计,从人类认知理解上并没有太大问题,但是作用到机器上就会出席比较大的麻烦。为什么会造成这种现象呢?在笔者看来,就是所谓医疗信息化在作祟。信息技术应该是一门重要的学科,它的重要作用是帮助人们重新认识这个世界。用机器的方式对世界进行组织和计算,这里面虽然会产生冗余,但是因为机器的大规模自动化应用,将是的大量数据的集体计算能力得到非常大的提升。

    所以笔者提出了信息化医疗的理念,这也是为什么说信息技术驱动医疗。原因在于,信息的信息化技术更加强调改造一种旧有的方法和工作模式,通过大量机器的参与,大幅度的提升旧有模式的工作效率。因此,在提到移动医疗的门槛时,笔者经常会说,这里的最重要门槛是使用新时代的信息技术方法,对医疗工作过程,方法进行重新梳理和重新定义,帮助医疗系统寻找方法进行优化。而不是遵从现有医疗方法,找一个电子化的道路,这样是不可能解决问题的。

  • 互联网+医疗的创新-业务创新vs技术创新vs技术化创新
    以Google为首,创立了新的数据分类检索的搜索算法。以Facebook为首,创立了新的人与人的连接算法。以Apple为首,创立了新的人与机器的交互技术。这几件事情,是笔者认为具有跨时代意义的技术发展,他们可以说是真正的技术创新。当然正在到来的无人机远程图像传输技术、AR/VR技术等,也可能正在成为具有划时代意义的技术提升。

    但是有不少人说,不能所有公司都围绕着技术本身来进行创造性工作。是的,各行各业也都需要许多的业务创新。但是如今,在互联网的时代,任何的创新,或者说基础创新工作,还是有章可循的。这个章,就是对技术改变传统方法的总结和实践。用这套新的方法,来指导创新。因此笔者强调技术化创新,并不是认为互联网时代的引领者一定要做什么前无古人的新技术,也不是传统模式里面寻找新的业务增长点,而是从技术发展中,寻找使用革命性的技术,对领域进行创新改造。在这个过程中,实现业务价值,引导领域效能提升。因此,笔者认为,用现代化技术寻找医疗领域的增长点,是创新的关键。

  • 互联网+医疗的明天-大数据vs数据分析
    笔者最近出席一些论坛,也看了不少文章,发现有个词现在被反复提及“大数据”。这里笔者Quote一句最近特别喜欢的话。

    Big Data is like teenage sex:
    Everyone talks about it, nobody really knows how to do it,
    everyone thinks everyone else is doing it, so everyone claims

    为什么这么说?笔者还不敢说自己对“大数据”有多么深的造诣,但是就已有的技术理解而言,“大数据”不等于“大量数据”这是两码事。大数据是一种根据大量数据的统计结果进行分析的方法。举个例子来说,百度用大数据对地图两点之间距离进行统计分析,预测百度到家的送餐时间。这其中百度大数据使用了很好的大样本情况下的统计学方法。这套方法,其实在医学领域早就已经有所使用,但是这里面有一个重要的问题。现代医学有一个重要的概念,叫做循证医学,其核心思想是医疗决策(即病人的处理,治疗指南和医疗政策的制定等)应在现有的最好的临床研究依据基础上作出,同时也重视结合个人的临床经验。

    这个临床依据怎么来,就成了现代医学的最重要课题。于是现代医学研究,包括药理分析,开发出了一大套排除干扰,单一化的统计方法来完成数据的分析工作。这里很重要的一个词,叫排除干扰。而恰恰是这个词,和大数据的模糊化统计理念有出入。所以,有不少人说大数据是医疗的明天,这点笔者很难认同。原因恰恰是技术驱动互联网+医疗。因为如果是驱动,就要看看被驱动本体到底是什么。如果如笔者所说,大数据是一套统计方法论的话,那么除非医疗统计方法论出现了革新,否则很难说大数据是医疗明天这样的事情。

    那么明天到底是什么,在笔者看来要技术驱动,就要驱动信息化的医疗自身工作,那就是研究数据分析的过程,这一块儿虽说很难,但却是可以、也值得解决。从这个角度而言,也是笔者所引导杏树林努力实现的目标。

总结下来,回到文章一开头写的。最近的信息技术互联网,可能由于某滴、某信的快速发展变得有点浮躁,好像今天做了投资,明天就能有几千万的用户,后天就能继续融资几亿,周而复始,大家就觉得技术驱动了。笔者眼里的技术,是一个持续话提升和解决的事情。人工智能这个词从上个世界70年代提出,经历了20年的起伏,10年的低潮,如今又慢慢随着技术的提升重新进入了“代表未来”的词语。如果一定要问,技术的发展模式,在笔者看来,是踏踏实实的,做好一个又一个优化,把现在需要10个人的事情,自动化起来,变成2个人。这就是技术的发展模式,来不得半点“大跃进”,来不得半点虚假。而是踏踏实实,一步一个脚印的去优化,去改造,不盲目遵从,也不妄自菲薄。这就是技术驱动互联网医疗的核心。只要有了这个核心,大部分争论其实都是伪命题而已。做好事,让医疗真的提升,才能让我们的兄弟姐妹父母子女更多人看到病,看好病。

关于文字集与编码

写Python2的人,很多人都见过下面这行Error

1
2
3
4
5
6
Traceback (most recent call last):
File "/Users/Jack/Documents/ApricotForestDoc/2_product_rnd/redspiderlily/mailfetcher.py", line 35, in <module>
if is_reply_mail(subject):
File "/Users/Jack/Documents/ApricotForestDoc/2_product_rnd/redspiderlily/module/mailutil.py", line 46, in is_reply_mail
return ("回复" in subject_.lower()) or ("re:" in subject_.lower())
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 0: ordinal not in range(128)

上一次聊到Python3升级的一个重头就是unicode编码。所以这次想重点就聊两句字符编码。说实话就是在此之前自己也有些算不清楚。所以还是深入的跑到wiki上研究了一番,分享供参考。

ASCII,全称American Standard Code for Information Interchange,是一个字符编码标准。使用0-127(2^7)的数字代表不同的英文字符,这里包括大小写字母,空格,特殊字符等。这是一个大家都比较熟悉的字符集标准,可以看看下面图中的内容。这里不做赘述。

但是,ASCII因为标准内含有的有限,带有音标的字符‘é’就无法很好的表述,更别提汉字了。到了1980年代,计算机技术发展,那时候大家已经开始使用字节(byte)来作为计算机基本计数单位。1byte=8bit(2^8=256),所以可以表述的字符变多了。那个时候开始出现了实用128-255这些数字表示发音单词。所以直到今天,你去看word里面的字符表,Latin依然可以看到这个顺序关系,大体就是这个原因。

再之后,当世界各地的语言发展出了各自不同的字符集体系,比如中国简体(GBK,GB18030),中文繁体(Big5,以前有个特别扯的名字叫做大五码),法语(Latin1),日语等等。本来各种语言字符集各自写互不干扰,倒也相安无事。但是,世界大融合嘛,于是问题来了。有人需要在中文里写上一段日语,就像这样 ++“日本語にほんご”++ 。于是问题就来了,怎么才能在同一个文件里现实不同的字符集的字符内容呢?1980年,人来开始尝试解决这个问题,并制定了一个新的计算机工业标准用以规范的处理、表示和编码全世界主要文字。这个标准叫做Unicode(全称是The Unicode Standard)。目前,Unicode标准是8.0,已经包含了全世界已经有超过12万个字符,覆盖129种现代和历史上的语言种类。在这里面需要说明一个额外的概念叫做Universal Coded Character Set (UCS,也叫做ISO 10646)。按照Wiki对于Unicode和UCS的说法,目前两套字符集应该是完全相同的。同一个数字在两个字符集里所代表的字符应该是相同的。但是Unicode的外延要多一些。USC仅仅是一个字符集,而对应的Unicode同时还规范了校对、标准化、表示顺序的算法等。就如同本文提及对Unicode的定义一样,Unicode出来包括了字符集,还有表现和处理方法的部分。因此Unicode应该说是一个更加广泛含义上的标准。

理论上说,Unicode字符集或者UCS有110万字符点数可以被分配,目前时机分配成16个Plane,其中Plane0,被叫做BMP(Basic Multilingual Plane),一共65536个,其中绝大部分是中文(Chinese),日文(Japanese)和韩文(Korean),三者合称CJK。

这里需要特别提一下Chinese Simplified(GBK,GB18030),自从2000年以后,中国政府规定,所有在中国售卖的软件产品必须支持Chinese Simplified(GB18030)字符集。因此在我国,就出现了一个神奇的事情,就是Unicode和Chinese Simplified双字符集并行的问题。

有趣的是,笔者大概调研了几大中文网站的编码如下:

URI 字符编码
https://www.taobao.com/ Unicode(UTF-8)
http://www.jd.com/ Chinese Simplified (GBK)
http://bj.meituan.com/ Unicode(UTF-8)
https://www.baidu.com/ Unicode(UTF-8)
http://cn.bing.com/ Unicode(UTF-8)
http://www.sohu.com/ Chinese Simplified (GBK)
http://www.qq.com/ Chinese Simplified (GBK)
http://www.sina.com.cn/ Unicode(UTF-8)

感觉上各个大厂也是自说自话,不是不是很一致要遵守政府规定或者不遵守规定。这么说来,国家对这块儿在申请xxx备案的管理也不是很严格。

话有点扯远了,咱们再回来。目前Unicode字符集共设定16个Plane(数字从0x000000-0x10FFFF)对应(2^16+2^20)对应(1,114,112)。刚刚说的Plane0,基础语言集定义是从0x000000-0x00FFFF(2^16)。其他的大家可以查,Plane1和2用了一些,其他基本上用的很少。因此总共来说目前分配的字符大约是12万。

但是这样庞大的数字和计算机的比特(byte)之间并不统一,把一个Unicode字符串转换成Byte的过程,这里引入了一个叫做Encoding,编码的概念。1992年,为了兼容不同处理器和C语言,人们引入了一个编码标准,这就是大家广泛知道的UTF-8。截至2016年5月份,在WWW上的统计,UTF-8的使用率已经达到86.9%,对比GB2312(0.8%)。同时W3C也把UTF-8作为XML和HTML的推荐编码。

下面我们来阐述一下UTF-8的实现原理(同时可以结合下图来看):

如果是7位以内表述的字符表数字,就只占用一个自己,表现为(0xxxxxxx),这样刚好和ASCII码的描述相一致,这样就不会造成原有ASCII的识别错乱,特别是针对C语言的strlen()和strcopy()。从第8位,也就是十位数的256开始,采用两字节表述模式(110xxxxx 10xxxxxx),最多可以表示11个bit位,也就是2^8(256)到2^12-1(4095)。以此类推。是不是一种很有趣的编码模式 :)

下面看一个栗子。以杏树林的“杏”字为题。

所以总结一下,Unicode和ASCII是一个字符集的概念,他们是随着电信发展而产生的编码本。只不过Unicode有多包涵了表示和处理部分,范围会更广泛。为了让计算机能读懂编码,适应计算机的计算,我们有了诸如UTF-8类的编码方法。

值得参考的一系列词条出处
https://docs.python.org/3/howto/unicode.html
https://en.wikipedia.org/wiki/Character_encoding
https://en.wikipedia.org/wiki/Unicode
https://en.wikipedia.org/wiki/Universal_Coded_Character_Set
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane
https://en.wikipedia.org/wiki/UTF-8