有没有朋友做过病历结构化设计？

仙人掌

我在做住院管理系统的时候（为了自己写病史方便：）），感觉把现病史部分结构化有些麻烦，主要是把现病史分成若干部分，再对这些部分预设若干模板句式。本以为很简单，可做起来才知道很麻烦，仅组织这些术语就很头痛了。我现在只做了心内科的部分，还有许多。不知那位朋友做过这方面的工作，能否给点指点呢？

ironstone

曾经做过一点点研究，不过我发现用现在的方法来做结构化的病历，所存在的技术问题和非技术问题（如文档结构的拆分等）都非常麻烦，最后放弃了，我现在在构想一种新界面，但还不是很成熟。不知道你的开发思路是如何的？可以好好交流。

sbf2000

现在正在做，主要思路：对象导向；属性模板。采用HL7 CDA规范。
界面：主要把文档表示为“文档树”，每个树节点表示相应的文档对象。每个文档对象有多个制定好的属性模板，编辑时先套用模板再作必要修正。最后将文档树转化为可视化文档。

小城医生

技术不是问题关键是知识库的建立。

starsshow

呵呵，我到觉得知识库的建立恰恰是个技术问题。不过不单单是软件技术，还要有医学、模糊识别、汉语语言等大量技术和知识背景。

仙人掌

几位老兄所提到的确实也是我所遇到的问题。我所采用的界面大概和sbf2000所说的相近。另外在语言修正输入上，我利用智能狂拼或黑马神拼的强大汉语库及它们的文本学习技术，从我搜集来的大量病历文本中提取术语词或短语。这样可有效的提高医学术语输入的智能性，前提要用智能狂拼或黑马神拼，而且分发时要导入字库。（我本来是为自己用，没考虑太多。）

tianma

病历结构化可能造成大量的雷同病历，而丧失个性化描述。有了导向和模版后，人们未必再对这千篇一律但也没有大错的东西作进一步的修改，特别是在时间紧急和每天例行公事的情况下。
但这样的病历有多少实际价值呢？

starsshow

如果只是为了帮助快速输入病历，自己写一个方便的输入法也就够了。
结构化的病历数据，其目的是为了针对医院需求提供关于病历质量控制，医疗科研方面的统计、检索等方面的功能。
各位认为呢？

danelchen

从某种意义上来说，结构化的病历确实可以大大的减轻临床一线医师的大量的工作量，但是作为临床一线的前3年的医师，对他们通过大量的临床病历书写来提高临床思维能力的功效就要大打折扣了。所以对了结构化兵力的适用人群，或者说由此变革所带来的相应的应对措施都是用户，或者说我们应该为用户周全的进行评估和衡量。所谓三思而后行嘛。不知道大家有没有认同感。

danelchen

[这个贴子最后由danelchen在 2002/12/02 10:36pm 编辑]

再则，说到知识库的问题，我看着还不仅仅是一个技术的问题，如果可以把它总结为单纯的技术问题，那么它的进展也就不会这么缓慢了。包括在国外的同类产品中关于知识库的问题也还在争论不休。Starsshow所说的“结构化的病历数据，其目的是为了针对医院需求提供关于病历质量控制，医疗科研方面的统计、检索等方面的功能。”这些在我以前的帖子中就有提及，只是没有引起深入的讨论。sbf2000所说的“主要把文档表示为“文档树”，每个树节点表示相应的文档对象。每个文档对象有多个制定好的属性模板，编辑时先套用模板再作必要修正。最后将文档树转化为可视化文档。”中的文档树就涉及到知识库的问题。这里有些是需要讨论的，比如有多少文档对象，这些文档对象进行怎样的分类，是依从于什么样的标准，满足标准还是满足用户目前所提出来的需求等等这都不是我们在家里闭门造车就可以做出来。
我说的这些都不是我想象出来的，而是我在实际工作当中所遇到现实情况，就拿一部分的来说，比如“检查”的分类节点（这里我们不讨论“检查”的定义或者是它的正确性如何。）我以我的自身的医师的经验进行了整理和分类，在用户那里就遇到了分类要采用他们习惯的分类法的问题。而分类法不是说谁对谁错的问题，而是在某种情况下那种分类法更为适用的问题了。相信这样的问题大家一定也多多少少的遇到过。

仙人掌

“病历结构化可能造成大量的雷同病历，而丧失个性化描述。”我不太统一这个观点。病历可不是用来表现个性的，和法律文书一样是个很严谨东西。我设计这个程的目的也不是为了输入病历方便，而是为了后期的查访记录、病程记录、交班记录、出院记录以及病案首页等内容的相关数据录入的统一和方便。其实除了现病史之外的其他内容早有表格式样，结构化很方便，我想这部分没有个性化的必要吧。我的重点在现病史部分这十几行的几百个字，我将它按发病时间、症状、部委、程度等共分了二十多份，也是为了以后统计疾病性质方便。我的想法比较简单，各位的讨论让我受益匪浅，谢谢大家。

starsshow

呵呵，我看病历更象是八股文。
“仙人掌”的结构划分方法针对某一点上可以满足一定需求。但要做到通用会有些问题，因为很多词汇的属性并非单一的。
我觉得病历处理方面在功能至少要满足几点：
让医生可以很方便的输入；
能够保证后期的检索、统计等；
可通过外建的控制模型对病历质量进行检查；
不同系统间的数据/文档交换。

仙人掌

有这么多同道中人真是感觉到高兴，看到大家的见解知道有这么多人热衷于医疗信息化，我更加坚定从临床转移到信息管理工作上来了。不过现在的医院对信息工作人员还不是很重视。不知大家在自己医院感觉如何。对了，我的程序工作界面是模仿病历夹的，我个人认为这样很容易上手，我让几个同事看后他们虽然打字不快，有两个连word都不会用，但不用培训就知道怎么用。所以我想如果解决了输入问题，就不用担心医生会排斥这类系统了。

ironstone

我有个朋友开发的界面也是类似于病历夹的方式，这种方式一个好处就是沿袭了医院的使用习惯。但是否存在不足的地方？我也没有进行深入的研究，不知道有谁考虑过没有？
我现在所设计的界面，其实有些类似于ultraedit,但在具体界面的表现上可能会更接近于word，在操作方式上会结合xml编写器。我这样设计的一个原则是，操作者有一定的电脑基础，而且需要在合适的地方加入自己的xml标记，以便于以后进行深入的数据挖掘，因此除了系统采用的xml标记以外，允许操作者自己定义xml标记，也允许操作者直接类似于使用文字编写器一样编写。至于模板的设计和使用，会到类似于CDA的第三层次，交给医师去管理和决定。为什么舍弃在界面上的表格式录入，一个是我认为表格式在电脑操作上反而更加繁琐，第二是表格在信息表达上虽然有一定的格式化，但过于局限，约束了医师对内容的个性化表达，而且随着医学的不断发展，其变化可能会导致系统的升级和修改，这样的工作量是不能接受的。所以从最初的表格方式转向了编辑器方式，当然编辑设计的前提是医师的操作水平，但我想这在以后的发展中应该不是最主要的问题。因此在编辑器方式的设计中，核心思想是内容表达的自由化，和数据表现的个性化。

乖乖兔

ironstone 可否给出更详细点的资料?