系统简介
SaaS模式Java版云HIS系统源码，在公立二甲医院应用四年，经过多年持续优化和打磨，系统运行稳定、功能齐全，界面布局合理、操作简便。
1、融合B/S版电子病历系统，支持电子病历四级，HIS与电子病历系统均拥有自主知识产权。
2、全套系统采用云部署模式，部署一套可支持多家医院共同使用。
3、适用于二级医院、基层医疗机构，可作为区域HIS使用，经扩展后能够应用于医联体/医共体。
4、具有独立的配套SaaS模式运维管理系统，支持远程运维，运维功能丰富、方便易用。
5、系统技术特点：采用前后端分离架构，前端由Angular、JavaScript开发；后端使用Java语言开发。
6、系统遵循服务化、模块化原则开发，具有强大的可扩展性，二次开发方便快捷。
7、全套开发文档和产品文档，助力快速熟悉和掌握源码。
HIS系统作为医院信息化的核心业务系统，如今已成为各个医疗机构的必备品了。大到三级二级医院，小到社区卫生服务中心，门诊（门诊管理系统也可以理解为门诊的his系统，只是功能简单，模块较少）。随着国家对医院信息的要求逐步加大，对于各级医院机构的his系统也是提出了更多的要求。
1、一体化优先，避免多系统拼凑堆砌
一体化并非是指大家理解的一套系统，它应基于平台化，前端功能界面一体化，使用者在不同业务界面无任何异构感知，后端数据结构灵活开放，依赖平台服务总线，标准接入，那怕是其他异构系统也可采取和内部系统一样标准“插入”总线，这样既满足了医院业务对系统一体化的要求，同时也实现医院内部数据资源的共享，将有效数据充分利用起来，供医护人员、管理者使用。
2、适当考虑前瞻性，保障“地基系统”持续性
HIS系统作为医院信息化建设的“地基”系统，支撑着全院的各个环节业务实现，牵涉面广，牵一发而动全身，其重要性和支撑性不言而喻，对其稳定性和持续性的要求很高，不建议频繁换购，所以在选择HIS系统时，需从多个角度去考虑，适当兼顾一定的前瞻性，有利于保障“地基系统”持续性。同时系统应内置了医疗相关的国标、行标、团标、规范、指南的相关标准，为互联互通评测及系统交互奠定基础，并尽可能支持开源数据库、国产操作系统、国产加密等（不一定是现在就要应用），最大程度考虑未来信息系统的发展要求。
3、注重信息智能化，避免传统记录型
与之前的HIS相比，云HIS系统在互联互通的基础上，完全可以拥有智能化服务，不仅信息更加精准，还拥有智能化的辅助录入、智能化管理功能，支持智慧医院的运行。在电子病历系统上，智能化应用也得到了广发的应用，如在医生下达传染病诊断或慢病诊断时，系统会自动弹出上报表单要求医生填写，可以根据医院需求设置必须填写，稍后填写，提醒填写等，并在管理模块中记录填报流程及结果。系统支持多种规则的自定义设置。 在危急值的管理中，系统智能化管理尤为重要，在检验和检查结果中出现危急值时，系统会即时在医生工作站提醒医生处理，同样系统也会根据医院需求设置不同的处理方式，但医疗质量管理模块中会详细记录整个危急值的处理流程和结果，大大加强了医疗质量管理的可追溯质控。
4、追求开放型，拒绝封闭式
医院对医疗系统的需求是多样化的，目前要做到一套包括完整生态链的系统不容易，所以系统一定要是开放的。封闭的系统，会给用户使用功能扩展带来不便。预留系统接口，方便用户后续对接其他外部系统，更好地支撑医院的业务拓展。一套技术成熟的HIS系统架构应基于平台化设计，利用集成服务总线（HSB）（当然也可以是内置HSB），包括自身内部业务系统也同样是通过HSB与之集成，实现前端业务系统应用一体化，后端各个业务系统分离独立。
5、支持报表自定义设计，满足业务的多方面统计分析
HIS系统是医院的业务系统，业务系统运行产生了海量的业务数据，我们称之为生产数据，而医院管理上所需的数据就需要从生产数据中通过报表来提取满足不同业务科室或医院管理的要求，如医院的财务科、医务科、护理部、质管办、病案室、后勤科、药剂科等科室对数据分析的需求多方面，一些HIS厂商实现这些统计有的开发界面，有的报表统计，且多数都是有偿的，或者在实施期内限制数量，但后期都需要收费，且还需要提交研发部门才能实现，要等待1-2周时间甚至更长，而这些业务科室要数据又比较急迫，这样就导致了很多业务科室被迫手工统计，久而久之，如果做出来还不准确，科室很多就懒得提了。选择HIS时应特别注意这类统计查询的实现方式，尽可能使业务层面的各类查询通过系统自带的自定义报表实现，且永久免费，不管在实施期还是维保期，只要客户提出来格式和数据算法，现场工程师都可以快速实现，不受制于开发（一旦设计开发，周期往往很长），避免医院着急要数据时迟迟出不来的问题。同时软件公司应提供对医院信息管理员的报表培训（主要涉及一些SQL语句增、查、删、改），保证一些简单数据医院自己也可以“拉”出来。另外需要特别注意设计出来的报表不能受系统升级的影响，避免由于系统升级带来的报表无法使用或统计不准等问题（这一点需特别留意，一般涉及开发的统计系统升级就容易被“冲”掉了）。
6、支持系统模块化可配置，杜绝系统架构固化
医院系统的设计不仅要立足当前应用需求和相关技术的发展，还应充分考虑未来的应用需求的增长和发展需要，能够不断扩展应用规模与服务类型，使系统建设具有较好的继承性和可扩充性。
一套好的HIS系统，应基于模块化开发，降低系统之间耦合性，模块化升级；后台数据分域、分区存储；可灵活配置的系统架构，便于后续的模块扩展升级，增加新的功能模块，支撑好医院的业务拓展，医院也可以根据自身需求，选择关闭某些功能，更好地适配医院业务需求。
7、系统支持专科信息化，更好满足科室专属化要求
随着医院快速发展以及高质量发展的要求，对医院信息化也提出了更高的需求，尤其在一些重点人群的科室，如：儿科、产科、慢病科、康复科等，不仅仅只是满足患者的治疗需求，同时还需要满足对患者的健康管理，全生命周期的专科数据采集和记录，垂直条线的监管要求等等，针对类似专科化需求，很多科室只能无奈使用医院统一的HIS系统，导致了医生护士重复录入，大量的碎片化条线系统之间形成大量“信息孤岛”，无法共享，降低了医护人员的工作效率，同时也无法掌握患者的全生命周期的健康数据。在选择HIS系统时，如医院某些专科规模比较大，业务复杂，就需要利用智能化的手段，加强贴合专科诊疗路径闭环打造、全生命周期的专科数据采集和记录、数据专科化呈现和分析，和以专科知识库为基础的智能辅助决策支持等方面，更好地适应专业的科室级应用，而这类专科系统最好还是在HIS系统上的一种延伸和深入，如采购单独的专业系统，在业务交互和数据共享上又是一个问题，毕竟科室的临床业务还是和其他科室基本是一样的。这一点在选择HIS时，也是考虑的一个方面。
8、系统支持集团化应用，满足一体化管理
集团医院、医联体医院、连锁医疗机构对医院信息化的要求不同于单体医院的信息系统，很多HIS在单体医院运行正常，但面对集团医院时，一般简单理解为一个个分院（或集团下的医疗机构）当作科室来维护，这样简单的设置后，虽然可以简单满足应用，但在基础目录的维护和后期集团对应用数据的统一管理分析上确“捉襟见肘”，这和信息系统的架构设计有关。尤其是未来发展比较大的医疗机构，在选择系统时就需要考虑到云HIS的应用。可以查看在HIS系统的基础数据维护时，如：三大目录（收费项目、药品目录、医嘱项目）的是否可以针对每一个项目设置到不同的医疗机构使用，是否可以设置为公用和私用。系统部署时是否是同一数据库，同一标准，同一基础目录，前端业务是否能各自独立运行，互不影响，如：某个药品规格可以单独设置，单独调价，单独设置属性等。后端又能保证基础数据统一维护，业务数据统一管理，统一分析。其实一个好的云HIS系统不仅可以实现医疗流程信息化，最大程度方便患者就诊，也为全院的管理水平现代化和领导决策的准确化打下坚实的基础，在节省医院运营成本，提高工作效率上起到了关键作用。此外，好的系统一定具备前瞻性，灵活开放，既能满足医院业务需要，也能兼容其他外部系统，同时也能实现功能的持续化升级、拓展，助力医院的可持续发展。
