医院选低代码，别只看demo打得多花哨
医疗信息化圈子里，这两年聊得最密的一个词就是"低代码"。医院信息科想提升需求响应速度，软件厂商想降低交付成本，两边一拍即合，低代码平台就顺势火了起来。但真到了选型阶段，很多信息科主任和工程师反而懵了——市面上低代码产品几百款，有的强调拖拽生成表单，有的主打业务流程编排，有的宣传AI辅助写代码，各有各的说法，各有各的demo，看下来眼花缭乱，根本不知道哪款适合医院场景。
这个问题的本质，不是"哪个低代码平台最强"，而是"哪个低代码平台最能适配医院现有的信息生态"。如果按这个逻辑去评估，你就需要一个参照物，一套靠谱的评估框架。信通院这几年连续发布低代码相关白皮书和标准，把低代码平台的可信能力、技术要求和选型评估方法做了系统梳理，算得上是行业里比较权威的参考。我最近正好用这套框架，对米缀平台做了一次相对完整的适配性评估，今天就把整个思路和过程展开聊聊。
先说结论：医院选低代码，核心要看四件事——能不能接进现有系统、业务人员能不能用起来、复杂报表和图表能不能搞定、数据安全和运维边界怎么划分。这四件事看起来简单，深入下去每一件都有坑。下文我会沿用信通院白皮书的评估视角，结合医院场景逐一拆解，再用米缀平台当实例说说适配性到底该怎么判断。
1. 医院选低代码，为什么不能只盯着demo效果
1.1 医院信息化的特殊约束
医院的信息化环境和普通企业有很大不同，这个特点直接决定了低代码平台的选型标准不能照搬互联网公司的做法。医院的核心业务系统——HIS、LIS、PACS、EMR，很多已经在院内跑了十年甚至更久，数据结构复杂，接口协议五花八门，有的系统连原厂工程师都换了几茬。信息科日常面对的需求，往往不是从零开发一个新系统，而是在老系统的基础上做增量改造、做报表、做流程补充。
这种环境里，低代码平台的价值不是替代现有系统，而是作为现有系统之外的"快速响应层"。比如临床科室临时要一个统计报表，护理部要做一个排班调整审批流，运营部要看某类病种的费用结构分析，这些需求走传统开发流程，排期动不动一两个月，等做出来业务部门早就不着急了。低代码平台如果能把这类需求的交付周期压缩到几天甚至几小时，信息科的价值立刻就能体现出来。
但问题的关键在于，平台能不能真正接进医院的环境，而不只是在一个演示环境里跑得飞快。很多低代码产品在demo阶段看着很惊艳，表格、图表、审批流一气呵成，但一旦要对接医院现有的数据库和接口，就暴露出连接器不够用、数据模型不兼容、部署方式不被信息安全部门认可等各种问题。
1.2 医院选低代码常见的三个误区
实际接触下来，医院在低代码选型上的误区集中在三个方面。
第一个误区是只看前端交互效果，忽略后端集成能力。有的选型团队被拖拽生成表单、自动生成图表这些功能吸引，觉得"这个平台好，业务人员自己就能搭应用"。但医院的应用不可能孤立存在，数据从哪来、数据往哪去、怎么和科室现有系统互认，这些才是要命的环节。一个连不了医院现有数据库的平台，前端做得再好看也没用。
第二个误区是低估了"谁能用起来"这个问题。低代码并非天然低门槛，不同平台对使用者的要求差异极大。有的平台号称零代码，但实际做复杂逻辑时还是要写脚本；有的平台业务人员确实能上手，但处理复杂场景时性能和灵活性都跟不上。选型时如果没搞清楚医院里到底是谁在用、用来做什么类型的应用，后面大概率会卡在"做出来的东西没人会用"这个尴尬局面上。
第三个误区是忽视部署模式和运维边界。医院对数据安全的要求很高，很多医院根本不允许核心业务数据出内网，这就要求低代码平台必须支持私有化部署。而且平台部署后由谁来运维、底层环境谁负责、版本升级怎么处理，这些问题如果不提前谈清楚，项目上线也就意味着麻烦的开始。
1.3 把"适配性"作为选型的第一关键词
把上面这些因素综合起来，你就能理解为什么我特别强调"适配性"这三个字。低代码平台的适配性不是一个模糊的概念，它应该被拆成几个可以验证的技术维度：对医院现有技术栈的适配能力、对医院复杂业务场景的适配能力、对医院组织能力和人员结构的适配能力、对医院安全合规要求的适配能力。
信通院的白皮书里其实也隐含了这样的评估逻辑。它没有简单地说"哪个平台好"，而是从低代码开发平台的可信要求出发，把功能、性能、兼容性、安全性、服务能力等维度拆成一套可度量、可验证的标准。医院在选型时如果能借用这套标准，把"感觉不错"变成"实测通过"，踩坑的概率就会低很多。
我在评估米缀平台时，就是以这套逻辑为骨架，先确立评估维度，再逐项去做技术验证和业务场景模拟。接下来我会把那套框架展开讲清楚，再结合米缀平台的具体能力项做适配性分析，这样你拿这套方法去套其他平台也一样能用。
2. 信通院白皮书里"适配性"到底在考什么
2.1 白皮书的评估逻辑不是"打分排名"
很多人对信通院白皮书有个误解，以为它是给低代码平台做排行榜的，看完之后直接选第一名就行。实际上不是这样，白皮书更像一套"体检标准"，它把低代码平台应该具备的能力拆成了多个维度，每项能力都有明确的检验方向，但最终合不合格、适不适合你，要结合你自己的使用场景来判断。
具体到医院这个场景，我认为白皮书里最值得关注的四个能力域是：平台功能完备度、集成开放能力、安全合规能力、工程化交付能力。这四个域基本能覆盖医院选型的核心关切。
平台功能完备度考察的是低代码平台在页面设计、数据建模、流程编排、权限管理、报表图表等方面的能力是否齐全。医院的应用场景很杂，有的应用偏重数据录入和查询，有的偏重流程审批，有的偏重数据展示和分析，如果平台只在某一方面突出，就很容易在真实项目中暴短板。
集成开放能力考察的是平台能否和外部系统对话。医院系统集成是刚需，平台至少要支持常见的数据库连接、HTTP接口调用、WebService对接，最好还能支持消息队列和文件交换。这个维度如果不过关，前面说的"快速响应层"就无从谈起。
安全合规能力考察的是平台在身份认证、权限控制、数据加密、审计日志等方面的表现。医院的患者数据受严格监管，等保合规是底线，低代码平台如果连基本的审计能力都不够，信息安全科那一关就过不了。
工程化交付能力考察的是平台在代码生成、持续集成、自动化测试、部署运维等方面的能力。低代码不等于不需要工程化管理，上了低代码之后，应用开发出来只是第一步，后续的测试、发布、监控、更新全都要有章法，否则平台就会变成一个新的遗留系统制造机。
2.2 用白皮书标准推导出医院选型清单
顺着这四个能力域，结合医院业务的特点，我把选型检查清单进一步具体化，分了七个可以直接拿去做测试和验证的检查项。
- 部署方式：是否支持私有化部署？部署过程是否简单？对基础环境的要求是否可控？
- 数据接入：能否直连常见的关系型数据库？能否调用RESTful和WebService接口？是否支持文件导入导出？
- 应用构建方式：页面、表单、列表、流程、报表、图表这些元素是否都能通过可视化方式搭建？复杂逻辑是否需要大量写代码？
- 权限管理：是否支持细粒度的数据权限和功能权限控制？能否对接医院的统一身份认证？
- 开放与扩展：是否提供API接口供外部系统调用？是否支持自定义组件或插件扩展？
- 安全审计：是否有完整的操作日志和审计能力？数据在传输和存储过程中是否加密？
- 厂商服务：是否有医疗行业的成功案例？是否愿意配合做POC测试？技术支持响应是否及时？
这张清单看似基础，但它能帮你过滤掉相当大一部分不适合的低代码产品。我在评估米缀平台时，就是拿着这份清单逐项过，每过一项都会设计一个具体的业务场景来做验证，而不是光看厂商的演示。下面我会把米缀平台在这七个检查项上的表现展开讲，重点说它适配医院场景的几个关键点。
2.3 米缀平台在集成开放能力上的表现
先讲集成开放能力，因为这是医院场景里最要命的环节。米缀平台给我印象最深的一点，是它对"datareport一站式低代码"这个定位的执行力——它不只是做一个应用搭建工具，而是把数据接入、数据处理、报表呈现、应用发布串成了一条完整的链路。
我在POC时用了一个很典型的医院场景来测试：接HIS系统的某个视图表，做一个科室运营日报。测试过程大概是这样的：在米缀平台里配置数据源，选数据库类型、填连接信息、测试连通性，整个过程和常见的数据源配置工具差不多，技术上没有门槛。连接上之后，能在平台里直接预览表和字段，不需要写SQL就能完成基础的数据筛选和排序。这一点对医院来说太重要了，因为信息科不一定每个需求都要走定制开发，很多临时性的取数需求如果能在低代码平台上直接做，效率提升会非常明显。
再往后是接口对接能力。医院里除了数据库直连，还有大量系统间调用是靠WebService和HTTP接口完成的。米缀平台在这块支持可视化配置接口调用，可以在页面上设置请求参数、解析返回结果，也支持把这些接口封装成应用的数据源，供表单和报表使用。对于医院这种接口五花八门、常常没有完整文档的环境来说，这个能力解决了很多实际麻烦。
不过我也要说实话，这个平台强的地方在数据层面，如果把它当成一个通用的前端低代码开发工具去用，硬要做特别复杂的C端交互界面，它不一定是所有选项里最顺手的。医院的内部应用大多数是表格、表单、报表、审批流这类形态，它的适配度是高的。
3. 医院真实场景下的米缀平台适配性拆解
3.1 可编辑echarts图表功能是报表场景的加分项
医院里最不缺的就是数据，最缺的往往是直观的数据呈现。院长要看运营指标趋势，科室主任要看病种费用占比，质控科要看不良事件分布，这些需求落到最后，全是图表。
传统开发要做一个图表页面，前端选图表库、写配置、调样式、对接接口，一套流程走下来怎么也要一两天。如果用低代码平台内置的图表组件，效率会高很多，但很多低代码平台的图表组件其实是"半成品"，样式固定、交互有限，做出来之后如果想改个颜色、调个坐标轴、改一下提示信息，就得上代码。这就让"低代码可编辑echarts图表"成了一个很实际的选型加分项。
米缀平台在图表这块做得比较到位。它内置了多个常用图表类型，拖拽到页面上绑定好数据就能出图，基本满足日常看数的需求。更重要的是，它还提供了对图表的可视化编辑配置能力——数据映射、坐标轴设置、图例、颜色、提示框这些都能通过配置项调整，不用在代码层面硬造。真遇到特殊需求，比如自定义tooltip或者联动交互，它也支持在图表配置里写部分代码来扩展。这种方式对医院来说很友好：初级使用者可以用纯配置实现80%的需求，进阶人员可以在需要时写一点代码完成深度定制。
我在POC里做了一个门诊量趋势分析图表，数据源直接连的是模拟HIS的门诊挂号表，配置过程大概不超过十五分钟。图表出来之后，运营科的同事在旁边看着说"这要是以前，报上去等开发怎么也得排两周"。这个反馈很能说明问题，图表能力在低代码选型里的权重，比很多人想象中要高。
3.2 从搭建到发布，datareport模式如何缩短交付链路
医院信息科接需求有一个特点，需求本身不复杂，但沟通成本极高。临床科室说不清楚自己要什么，信息科工程师理解需求时容易产生偏差，来回沟通几轮之后，本来一天能做完的事拖成一两个星期。
低代码平台的另一个价值，就是能把这个沟通链路压缩。米缀平台采用datareport一站式低代码的构建模式后，业务人员可以直接参与到原型搭建里来——数据接好、报表图表拖出来、页面布局调好，预览效果放在会议室大屏上一看，业务科室马上就能说"这里要加个筛选条件"、"这个字段显示得不对"，修改也就是几分钟的事。
这种模式之所以对医院特别有效，是因为它把"需求文档-开发-测试-交付"的线性流程，变成了"业务人员搭原型-技术人员调优-双方确认-发布上线"的协作流程。信息科还是那个信息科，但响应速度完全不是一个量级。我在实际项目中不止一次看到，信息科花了一个下午用低代码平台做出来的应用，比之前排了两周期的需求交付更快、更贴合需求。
3.3 医院典型应用场景的搭建实例与配置要点
为了更具体地说明米缀平台在医院场景里的适配性，我整理了两个实际POC过的应用场景，一个是数据统计类，一个是流程审批类，每个都附上配置思路和要点。
场景一：临床科室月度工作量统计
这是信息科被问得最多的一类需求。科室主任想看的维度很多：收治患者数、手术量、平均住院日、床位使用率、费用结构，等等。传统做法是让开发写SQL从HIS里取数，做成一个固定报表放在OA里。问题是需求变化频繁，这个月想看按病区的拆分，下个月想看按病种的分析，每次都找开发改。
在米缀平台上，我把数据源直接指向HIS的统计视图，然后用可视化查询配置做了基础的聚合逻辑，包括按时间分组、按字段汇总、绑定筛选条件。页面部分用表格组件展示明细数据，用echarts图表组件展示趋势和结构占比。整个搭建过程不写一行SQL，纯拖拽和配置完成，耗时大约一个多小时，其中大部分时间都花在理解科室的数据口径上。
配置要点是：数据源连接复用、查询逻辑和页面组件解耦、筛选条件参数化。这样后面科室需求变化时，只需要在查询配置里调整条件或新增组件，不用重建应用。
场景二：科室耗材领用审批流程
医院内部的审批流需求多而杂，耗材领用、设备报修、请假申请、外出学习审批，每个流程的参与角色、审批层级、表单字段都不太一样。这类需求用传统开发模式做，需要建表、写流程引擎配置、做前端页面、联调测试，工作量不大但很琐碎。
米缀平台的表单设计器和流程编排能力在这里就能派上用场。我在平台上配置了一个耗材领用申请单，字段包括申领科室、耗材名称、数量、用途说明，表单页面用拖拽搭建。流程配置里设置了三层审批路径：科室负责人审批、库房审核、分管院长审批，各级审批人可以在平台里配置。这个应用从搭建到测试完成，耗时比统计类应用还要短，大概四十分钟。后续如果想调整审批层级或增加抄送人，在流程编排里改动即可，完全不用走发版流程。
3.4 米缀平台适配性评估的结论与边界
做完了这些POC场景之后，我对米缀平台在医院场景下的适配性结论是：它在数据密集型的内部应用场景里适配性很强，尤其是报表、图表、数据录入和流程审批这几类需求，交付效率提升很明显。它比较适合医院信息科用"业务化思维"去构建应用，而不是把它当成一个纯粹的前端开发工具。
再说边界。如果你的需求是高度定制化、交互极其复杂、面向外部用户的互联网应用，低代码平台不一定是首选，米缀平台也一样。医院的内部应用大多数是标准的管理信息类系统，这正好在低代码平台的舒适区内，但千万不要因为某几个场景跑通了，就把低代码当成万能药延展到所有场景，这是我在大量项目里见过的最典型的误判。
4. 如何做一次靠谱的低代码选型评估
4.1 选型评估的工作流程设计
评估低代码平台不能靠现场看一遍demo、听厂商讲一遍PPT就拍板。我在实际操作中一般把选型评估拆成五个阶段，每个阶段都有明确的动作和产出。
- 需求梳理：和院内各科室做一轮需求征集，把未来一到两年内需要用低代码承接的应用场景整理成清单，标注优先级和核心复杂度。
- 产品初筛：结合信通院白皮书的能力维度，对照厂商提供的产品资料，把明显不匹配的产品淘汰掉。
- POC测试：选用院内1到2个真实需求场景，让厂商在测试环境里搭建出可运行的应用，信息科工程师全程参与。
- 综合评审：以POC结果为事实依据，对照预先制定的评估表逐项打分，邀请业务科室代表参加，听取使用感受。
- 试点上线：选一个低风险场景先试点，跑通后再逐步扩大范围。
这个流程看起来不复杂，但每个阶段都有值得展开的细节，下面说几个容易踩坑的关键点。
4.2 POC测试不要被厂商牵着走
POC测试是整个评估环节里最核心的部分，也是最容易被厂商"设计"掉的部分。有的厂商在演示环境里专门做了医疗行业的示例应用，数据是造好的，流程是提前跑通的，你去看的时候一切顺滑，但一旦换成院内真实数据和真实逻辑，问题就会暴露出来。
所以做POC测试时有一个原则：用你自己的场景、你自己的数据、你自己的网络环境。哪怕只是从HIS里导出一张脱敏后的真实结构表，也远比厂商造出来的演示数据有价值。这个过程中你要看的不只是应用能不能搭出来，还要关注几个隐形指标：
一是搭建过程是否顺畅。是图形化配置为主，还是时不时要写代码？如果必须写代码，写的是通用的JavaScript/SQL，还是厂商自创的脚本语言？后者意味着你在未来会被厂商深度绑定。
二是遇到报错时怎么排查。低代码平台最怕的是黑盒，报错信息不明不白，出了问题只能找厂商。POC阶段可以故意设置几个异常场景，比如把数据源密码改错、把字段类型配错、把流程节点指向不存在的用户，看看平台的报错提示是否清晰，看看工程师能不能独立定位问题。
三是看平台生成的应用运行起来性能如何。医院的报表动辄上万条记录，加上多表关联和筛选，如果分页加载很卡、图表渲染很慢，这在实际使用中会非常影响体验。POC时直接用大数据量去压一下，比自己事后后悔要强得多。
4.3 评估打分表的设计思路
评估打分表不需要搞得太复杂，但一定要在POC之前就设计好，让参与评估的所有人使用统一标准，尽量避免"凭感觉打分"。
我一般会把评估项分成两部分：硬性指标和体验指标。硬性指标是"不满足就淘汰"的一票否决项，比如是否支持私有化部署、是否能对接院内数据库类型、是否具备审计日志能力等。体验指标是打分项，比如搭建效率、权限配置便捷度、图表组件丰富度、厂商服务响应速度等。
打分表设计好之后，建议在POC开始前发给参与评审的同事，让大家带着问题去看，而不是等到POC结束时再临时打分。这样能大幅提升评审的有效性。另外，一定要让业务科室的用户代表参与打分，他们不看技术实现，只看"好不好用、能不能满足需求"，这个视角和信息科工程师完全不同，两边意见合并在一起才有参考价值。
4.4 厂商服务能力怎么考察
低代码平台选型，选的不只是产品，还有厂商。医院项目的实施周期和决策链条都比较长，厂商的本地化服务能力直接决定了项目上线后的体验。
考察厂商服务能力时，最有效的办法不是看宣传册，而是直接问几个实际问题：你们在医疗行业有哪些落地案例？能不能提供客户联系方式让用户去打听？产品多长时间发一次版本？版本升级是免费的还是额外收费？遇到紧急故障时，技术支持的响应时间是多久？这些问题如果厂商回答得含糊，你就要多留个心眼了。
还有一个很多人忽略的细节：不要只看厂商总部的实力，要重点看本地团队的配置。低代码平台在上线初期一定需要厂商驻场支持，本地团队如果没有足够的技术人员，出了问题远程沟通的效率会非常低。米缀平台在POC期间的支持响应速度给我印象比较深，配置过程中遇到的问题基本都能在当天得到回复，这个服务效率对医院选型来说是加分项。
5. 医院低代码上线的常见问题与避坑实录
5.1 平台有了，但没人会用
医院上了低代码平台之后，最容易出现的问题不是技术问题，而是组织问题。平台买了、部署了、培训也做了，结果三个月之后，平台上跑的应用还是厂商在试用期做的那几个demo，信息科没人主动去搭建新应用。
出现这种情况，根本原因是把低代码平台的推广想得太简单了。低代码不等于零代码，平台只是降低了开发门槛，使用者仍然需要具备一定的逻辑思维和数据处理能力。医院信息科里真正有时间、有兴趣、有能力去研究新工具的工程师，其实并不是多数。
我的建议是，平台上线初期要找到一个"种子用户"或"种子团队"，这个人或团队不一定技术最强，但一定要对用工具解决问题有热情。先带着他们做出两三个有影响力的应用，让院内看到效果，再去推动普及，阻力就会小很多。一上来就铺开全员培训，结果往往是培训完就完了，没有后续动作的话留存率低得吓人。
另一个有效的做法是建立"低代码应用集市"。信息科把平台上已经开发好的应用统一发布出来，按科室、按场景分类，业务部门可以直接申请使用。这样既能避免重复开发，也能让更多的人看到低代码平台的实际成效。
5.2 数据权限和审计合规怎么做
医院低代码应用涉及患者数据和经营数据，权限控制和审计日志这两件事绝不能省。很多低代码平台自带的权限模型比较粗，只能控制到菜单和按钮级别，做不到行级数据权限。比如同一个统计报表，科室主任只能看本科室数据，院领导能看全院数据，这就要靠行级权限来控制。
米缀平台在数据权限这块提供了比较灵活的控制方式，可以在数据源或查询层面配置权限过滤条件，支持按当前登录用户的属性动态过滤数据。配起来不复杂，但需要在应用设计阶段就考虑好，等到上线后再补就会很麻烦。这个点建议选型时重点确认，否则后面做成千上万个应用时，隐私合规的风险会变成一颗定时炸弹。
再强调一遍审计日志的重要性。低代码平台上如果跑着涉及患者隐私数据的应用，每一个查询、导出、修改动作都要留下记录。平台自带的审计能力如果不够细，至少要把应用接入医院现有的安全审计体系里。不要因为应用开发得太快而放松了对数据安全的把控，开发快和省事不等于可以不守规矩。
5.3 性能瓶颈和数据处理能力
低代码平台在应用开发效率上有绝对优势，但在性能上往往不如定制开发的原生方案。医院的数据量在某些场景下非常大，比如PACS的影像数据、HIS的门诊记录、LIS的检验结果，如果直接把几千万行的表拉来做分析，很多低代码平台会扛不住。
低代码平台在处理这类问题时，通常的思路不是"硬扛"，而是"绕开"。比如用视图或者物化表预先聚合数据，让前端展示的是经过预处理的中间结果，而不是直接查底表。又比如利用定时同步，把数据从核心业务库同步到低代码平台的查询库，既减轻了源库压力，也保证了查询性能。
用米缀平台测试时也能感受到，对大数据量的处理，合理配置数据过滤和分页非常重要。图表的数据源尽量用聚合后的结果集，不要一次性加载全量明细。数据模型设计得好，低代码平台就能在你需要快速交付应用、数据量控制得又不算特别夸张的绝大多数场景中表现良好。
5.4 避免新的"平台锁定"
低代码平台用久了，会产生一个新的风险——平台锁定。应用在平台上搭得越多，迁移成本就越高，到最后换平台的代价可能比当初从传统开发迁移到低代码还要高。
选型时就要评估这个风险。主要看三个方面：一是平台生成的应用是否支持导出标准代码？二是平台是否提供开放的API，让应用可以被外部系统调用？三是平台是否支持常见的数据格式导出，比如Excel、CSV、JSON？米缀平台在这些方面做得比较开放，应用对外提供API访问能力，数据层面也支持常见的导出方式，这在一定程度上降低了平台锁定的风险。
但说句实话，平台锁定这个问题，现阶段所有低代码厂商都不可能彻底解决。医院能做的是在选型时就把这个因素纳入考量，同时内部建立一定的应用治理规范，避免在低代码平台上无限堆叠应用而不做归集和治理。
6. 选型之后的落地路径建议
6.1 从见效快的场景切入
低代码平台在医院能不能持续用起来，第一仗很重要。如果第一个应用就选了个特别复杂的业务，做的时候磕磕绊绊，上线问题不断，后续推广基本就凉了。
我的建议是从报表类、统计类场景切入。这类应用对流程交互的要求相对低，主要工作集中在数据接入和页面呈现上，一旦数据链路跑通，见效非常快。临床科室看到你几天之内就交付了一个以前要排几周周期的报表，后面再推低代码平台去承接流程类应用，阻力就小很多。
6.2 建立内部的小团队和规范
低代码平台不是装好就完事的工具，它需要持续运营。医院内部最好有一到两名的工程师专门负责平台的建设和维护，同时建立一套简单的应用开发规范，比如命名规范、数据源管理制度、应用发布审批流程、权限复核机制。这套规范不用一开始就很复杂，但要随着平台上应用数量的增加逐步完善。
6.3 借助厂商力量但保持主动权
在低代码平台推广初期，可以要求厂商提供深度支持，包括联合共创、定制培训、应用模板开发等。但有一点必须清醒：厂商的资源不会永远围着你的医院转，最终平台的运营能力一定要掌握在自己团队手里。尤其是在业务部门越来越依赖平台的情况下，如果内部没有能独立维护和迭代的人，一旦厂商服务收缩，平台上的应用就会僵在那里。
我接触过不少信息科同行，对低代码平台的态度从观望到尝试再到常态使用，大概会经历半年左右的过程。这个过程里，选型方法论、厂商配合度和内部推动力缺一不可。信通院白皮书解决的是"怎么科学评估"的问题，而米缀平台这类具体产品解决的是"某个场景下好不好用"的问题，两者结合起来，就是一个完整的选型决策路径。
回到最开始那个问题：医院如何选低代码？我的答案始终是——先回到医院自己的场景里去，把需求想清楚，把数据接线想清楚，把使用者的能力边界想清楚，再去看产品。低代码平台是工具，工具合不合适，只有拿自己手头的活儿试过才知道。这篇内容里提到的评估框架和POC思路，希望对正在做选型的同行有点参考价值。
