为了诱惑你来阅读我的文章，今天做回标题党，很高兴你能点进来。前段时间我听HIT专家网组织大佬们的网课，其中提到，设计一个20年不做颠覆性改变的系统，这个问题让我思考了良久。对啊，一个系统设计如何能扛过20年的风风雨雨，这是一个有意思的问题？ 

你可能心底和我一样有一堆疑问，20年为你服务软件公司是否倒闭？20年你是否还在原来这家单位？20年又会涌现多少新技术？20年发布多少医疗行业改革政策？20年之间充满了无数的变数，设计一个系统如何扛过20年的时间，想到这里是不是感觉有点天方夜谭？接下来谈谈我的想法。

先看世界上顶级大佬，贝索斯在一次演讲中曾说过“我经常被问到一个问题：未来10年，会有什么样的变化？我觉得这个问题很有意思，也很普通。但我很少被问到：未来10年，什么是不变的？”，“我认为第二个问题比第一个问题更重要，因为你需要将你的战略建立在不变的事物上”。

按照贝索斯这个思路，同样可以用在我们这个医疗行业上。未来20年医疗行业什么不变？为患者服务的本质不变。这个原则不管20年、30年都始终不变，我们的信息系统业务设计可以围绕这个原则开始展开。

顺着这个思路下来，经过这么多年发展应用，医院信息系统复杂程度已经非常高，我们也希望不要动不动就要推倒重来建设系统（俗称不要重复造轮子），换系统的代价实在太大，希望保持一种长久的基本性稳定，一般HIS系统会干了一件很重要的事情，就是对系统进行分层设计（俗称架构设计），将系统解耦，获得一个稳定的底层结构（20年不会颠覆改变），上层允许各种HIT应用可以做到“热插拔”。

医院信息系统架构这个单纯从技术的角度来看，未来20年什么不变的？要回答这个问题，首先回顾我们现有的软件架构，为了把问题简化，不考虑单机版的情况，我把现有所有的信息系统架构统一抽象成二层架构(C/S、B/S)、三层架构(SOA、微服务、中台)，如下所示：

二层架构

三层架构

不管是二层还是三层结构，在相当长一段时间内“数据库”这个底层是不会变化的。所以要做到20年不做根本性改变，我个人认为如何设计“数据库”是关键。

回到现实当中，是否存在可以运行20年的系统，我只能说靠运气，有人说我们不是有HL7标准、国家标准，按照标准做不就可以了，HL7太复杂、落地困难，国家标准医院完全遵循也很困难，还有标准过多的问题，一个icd全国就有好几个版本，何况每个厂家都有一套自己架构，互不相通，这套架构能跑20年是个大问题，还有厂商能活20年也是个问题，既然有这样问题、那样问题，你自然想到了一点解决方法，厂商将自己架构开放出来不就行了。

薛万国主任，在他文章提到“封闭是当前医院信息系统发展的最大技术障碍，很多医院抱怨“被厂商绑架”的根源在于系统的封闭性，医院基础信息系统具有开放的责任与义务，有建立和遵循业务集成规范的义务，开放的内容包括：开放数据、开放事件、开放服务功能”。坦白说单凭厂商自觉性，比登天还难，毕竟商场如战场，换位思考，这种决策相当于“自我革命”，非常困难做的，要有非凡的勇气。

在这个章节开始之前，我先来谈一下去年工信部推出的一个政策，“携号转网”，也称作号码携带、移机不改号，也就是说一家电信运营商的用户，无需改变自己的手机号码，就能转而成为另一家电信运营商的用户，并享受其提供的各种服务（百度百科）。

我们生活都有过这样的困惑，比如我是中国移动的客户，我现在对移动很不满意，我想换成中国电信，你会换吗？拿我个人举例，不会换，因为我的移动手机号码如果换了，我的微信要重新更换手机号码绑定，我的银行账号也是绑定这个手机号码，我的亲人、同事、朋友保存这个号码，难道挨个发短信通知，代价实在太大！移动服务再不好，也只能忍着。现在不一样了，有了“携号转网”，我这个移动手机号码可以不变，只是换一下运营商就行了。国家给我了“用脚投票”的权利，我上个周末去移动营业厅办理宽带续费，我发现费用比去年便宜了一半，我那时候就想是不是受了这个“携号转网”政策的影响，心里就是一个“爽”字。

作为医院一方，我们特别害怕被厂商“绑架”，一旦采用某个厂商的产品以后，一般不轻易换系统，因为代价实在太大，这个代价好比换手机号码，尤其你的系统已经运行十年以上，除非是“忍无可忍”。为什么你那么害怕换系统，最重要原因不在于你觉得旧系统不好用，而是怕后台数据库发生了“断层”，A厂商的数据与B厂商的数据互不相通的，B厂商的系统调用不到A系统的历史数据，你可能说做接口啊，话是没错，假如你又成B厂商换成C厂商，又做一次接口吗，工作量巨大。

如果允许医疗数据“携号转网”，也就是说某权威机构制定一套开源数据库表结构标准，如果被多个厂商在遵循这套标准开发软件，可以无缝切换不同厂商的软件，用户真正拥有了“用脚投票”的权利，也保证了做到20年不做颠覆性改变成为大概率事件。

在这里或许你了解我要表达的意思了，只有HIT开放新生态才能做到设计20年不做颠覆性改变的信息系统，当然这只是我个人看法。

其实医院大部分的业务场景都是相近的，为避免重复造轮子，假设CHIMA成立有一个“数据库设计标准化委员会”，比如，设计“患者主索引表结构”，主键id、姓名、性别、出生日期、户籍地址、现地址……。设计“挂号业务表结构”，主键id、患者id、姓名、挂号医生id、挂号医生姓名、挂号时段……相关流程图、时序图等等。假设有A厂商、B厂商软件都是基于CHIMA的“数据库设计标准化委员会”来开发的，医院就可以实现“携号转网”，实现真正HIT应用“热插拔”。

为什么你要考虑表结构、流程图、时序图这么具体，第一个原因降低大家开发门槛，容易普及，容易到一个还未毕业大学生就可以在学校把这些东西了解清楚了，还可以开发相应的软件，如果要别人实现 HL7协议标准，坦白说，学习成本过高，开发难度大。第二个原因，每个人设计数据库的能力水平千差万别，表、字段的命名，范式设计都是有学问的。其实我们现在各种上报的数据接口，就是一堆设计好表结构给到你，为什么不给你HL7标准，让你自己看着办，原因就是以上2条。

某上报数据接口

我斗胆再从商业的角度来分析这个问题。如果某个厂商基于CHIMA的“数据库设计标准化委员会”来开发的，相当于给用户一把刀子，随时拥有“捅你”的机会，用户离开你的时候都不会和你说声“再见”，因为他们是“用脚投票”的，同时倒逼厂商必须重视售后服务、软件易用性、稳定性。

还有人会说，你这个开源东西不安全，我觉得这完全是悖论，整个互联网的大厦都是建立在开源“TCP/IP”协议，移动手机操作系统80%份额来自于开源安卓系统。为什么这些开源的东西，你敢用。安全问题本质非法访问未授权的资源，应对安全的问题现在有非常多的解决方案。比如数据库设定不同的角色；手机APP重要概念隐私权限，比如APP打开摄头，征询用户同意才能操作；防火墙的拦截非法请求。本质是检测别人是否非法访问资源。

以上来自一个普通医信工程师的思考，认知水平十分有限，不足之处，请大家指正批评！

（作者：冯火 广东省罗定市人民医院信息科）

    https://live.chima.org.cn/watch/975050

    https://live.chima.org.cn/watch/997828

欢迎您分享医院信息化建设中的技术实践和工作经验。

投稿邮箱：sec@chima.org.cn

微信：13716062058