his一般都有内部的UI设计，内部的控件，外面很难拿到手，而且现在都在bs化，你为什么要进delphi的坑呢？
当然，一定要做也不是不可以。
至于UI控件嘛，其实都有平替方案，最难搞的其实是电子病历，也就是图文混编，如果你能做到word那样就差不多了。
另外还有一个比较麻烦的就是各设备的接口，有很多公司的接口其实是不对外开放的，你要解析他们的数据、与他们做对接会有很大的运气成分在里面。

HIS 其实应该用 Delphi 而不应该用 WEB。
因为 HIS 里面有大量的输入界面，WEB 很难做到那么复杂功能。而 Delphi 能够做到。
比如录入的时候的 Grid，下拉，选择，这个下拉选择框里面，可以很复杂。用 DBGridEh 可能都不够。
病例编辑界面，那就是相当于 WORD 的功能，我知道很多是 Delphi 做的。

我不知道楼上的几位是否有真的做过his。

首先说bs和cs的选择：
cs的his目前能看到的是大部分是pb，delphi，.net这三个。
bs的his目前能看到的大部分是js+java，人好招，也都有成熟的前后端框架，而且天生跨平台，方便的在linux或国产系统下跑满足信创要求。
还有一种就是上面提到的，基于cef套壳的bs、cs结合体，这种需要投入的研发会多一些，尤其是要跨平台的时候，可能要自己做一些适配工具。

不管cs还是bs或者是结合体，你还需要一个成熟稳定的后端服务，当然，cs你直连数据库也是可行的，看医院体量，小医院足以应付。

不存在说哪个东西只有cs能做bs不能做，或只有bs能做cs不能做，取长补短两者结合的产品已经随处可见了，因为你his还要和其他系统做对接甚至是嵌入，其他系统可是五花八门的。至于和硬件交互比如读卡这些，厂商都有现成的bs方案，实在不行本地启个cs开发的http server后bs的任督二脉立马全打开了，不存在说什么bs部署方便cs部署不方便，只是bs部署是浏览器帮你做了而已，浏览器不是cs程序么？

选择哪种技术还要考虑：公司能持续的技术人员强项是哪些？是否要考虑跨平台和信创？产品边界在哪里？产品周期预计多久？打算投入的money是多少？目标客户群体是哪些级别？

然后说UI框架，
cs的基本上就是各自平台那几个ui控件包，有能力的尽量自己开发，如果你想长期在这个hit行业浸润，对于第三方是能不用就不用，实在没时间开发也要在用的时候考虑好后期自己开发替换留出预案。
bs的就是vue、react、easyui这些了

两者都需要做好造轮子或改造轮子的准备，需要自己改造的控件一般有：用于查询区间的日期时间控件、医嘱的grid控件(这个最为重要)、床位卡控件(护理上用的多)、表单组合控件（有些业务界面是其他几个业务界面组合出来的）、报表工具、一些可能的图表曲线控件(如体温单、产程图)等，还有一部分控件需要考虑外采，比如病历部分如果也自己开发需要病历编辑器。具体哪些要做，还是要看产品边界内涉及到哪些业务。

其实his更多的是业务，你把业务搞明白了再开发少走很多弯路，一定要整个流程走通了再开发，会省事很多很多很多事，否则很容易做半截发现后面按原来的设计走不下去，然后已经做的又不想tui翻，于是就各种的折中和凑合，给后面长期发展增加成本。盒子里不也有卖his产品源码的帖子吗，有条件不妨交点学费，或许拿来就用也说不定。
his说白了就是围绕三个字，人财物，人就是医护患者等，财就诊疗、绩效工资、医保结算等，物就是药品、耗材、检查检验等。业内经常说，能把账算对了这个his就算不错了。

his面对的医院不同，业务细节也不同，但临床业务基本上大差不差，系统开发时要考虑弹性，要做好下家医院界面和数据处理都要重新弄的准备，要极力避免上一家医院一个代码版本，后面会拖死你，可以考虑引入一些脚本处理业务，界面使用可配置生成，脚本和界面和业务处理一定要放到数据库里，这样同一套程序连接不同医院数据库就是不同的处理逻辑和ui，我也亲眼见过这样的产品，如果你的抽象能力极强，最终你很可能会发现，你做的并不仅仅是his系统，而是做了套业务开发框架，通过配置和少量额外工作就能变成其他行业的业务系统。我这边目前也投入了一些资源在做业务开发框架，和其他框架不同的地方是，我做的框架要集成一个开发调试工具，允许直接调试修改脚本或规则后运行，相当于在服务端放了个IDE进去，还要实现一个业务逻辑脚本支持pascal，c或js多种脚本语言混合使用（你能招到哪种程序员，就用哪种脚本），可是进度缓慢，目前在脚本解析器的开发阶段，扯远了。

至于病历编辑，严格来说不是his的功能，但小医院可能希望你也做了至少有个简单的也行，避免二次采购和集成成本，病历系统有需要了你再说，我会知无不言，如果你需要排版编辑软件，那你找我，我专门做这个的，有开源版本，也有收费版本，有cs版本也有bs版本，有delphi版本也有.net版本，有js版本也有c++版本，都是纯原生的语言开发的，不需要弄成ocx或dll，小医院开源版本足够用了。

又扯多了，总之医疗、教育这两颗长青树，有生之年永远不过时，his在医院算是非常重要的系统，其他系统都围绕着他转，有些his产品都不要钱的往进去冲，要的是后面的其他系统接口费维护费，在今天已经很少有新公司开发his了，但任何行业都需要新鲜的血液，如果“目及”范围有不少客户，有愿意配合的医院，有重视信息化的领导，有能包容产品循序渐进的一线医护，有志同道合的伙伴，有想做事的心，天时地利人和都叫你占了，那就开干，犹豫一下都是对我说这么多的不尊重。

跨平台只是个小问题，对于web客户端来说，天生跨平台。我做过政府的项目，总体来说与诊疗系统差不多。
鉴于知识的限制，我只能做lazarus的跨平台系统和windows服务器+web系统。
lazarus跨平台没问题，但没有适合的web开发工具，因此只能做linux arm\loongarch的CS。
delphi+unigui+RTC，做成windows服务器，用rtc替代unigui的数据处理功能，只用web组件，kylin的浏览器与win的没差别，但是读卡扫描不知道怎么弄，如果是kylin，只能用lazarus做一个桌面扫描模块，读取数据后到bs里刷新。
反正js学不来，这把年纪，也就跟定delphi/lazarus/pascal了，反正跨平台、移动、web都可以做得像模像样的。
这几天还发现rtc似乎与unigui+fastreport有冲突,可能与线程有关。

这领域技术最前沿的应该是nl2his
关键在于DSL。因为现在的LLM还没聪明到可以根据自然语言就能自动产生高级语言（delphi等）的代码，所以，把DSL作为中介LLM推理起来就简单很多。
问题是在his领域，还没一款dsl做到能完全表达整个系统而无需使用高级语言编程。
像网易的CodeWave，也只能用AI辅助写一些简单的业务逻辑。
所以，除了如何充分发挥LLM的作用外，关键在DSL。
一旦有一款DSL出现，使用它后无需编程，就比较容易实现nl2his，否则，LLM对于低代码平台更多是噱头。
本来，
低代码平台供应商在那些深耕某行业的信息服务商面前，只能啃骨头喝汤，肉都没能力强。
现在随着LLM的辅助编程，以后连汤都没得喝了。
所以，现在大多数低代码平台都没有大的投资价值，包括outsystems、轻流、宜搭、简道云等等。

窗口Spy足够你去了解坐标用的组件，坐标HIS基本上用dev组件了，你把dev常用的组件搞熟了，做点小系统足够了，而且兼容性又好，资料多，升级也方便；