惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Y
Y Combinator Blog
博客园_首页
量子位
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
H
Help Net Security
The Cloudflare Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
A
About on SuperTechFans
腾讯CDC
H
Hackread – Cybersecurity News, Data Breaches, AI and More
D
DataBreaches.Net
L
LangChain Blog
Stack Overflow Blog
Stack Overflow Blog
Jina AI
Jina AI
月光博客
月光博客
云风的 BLOG
云风的 BLOG
博客园 - 聂微东
Hugging Face - Blog
Hugging Face - Blog
雷峰网
雷峰网
C
Check Point Blog
V
V2EX
T
Tailwind CSS Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Microsoft Security Blog
Microsoft Security Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
HIS产品设计手册-门诊常用处方及药品
吴之猫 · 2024-04-10 · via 人人都是产品经理

书接上回,上篇文章介绍了门诊处方开立的一些基本概念和基础的录入设计。这回我们接着介绍一些门诊处方开立过程中帮助医生提升系统操作效率的辅助功能。

一、常用处方维护与开立

常用处方是指医生将常用的处方在系统中预先维护,在看诊过程中直接引用事先维护的常用处方从而快速完成处方开立的操作。

1. 常用处方维护

1.1 使用范围

常用处方的第一个属性是使用范围。使用范围一般包含个人、科室、全院三个。

使用范围决定了该常用处方在开立时能被选择的范围:

  1. 个人常用处方,在开立时只能个人登录的账号可以看到。
  2. 科室常用处方,只要用户登录地点为属于维护的科室范围,就能使用该常用处方。
  3. 全院常用处方可供登录在全院所有地点的用户使用。

对于大型的三甲医院,科室并不是只有一级,而是依据级别和位置细分的科室树。比如内科下有内分泌科,内分泌科又可以细分为内分泌科门诊和肥胖、高血压、糖尿病等专病门诊。如果医院有多个院区,那么单单内分泌科门诊就可以分为A院区内分泌科门诊、B院区内分泌科门诊、C院区内分泌科门诊等等。

对于科室常用处方维护,需要支持用户能够选择需要的科室层级进行维护。例如一个用于糖尿病治疗的常用处方,可以设定它在内分泌科全部适用还是只在糖尿病专病门诊适用,设定只是在A园区的内分泌科门诊适用,还是可以共享给所有院区的内分泌科门诊。

同理,有多个院区的医院,在逻辑上也可以在“全院”这个范围上再细分二级的院区。但本身全院常用处方的使用场景就比较少,一般情况下也没有必要设计院区层级。

1.2 维护字段

  • 处方名称:用户为该常用处方起的名字。
  • 拼音码及五笔码:用于开立时快速检索。系统根据录入的处方名称自动生成,拼音码为名称汉字的首字母,用户也可以自己修改。
  • 药品名称及规格:维护功能的药品数量限制与开立时相同。一般情况下,所选的药品范围是所有药品字典启用的药品。对于一些字典数据质量不高,不用的药品没有及时停用的机构,可以加上是否有库存的过滤条件,以免用户在维护时检索出太多过期的数据。如果加上库存过滤条件,标记为自备药的药品需要能够始终检索出来。
  • 单次剂量、用法、频次、天数、费用、备注、父医嘱:维护所选药品的相应使用方法数据,以便开立时能够快速带入。

1.3 处方复制

在维护常用处方的过程中,经常会遇到调整常用处方使用范围的情况。比如原本用户自己的个人常用处方想要共享给科室所有用户。

这时,系统就需要支持修改或者添加多个适用范围的功能。

在目前许多系统设计中,一般都是支持常用处方直接复制到其他使用范围。例如将原本的个人常用处方直接复制一份到科室或者全院处方中。这样系统的逻辑相对简单,也能满足各种使用场景的需要。

2. 常用处方开立

在处方开立界面,常用处方功能一般在右侧边栏。

有些系统将个人、科室、全院三个范围的常用处方设计为三个页签,用户点击相应的页签进行查看。我比较倾向的是在常用处方列表可以直接查看到所有可以使用的常用处方。这样可以充分利用默认页面列表的展示空间。列表内容以“个人>科室>全院”的顺序进行排列。用户可以通过快速地过滤条件过滤查看的常用处方的范围。

用户可以通过双击常用处方的名称将所选常用处方直接开立给当前所选患者。当然,也可以在引用之后再根据需要调整处方的内容。在此界面,我也比较推荐在鼠标悬停在处方名称上的时候,通过气泡的形式展示处方维护的药品详情。这样用户就在不打开新窗口的情况下查看维护的常用处方的明细。

在处方开立界面,一般也都会有将正在录入的处方内容快速存为常用处方的快捷操作入口。医生在正常开药的过程中,将认为比较常用的处方直接存为常用,其实是最为合理的使用路径。

二、常用药品维护与开立

常用药品是支持用户将经常使用的药品单个存为常用。在处方开立时,直接点击常用药品完成引用,从而快速完成处方开立。

1. 常用药品维护

常用药品维护的逻辑比较简单,只要选择对应药品,预先设立好相应的开立方法。与常用处方不同的是,常用药品只需要维护个人的就行,科室或者全院常用药品没有太多用处。

常用药品维护的字段也都是常规的药品名称及规格、单次剂量、用法、频次、天数、费用、备注就可以 。

2. 常用药品开立

一般来说,常用药品会处方开立页面的中上或者中下方。将维护好且启用的常用药品名称及规格展示出来,鼠标悬停在药品名称及规格上,弹出气泡框显示详细的使用详情。

双击索要开立的常用药品,则会自动添加到所选患者的处方开立界面中。系统操作尽量与处方开立的操作保持统一,保持交互上的一致性。

当然,处方开立界面已保存的药品,也需要有快捷地存为常用药品的入口。可以添加操作按钮或者添加右键菜单,支持用户完成此操作。

三、历史处方查看及引用

很多患者看门诊都是为了续开之前的药品,特别是对于慢病需要长期药物治疗的患者。因此,在系统中如何快速的找到患者之前开立的处方并引用到本次,也就成了门诊处方开立必不可少的功能。

在门诊医生工作站中,一般都会在处方开立页面提供供医生查阅和引用所选患者之前历次就诊的药品处方的功能。历史处方的使用场景比较明确,在界面上默认展示处方的开立日期和科室信息,从而尽量多展示历史处方数量。可以在鼠标悬浮的气泡中展示就诊日期、就诊科室、诊断和药品明细等信息,方便医生快速选择到所需要的处方。

医生可以选择需要的处方将药品及用法用量等信息一键带入本次就诊中。设计比较灵活的系统,会在统一查询患者所有历史就诊记录的功能也提供快捷引用的操作入口。

四、药品常用方法维护及使用

药品常用方法不难理解就是为药品维护常用的使用方法,在处方开立时就自动带入,用户只要按需修改使用方法后就可以直接保存。有了这个功能,用户就不需要每个药品都是重复地录入单次剂量、用法、频次等信息。

如果确实有需要,还可以对同一个药品维护针对不同情况的常用方法,在选择药品之后再进行选择带入就可以了。

药品常用方法的功能,也需要支持个人、科室和全院三个不同使用范围的设置。在处方开立的界面,也要支持通过操作按钮或者右键菜单选项,直接将已开立的药品的使用方法存为常用的快捷操作入口。

印象很深的是在上线一家大型三甲医院系统时,前期的调研规划和后期的培训都漏掉了这个功能。但是在上线的第一天,几乎所有的门诊医生都吐槽系统不好用。调研了几位医生之后我们发现主要是因为少了药品常用方法这个功能,每个药品都要多花两三秒的录入时间。

比如10ml一支装的藿香正气水,常规的用法就是每次一支、口服、每日两次。如果有维护常用方法,医生选择好药品之后可以直接保存。而没有的话就只能依次选择和录入单次剂量、用法、频次。这样的操作浪费时间且没有意义。于是我们连夜开发上线了这个功能,同时将医院原有系统的常用药品方法数据整理导入到了我们的系统中。

单单一个处方开立,就有常用的处方、常用药品和常用方法等辅助功能。可见为了医生们能够提升看诊效率,产品经理们也是想尽了一切的办法。门诊处方开立仅仅是庞大的医院信息系统中的冰山一角。在整理上面内容的时候也经常想是不是要先讲一讲登录地点、科室、字典这些基础架构的内容,理解起来会容易一些。好的一面是,可能一段时间内都不会缺少题材了。

专栏作家

吴之猫,微信公众号:有不知,人人都是产品经理专栏作家。健康管理小硕,医疗健康产品汪+文艺猫。

本文由 @吴之猫 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。