- 博客(192)
- 收藏
- 关注
RSS订阅原创 ODS详解——什么是ODS？
ODS（操作数据存储） 是介于源业务系统（如HIS、EMR、LIS、PACS等） 和后续的数据仓库或临床数据中心（如CDR） 之间的一种准实时或近实时的数据集成与暂存区域。简单来说，ODS 是：一个用于集中存放来自各个业务系统的、经过初步清洗和整合的、保持一定实时性或近实时性的操作型数据 的数据库或数据层。它不是最终的数据分析或决策支持数据库，而是为了支持部分实时查询、数据共享、数据转换和进一步处理 而存在的一个中间层。
2025-11-23 09:16:09
798
原创 医院信息集成平台数据层详解
ODS（Operational Data Store，操作数据存储）是数据层中最接近源系统的中间层，用于汇聚来自HIS、LIS、EMR、PACS等业务系统的原始或初步整合数据。它既不是直接面向终端用户的“最终数据”，也不是高度结构化的“临床数据”，而是连接业务系统与上层数据中心的“桥梁”。CDR（Clinical Data Repository，临床数据中心）是数据层中以患者为中心、高度结构化的临床数据集合，专门为临床诊疗、电子病历（EMR）、患者全景视图等场景设计。
2025-11-23 09:15:39
638
原创 数据质量技术规范（示例）
术语定义数据质量数据满足特定用途和业务需求的程度，是数据可信、可靠、可用的核心属性。数据校验基于规则对数据的格式、取值、逻辑关系等进行检查，以确保其符合预期标准。数据清洗对错误数据、缺失数据、重复数据、异常数据等进行识别、修正或剔除的过程。数据一致性相同数据在不同系统、表或字段中保持逻辑与内容上的统一。数据完整性数据的必填项完整、无缺失，符合业务与技术上的完整性约束。数据唯一性某一数据对象（如患者、订单、商品）在系统中具有唯一标识，不存在重复记录。数据及时性。
2025-11-21 18:25:26
799
原创 医院数据质量管理规范（示例）
术语定义数据质量数据满足明确用途的程度，通常包括准确性、完整性、一致性、及时性、唯一性、有效性等维度。数据质量问题数据在准确性、一致性、完整性等方面不符合预定标准或业务要求的情况。数据校验依据规则对数据的格式、范围、逻辑关系等进行检查，以发现潜在错误。数据清洗对脏数据、错误数据、重复数据、缺失数据等进行修正、删除或标准化处理的过程。数据责任人对某一类或某一数据对象的质量负主要责任的科室或个人。维度定义说明 / 示例准确性数据是否真实、正确地反映了客观事实。
2025-11-21 18:25:03
452
原创 医院数据标准技术规范（示例）
术语定义数据元（Data Element）数据的基本单元，由名称、标识、定义、数据类型、格式、值域等组成。编码（Code）为对象（如药品、疾病、科室）赋予的唯一标识符，用于系统间统一识别。值域（Value Domain）数据元允许取值的范围或集合，可以是枚举值、范围、格式等。数据格式（Data Format）数据在存储或传输中的表现形式，如日期格式、数值精度、字符串长度等。数据接口（Data Interface）不同系统之间进行数据交换的约定，包括数据格式、传输协议、调用方式等。
2025-11-20 13:25:49
566
原创 《医院数据标准管理制度》示例
数据标准：对数据的命名、定义、格式、取值范围、编码规则、分类体系等做出的统一规范。数据元（Data Element）：数据的基本单元，如“患者姓名”、“药品编码”、“检验结果”等。编码标准：对数据项（如药品、疾病、科室等）赋予统一的、唯一的编码，如药品编码、ICD疾病分类编码等。业务术语：医院业务过程中使用的具有特定含义的词汇或指标，如“药占比”、“平均住院日”等。数据治理：对医院数据资产进行规划、监控、控制与优化的一系列活动，数据标准是其核心基础之一。
2025-11-20 13:24:43
746
原创 数据质量管理系统（DQMS）
医院数据质量管理系统是一套用于监控、评估、改进和维护医院数据质量的信息化平台，通过对数据质量问题的发现、分析、预警、纠正和预防，确保医院数据在各个业务环节中真实、可信、可用。它通常作为医院数据管理平台或数据治理体系的一部分，也可独立部署，是保障医院数据价值与业务连续性的关键工具。维度价值体现临床方面保障患者安全，提升诊疗质量与效率，减少医疗差错管理方面支撑科学决策，提升运营效率与资源利用率科研方面提供高质量的数据基础，支撑真实世界研究、临床分析系统方面。
2025-11-19 13:20:02
877
原创 什么数据质量管理？
数据质量管理（Data Quality Management，DQM） 是指通过一系列策略、流程、技术和工具，对数据的准确性、完整性、一致性、及时性、唯一性、有效性等关键质量维度进行持续的监控、评估、改进和维护，以确保数据在整个生命周期中都是可靠、可信和可用的，进而有效支撑医院的业务运行、管理决策、临床服务和科研分析。数据质量管理就是通过规则、工具和流程，让医院的数据更准确、更完整、更一致、更可靠，从而让数据真正能用、好用、敢用，为临床、管理、科研等提供坚实支撑。问题回答什么是数据质量管理？。
2025-11-19 13:19:40
662
原创 元数据管理系统简介
元数据（Metadata），即“关于数据的数据”，它不直接是业务数据本身（如患者姓名、药品名称），而是描述这些数据的结构、来源、含义、关系、变更历史等属性信息。例如：数据对象示例对应的元数据数据库表（患者信息表）表名、所属系统（HIS）、创建时间、负责人、字段数、更新频率数据字段（患者年龄字段）字段名称、数据类型（int）、含义（患者实际年龄）、是否必填、取值范围、业务定义数据接口患者信息同步接口接口名称、来源系统、目标系统、数据格式、调用频次、负责人ETL任务。
2025-11-18 14:07:03
563
原创 什么是元数据？
元数据（Metadata）是描述其他数据的数据，用于提供数据的上下文、结构、来源、含义、关系、管理信息等，以支持数据的发现、理解、管理、使用和治理。元数据就是数据的“说明书”和“身份证”，它告诉我们：这是什么数据？（含义）数据从哪里来？（来源）数据长什么样？（结构）数据归谁管？（责任）数据怎么用？（用途）数据会影响谁？（关联）问题回答什么是元数据？元数据（Metadata）是“关于数据的数据”，用于描述数据的结构、含义、来源、关系、管理信息等，帮助人们理解、管理、追踪和使用数据。
2025-11-18 14:06:42
657
原创 医院主数据管理系统简介
医院主数据管理系统是医院信息化建设中非常关键的数据治理基础设施，它不仅解决了“数据从哪里来、数据是否可信、数据如何共享”的问题，还为医院实现数字化转型、智慧医疗、互联互通评级、DRG支付改革等提供了坚实的数据基础。如果您的医院正在考虑建设或升级主数据管理系统，可以从数据梳理、标准制定、系统选型、流程设计、治理机制等几个方面入手，逐步推进。
2025-11-17 17:55:11
876
原创 医院信息化中的主数据
医院信息化中的主数据是支撑整个医院信息系统（HIS、EMR、LIS、PACS、HRP等）运行的核心基础，其管理的好坏直接影响医疗质量、运营效率、患者安全和决策分析。因此，很多医院会建立主数据管理系统（MDM, Master Data Management），对这些核心数据进行统一的采集、存储、维护与分发，确保“一次录入、多处共享、一致准确”。
2025-11-17 17:54:47
1244
原创 HTTP 长轮询、SSE 、WebSocket 全面对比分析
技术优点缺点HTTP（长轮询）实现简单，兼容性好，无需额外协议实时性差，频繁请求导致高延迟、高开销、性能低下SSE实现相对简单，基于 HTTP，自动重连，支持文本流推送单向通信，不支持 IE，功能较单一WebSocket真正的实时、双向、低延迟、高效通信实现复杂，需要处理连接管理、协议细节，兼容性略低于 HTTP（但现代浏览器已普遍支持）技术一句话定位HTTP（长轮询）最基础的“请求-响应”通信，兼容性好但效率低，适合简单场景SSE服务端到客户端的单向实时流，简单高效，适合通知类应用。
2025-11-14 12:47:56
903
原创 Http长轮询详解
HTTP 长轮询（Long Polling），是一种基于标准 HTTP 协议的通信模式，用于模拟服务端向客户端推送数据的“准实时”效果。它是对传统“短轮询”方式的优化，通过延长单个 HTTP 请求的响应时间，让服务端在有数据更新时才返回响应，从而减少无效请求，提高通信效率与实时性。尽管名字里有“长”，但HTTP 长轮询并非一种新的通信协议，也不是一种官方标准，而是一种利用现有 HTTP 协议实现的“应用层通信策略”或“开发模式”。
2025-11-14 12:47:37
733
原创 SSE详解
SSE（Server-Sent Events，服务端推送事件）是一种基于HTTP 协议的服务器到客户端的单向实时通信技术。它允许服务端主动将数据“推送”到客户端，而客户端通过简单的 JavaScript API（）即可接收这些数据流。id: 123data: 系统即将维护，请保存工作\n\n适用 ✅不适用 ❌服务端需要主动、实时推送数据到客户端需要客户端向服务端发送消息（双向通信）消息是文本类型，比如通知、公告、日志、状态更新需要传输二进制数据（如文件、音视频流）希望使用。
2025-11-13 13:39:52
1078
原创 WebSocket详解
WebSocket是一种基于 TCP 的应用层通信协议，它通过HTTP 协议进行握手升级，在客户端和服务器之间建立一条持久的、双向的、全双工的通信通道，用于实现低延迟、高实时性的实时数据传输。WebSocket 协议使得客户端和服务器可以在同一连接上随时互相发送数据，无需重复建立连接或等待请求-响应，非常适合需要高频、双向、实时交互的应用场景。你需要客户端和服务端双向实时通信（如：聊天、游戏、协作）你追求最低的延迟和最高的实时性你传输的是高频、小数据量的消息（如状态更新、指令、通知）你希望使用。
2025-11-13 13:39:26
1423
原创 分享几个医疗信息化行业的术语
电子病历 (Electronic Medical Record，EMR) 是由医疗机构以电子化方式创建、保存和使用的，重点针对门诊、住院患者（或保健对象）临床诊疗和指导干预信息的数据集成系统，是居民个人在医疗机构历次就诊过程中产生和被记录的完整、详细的临床信息资源，是记录医疗诊治对象医疗服务活动记录的信息资源库，该信息资源库以计算机可处理的形式存在，并且能够安全的存储和传输，医院内授权用户可对其进行访问。
2025-11-11 17:50:12
805
原创 http与websocket的异同
获取静态资源（如 HTML、CSS、JS、图片）提交表单数据调用 RESTful API 接口普通的“请求-响应”模式业务逻辑不需要服务端主动推送信息的应用对比项HTTPWebSocket设计目标简单的资源请求与响应实时、双向通信通信方向单向（客户端→服务端）双向（全双工）连接方式短连接为主（可复用）长连接协议升级无通过 HTTP Upgrade 机制实时性较低（依赖轮询等）高适用性通用，适合大多数 Web 请求适合实时交互类应用如你正在开发一个需要。
2025-11-07 12:30:00
1432
原创 UML 4+1 视图用途介绍
用例视图就是从用户和外部系统角度看：“电商系统能提供哪些功能，谁来使用这些功能”。逻辑视图就是从系统设计者/开发者角度看：“系统内部有哪些功能模块，它们是怎么组织的，类之间如何协作来实现业务逻辑”。开发视图就是从程序员/架构师角度看：“代码怎么分模块、怎么组织、包之间有什么依赖关系”。进程视图就是从系统架构师/运维/并发编程者角度看：“系统运行时多个任务是如何并发执行的，服务之间如何交互与协同”。部署视图就是从运维/DevOps/架构师。
2025-11-07 12:15:00
19
原创 常见需求获取技术总结
通过与用户或干系人进行面对面、电话或视频交流，深入了解他们的需求、痛点、期望与业务流程。设计一组标准化的问题，以纸质或电子形式发放给大量目标用户，收集他们的需求、偏好、满意度等信息。直接到用户的工作或生活场景中观察他们如何执行任务、使用现有系统或处理业务，从中发现潜在需求与问题。从全部目标用户或干系人中，按一定规则（如随机、分层、典型）选取一部分有代表性的样本，再对这些样本进行访谈、问卷或观察，以推断整体需求。通过一系列图像、故事卡片或连环画的形式。
2025-11-06 12:30:00
699
原创 常见数据脱敏方法总结
方法是否可逆是否保留原数据含义适用场景示例替换可逆/不可逆部分保留测试数据构造姓名：张三 → 李四遮蔽/屏蔽不可逆部分保留（格式）展示类脱敏（UI/日志）手机号：138****5678加密可逆保留（需解密）安全存储/传输AES加密手机号乱序/打乱不可逆不保留（关系破坏）测试数据，破坏关联关系姓名与手机号错位匹配泛化不可逆降低精度保留大类数据分析、统计发布年龄：25 → 20-30岁取消/删除不可逆不保留合规删除、数据最小化删除身份证号字段。
2025-11-06 12:15:00
32
原创 电商系统高并发场景下库存扣减的线程安全实践：单体与分布式架构全方案详解
维度单体架构分布式架构典型部署单台服务器（如IIS/传统Tomcat），所有请求由同一进程处理多台服务器（负载均衡），多个服务实例共享库存数据库存存储位置数据库（主）或内存缓存（辅助，如本地字典）数据库（主）或分布式缓存（如Redis，主/辅）核心推荐方案数据库乐观锁（内存库存可选编程语言锁（如lock数据库乐观锁（跨实例通用）或分布式锁 + 缓存/数据库操作（复杂业务）或Redis原子操作（秒杀）或消息队列（削峰）是否依赖外部组件仅需数据库。
2025-11-05 14:33:37
233
原创 TCC（Try-Confirm-Cancel，预留-确认-取消）实现分布式系统数据一致性代码示例
/ 模拟HTTP客户端：跨服务调用工具（简化版）// 模拟调用库存服务// 实际是远程服务，这里简化为本地实例// 模拟调用支付服务// 实际是远程服务，这里简化为本地实例。
2025-11-05 13:20:27
29
原创 医院慢病管理软件系统需求规格说明书（基于PDOA方法·需求定义阶段成果）
本文档是医院慢病管理软件系统建设的需求定义阶段成果，基于前期《面向问题域的需求分析（问题域分析阶段文档）》中提炼的核心问题列表（如健康数据分散、患者依从性低等），进一步明确解系统（即本软件系统）必须具备的功能、性能及非功能需求，并定义核心数据实体与关系，为系统设计、开发、测试提供唯一的需求基准。术语定义解系统本需求文档中指“医院慢病管理软件系统”（即需要开发的信息化工具）健康数据患者的血压、血糖、体重、心率等生理指标记录（含测量时间、测量方式）随访计划。
2025-10-25 21:42:56
516
原创 医院慢病管理软件系统问题域需求分析文档（示例）
问题域（Problem Domain）：用户（医生、患者、医院管理者）在慢病管理实际业务中面临的真实场景、挑战与痛点集合（如数据分散、随访效率低等）。问题列表（Problem List）：通过调研与分析提炼出的、需要通过系统解决的核心问题（即需求的源头）。利益相关者（Stakeholder）：与慢病管理问题直接相关的角色（如慢病患者、门诊医生、护士、医院管理者）。
2025-10-25 21:31:50
614
原创 理解面向问题域的需求分析（PDOA）方法
对于开发团队：它能帮你做出真正解决用户痛点、符合实际场景的系统，而不是“看起来高大上但没人用”的工具；对于用户（比如医生、患者）：他们能参与到问题定义中，确保系统是“为自己设计的”，而不是“被强加的”；对于项目本身：它能降低返工风险、控制成本，让开发过程更聚焦、更高效。下次当你听到“我们要做个XX系统”时，不妨先问一句：“我们真的理解用户的问题了吗？” —— 这就是 PDOA 的核心精神：先理解问题域，再定义需求；先搞懂“为什么做”，再决定“怎么做”。毕竟，。
2025-10-25 21:24:11
1344
原创 一文带你学会用BPMN进行业务流程建模
本文将从BPMN的基础概念出发，带你逐步掌握其核心元素、典型应用场景及实际建模方法，即使零基础也能快速上手，用BPMN为业务流程“画出清晰蓝图”。
2025-10-25 20:49:03
1015
原创 描述业务流程模型的常见方法
方法核心定位关注重点适用场景通俗比喻标杆瞄准流程优化参考对比最佳实践，设定改进目标想提升效率但不知道“怎么做更好”时像“抄学霸的作业”，学习别人的优秀做法DEMO业务本质建模挖掘“必须发生的核心业务交互”需求分析、跨组织协作流程设计像“剥洋葱”，找到业务最内核的必要动作Petri网流程逻辑验证分析步骤流转、并发控制与潜在问题复杂流程的严谨性验证（如金融、工业）像“数学公式”，用逻辑推演流程会不会卡住BPMN业务流程可视化。
2025-10-24 13:10:39
714
原创 CDR、MDR、RDR、PDR解析
临床数据中心（CDR, Clinical Data Repository） 是医院内专门用于集中存储、管理临床相关数据的数据平台，以患者为中心，整合来自医院各个业务系统（如 EMR、HIS、LIS、PACS 等）的临床信息，为临床诊疗、病历调阅、临床决策等提供统一的数据支撑。管理数据中心（MDR, Management Data Repository） 是面向医院管理决策、行政办公、质量控制与绩效管理。
2025-10-24 13:10:16
653
原创 以电商系统为例，理解用户体验五层模型
用户体验五层模型包括：战略层（Strategy）：明确产品目标与用户需求范围层（Scope）：确定产品要提供哪些功能与内容结构层（Structure）：设计功能与内容的组织逻辑与交互流程框架层（Skeleton）：规划功能在界面中的布局与信息架构表现层（Surface）：视觉设计与用户感知这五层从抽象到具体，从目标到呈现，构成了一个完整的用户体验设计体系。层级核心目标电商系统对应内容关键产出物举例战略层明确产品目标与用户需求。
2025-10-19 10:11:55
115
原创 软件架构4+1视图中的进程视图该怎么画？
画进程视图的核心，就是用一张图说清楚：谁在干活？（执行单元）怎么配合？（同步/异步/共享数据）要注意什么？（资源限制和容错）即使你的系统目前并发量不高，这张图也能帮你提前发现潜在问题，避免未来扩展时“改一处崩全局”。记住：好的进程视图不需要华丽，只要能让团队成员（开发、运维、测试）一眼看懂系统的“动态运行逻辑”，就是成功的架构设计！
2025-10-19 10:07:27
82
原创 关于UML顺序图中“消息”的一点思考
在UML顺序图中，“消息”严格定义为一个对象（发送方）向另一个对象（接收方）发起的调用请求，目的是要求接收方执行特定的操作或行为。其核心特征可概括为三点：主体是对象间的交互：消息存在于系统内部的对象（如类实例、组件、服务等）之间，而非用户与系统之间直接的物理行为；本质是行为调用：消息名称通常是动词或动宾短语（如），描述接收方需完成的具体动作；目标是触发操作：发送方通过消息“请求”接收方执行逻辑，而非描述发送方自身的行为。
2025-10-19 10:02:38
67
原创 一份软件系统性能测试报告示例
问题编号问题描述严重等级根因分析优化建议BUG-001并发≥100时，首页响应时间超5s，错误率1.5%高应用服务器CPU饱和，Redis缓存未完全覆盖商品数据1. 应用服务器扩容（CPU≥8核）；2. 热点商品预加载至RedisBUG-002并发≥200时，订单提交失败率4.9%，数据库连接池耗尽严重MySQL最大连接数默认151，不足1. 调整连接池至300；2. 优化连接释放逻辑BUG-003稳定性测试中，应用服务器频繁Full GC（每2分钟1次），响应时间逐渐上升。
2025-10-18 10:39:14
41
原创 一份软件系统性能测试计划模板
指标类别具体指标定义目标值（预期）响应时间页面/接口响应时间从用户发起请求到收到完整响应的时间（含网络传输+服务器处理）。首页≤5s；订单提交≤4s事务平均响应时间单个业务流程（如“进入首页→加载完成”）的平均耗时。≤5s（并发≤100）事务最大响应时间单个业务流程的最长耗时（需控制极端情况）。≤10s（并发≤100）吞吐量TPS（每秒事务数）系统每秒成功处理的事务数量（如“提交订单”为一个事务）。≥100（并发≤100）成功率事务成功率。
2025-10-13 17:21:40
55
原创 一份软件系统性能需求文档示例
本性能需求文档从用户视角与业务目标出发，明确了电子商城系统在不同运行环境与负载条件下的性能目标，涵盖响应时间、并发能力、吞吐量、可用性、扩展性等关键维度，为系统全生命周期的性能保障与优化提供明确依据。建议在开发各阶段持续开展性能评估与测试，并在上线前完成全链路压测，确保系统在实际运行中达到本文档所定义的各项性能指标。✅ 附录（可选，可根据需要补充）《电商系统用户访问量与并发量预估》《核心业务流程与接口清单》《系统架构设计（含缓存、消息队列、数据库方案）》
2025-10-13 17:21:04
428
原创 质量保证（SQA）计划书-demo2
本文档明确 "[电商系统名称]" 项目的软件质量保证（SQA）活动框架，通过系统化的过程监控与改进，确保项目交付的电商系统符合业务需求、技术标准和用户期望，降低质量风险，提升系统可靠性与用户体验。
2025-10-11 14:22:47
44
原创 质量保证（SQA）计划书-demo1
本计划适用于电商系统建设全生命周期（需求分析→设计→开发→测试→部署→验收），覆盖所有核心模块（用户中心、商品管理、订单支付、营销中心、物流跟踪等）及关联的配套文档（需求规格说明书、设计文档、测试用例、用户手册等）。组织需求评审会（参与角色：产品、开发、测试、SQA），验证需求的完整性（无歧义/矛盾）、可测试性（每个需求可设计验证用例）及一致性（与业务目标对齐）。：功能测试（覆盖所有用户场景）、性能测试（模拟高并发）、安全测试（渗透测试+漏洞扫描）、兼容性测试（多端/多浏览器）、UAT（用户验收）。
2025-10-11 14:22:18
40
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人