EMR（电子病历）标准记录格式？
我和一些同事正在启动一个 EMR 项目（电子病历）。 我过去曾听到过关于标准记录格式的讨论，最近更是如此，以方便在适当的时候将记录 (HIPAA) 从一个设施转移到另一个设施。 有人看过这方面的资料吗？
A few associates and myself are starting an EMR project (Electronic Medical Records). I have heard talk in the past - and more so lately - about a standard record format - to facilitate the transferring of records when appropriate (HIPAA) from one facility to another. Has anyone seen any information on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
您可以利用 HL7 来实现系统之间的互操作性 (http://www.hl7.org/)。 可以传递患者人口统计信息和文本注释。 我离开 EMR 领域太久了，不知道是否有任何标准组织最近做了一些有趣的事情。 保持语义的标准格式是一个非常非常困难的问题。 请参阅 SnoMed (http://www.nlm.nih.gov/research/ umls/Snomed/snomed_main.html）用于一项长期运行的本体论工作——这仅仅是丰富的交换格式的开始。
来自与新兴电子病历供应商合作了数年的人的警告……这是一项非常艰难的业务。大型医疗系统的销售周期实际上可能需要数年时间，而小型医疗系统则需要大量的人力支持。这种做法会迅速侵蚀利润。 与现有实践管理系统的集成是非标准的，即使这些供应商另有声明。 越来越多的问题层出不穷。 我不确定对于没有资金的初创企业来说，进入这个领域是否明智。
You can look to HL7 for interoperability between systems (http://www.hl7.org/). Patient demographic information and textual notes can be passed. I've been out of the EMR space too long to know if any standards groups have done anything interesting of late. A standard format that maintains semantic meaning is a really, really difficult problem. See SnoMed (http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html) for one long-running ontology effort -- barely the start of a rich interchange format.
A word of warning from someone who spent several years with an upstart EMR vendor...This is a very hard business to be in. Sales cycles for large health systems literally can take years, and the amount of hand-holding required for smaller medical practices can quickly erode margins. Integration with existing practice management systems is non-standard, even if those vendors claim otherwise. More and more issues abound. I'm not sure that it's a wise space for an unfunded start-up to enter.
我认为将 HL7 视为您所说的标准是错误的。 它是高度定制的，并且每个客户之间可能有很大不同。 这是具有太多灵活性的标准之一。
我建议您阅读该标准（这应该需要您一段时间），然后尝试找到使用该标准的开发人员社区。 向他们询问恐怖故事，并为您将听到的内容做好准备。
I think it's an error to consider HL7 to be a standard in the sense you seem to mean. It is heavily customized and can be quite different from one customer to the next. It's one of those standards with too much flexibility.
I recommend you read the standard (which should take you a while), then try to find a community of developers working with the standard. Ask them for horror stories, and be prepared for what you'll hear.
晚了一个月，但是……
拍摄的标准肯定是HL7。 它用于许多领域，因此高度可定制，但有一个明确定义的医疗保健标准。 无论您选择哪种系统，每条消息（ACK、DSR MCF）、段（PID、PV1、OBR、MSH 等）、序列和事件类型（A08、A12、A36）都具有特定含义。
我们在连接 MiSYS、Statlan、Oacis、Epic、MUSE、GE Centricity/Lastword 和其他在我们使用的系统之间发送 DICOM、ADT、PACS 信息时没有遇到任何问题。 这些系统中的大多数都将设置一个接口引擎，以便在需要时调整消息，因此必须添加一种方法来过滤 HL7 消息，因为它们进入您的系统，并且当它们发送到下游时。
即使会有一个新的互操作性“总统标准”，而且我会冒险猜测它无论如何都会是 HL7，我也会使用 HL7 消息传递构建系统，因为这是目前业界接受的标准。
A month late, but...
The standard to shoot for is definitely HL7. It is used in many fields, so is highly customizable but there is a well defined standard for healthcare. Each message (ACK, DSR MCF), segment (PID, PV1, OBR, MSH, etc), sequence and event type (A08, A12, A36) has a specific meaning regardless of your system of choice.
We haven't had a problem interfacing MiSYS, Statlan, Oacis, Epic, MUSE, GE Centricity/Lastword and others sending DICOM, ADT, PACS information between the systems we have in use. Most of these systems will be set up with an interface engine to tweak messages where needed, so adding a way to filter HL7 messages as they come through to your system, and as they go out to the downstreams, would be a must.
Even if there would be a new "presidential standard" for interoperability, and I would hazard a guess that it will be HL7 anyway, I would build the system with HL7 messaging as this is currently the industry accepted standard.
在解决互操作性时，您不应该只关心交换格式，本地存储格式也应该标准化，以简化与交换格式的转换，反之亦然。
openEHR 是一种很棒的存储格式，它比 HL7 v2、v3 和 CDA 更具表现力，因此可以轻松转换为其中任何一个。 规范是开放的，在这里： http://openehr.org/programs/specification/releases/ 1.0.2
对于交换格式，HL7 v2、v3 和 CDA 中的任何一个都可以。 还要考虑 CCR 和 CCD。
http://www.aafp.org/practice-management/health-it /astm.html
While solving interoperability, you shouldn't care only about the interchange format, the local storage formats should be standardized also, to simplify the transformation to the interchange format and vice versa.
openEHR is a great format for storage, it is more expressive than HL7 v2, v3 and CDA, so it can be transformed easily to any of those. The specs are open and here: http://openehr.org/programs/specification/releases/1.0.2
For the interchange format, any of HL7 v2, v3 and CDA are good. Also consider CCR and CCD.
http://www.aafp.org/practice-management/health-it/astm.html
如果您想跳出 HL7 思维，并正在寻找具有指定记录格式而不是记录提取消息交换格式的综合 EMR 或 EHR，那么请查看 openEHR，http://www.openehr.org/。 ISO 13606 提取标准（几乎）是 openEHR 的子集。 您还会发现 Java、.NET、Ruby、Python、Groovy 等中可用的开源参考库和不同成熟度的 openEHR 实现。
一些组织还生成 HL7 工件，例如 CDA，作为基于 openEHR 的 EHR/EMR 系统的输出。
If you want to go outside HL7 thinking and are looking for an comprehensive EMR or EHR with a specified record format rather than a record extract message interchange format, then have a look at openEHR, http://www.openehr.org/. The ISO 13606 extract standard is (almost) a subset of openEHR. You will also find open source reference libraries and openEHR implementations of different maturity available in Java, .NET, Ruby, Python, Groovy etc.
Some organisations are also producing HL7 artifacts like CDA as output from openEHR based EHR/EMR systems.
查看护理记录的连续性 - IIRC，这是 Google Health 用于输入的内容。 它不是 HL7 系列标准（有一个竞争的 HL7 系列标准 - 不记得它叫什么“off-top”）。
Have a look at the Continuity of Care Record--IIRC, that's what Google Health uses for input. It's not an HL7-family standard (there's a competing HL7-family standard--don't recall what it's called off-top).
在政府规定格式并要求依法使用之前，可能不会有标准的医疗记录格式。
如果没有社会化的国家医疗保健，这几乎肯定不会发生。 所以实际上零机会。
There likely will not be a standard medical record format until the government dictates the format of one and requires its use by force of law.
That almost assuredly will not happen without socialized national health care. So in reality zero chance.
它的正确答案，但我认为一些补充关于 emr 的有意义的使用......官员宣布“有意义的使用”，EHR 认证标准
据路透社报道，CMS 上周发布了拟议法规，定义了电子健康记录的“有意义的使用”（Wutkowski/Heavey，路透社，2009 年 12 月 31 日）。
此外，国家卫生信息技术协调员办公室发布了一项临时最终规则，描述了 EHR 技术所需的认证标准（Simmons，HealthLeaders Media，2009 年 12 月 31 日）。
根据 2009 年联邦经济刺激计划，证明有效使用经过认证的 EHR 的医疗保健提供者将有资格通过 Medicaid 和 Medicare 获得奖励付款。
两项法规于 1 月 13 日在《联邦公报》上发布后，官员们将提供为期 60 天的公众意见征询期。有关 EHR 认证的临时最终规则计划于发布后 30 天生效（Goedert，健康数据管理，12/30 /09）。 http://www.myemrstimulus.com/
its correct answer but i think some add about meaningful use of emr..... Officials Announce ‘Meaningful Use,’ EHR Certification Criteria
Last week, CMS released proposed regulations defining the “meaningful use” of electronic health records, Reuters reports (Wutkowski/Heavey, Reuters, 12/31/09).
In addition, the Office of the National Coordinator for Health IT released an interim final rule describing the required certification standards for EHR technology (Simmons, HealthLeaders Media, 12/31/09).
Under the 2009 federal economic stimulus package, health care providers who demonstrate meaningful use of certified EHRs will qualify for incentive payments through Medicaid and Medicare.
Officials will offer a 60-day public comment period after both regulations are published in the Federal Register on Jan. 13. The interim final rule on EHR certification is scheduled to take effect 30 days after publication (Goedert, Health Data Management, 12/30/09). http://www.myemrstimulus.com/
这是一个非常困难的问题，因为数据收集从 MD 开始，而他们知道的唯一编码（ICD 和 CPT）都是关于计费的，而不是提供商之间可能使用的任何内容（特别是可以保存 MD 的形式）承担法律责任）。 他们甚至讨厌那么多的文书工作。
除此之外，HIPAA 规定患者而非提供者拥有数据。 并不是说如果他们拥有它，他们就能理解它或用它做任何有用的事情。
祝你好运。 无论发生什么，都将是政府强制的结果，恕我直言，这将是很长一段时间的事情。
有趣的是，可靠的医疗信息的来源之一是退伍军人管理局（因为他们不存在付款和法律责任方面的对抗性问题。）想想吧。 不过，对于任何现有数据和一些动力的标准来说，这可能是一个很好的起点。 这是另一个包含一些信息的问题。
This is a very hard problem because data collection starts with an MD and the only coding they know (ICD and CPT) is all about billing, not anything likely to be of use between providers (esp. in a form where the MD can be held legally liable). And they hate even that much paperwork.
Add to that the fact that HIPAA dictates that the patient not the provider owns the data. Not that they could understand it or do anything useful with it if they had it.
Good luck. Whatever happens will result from coercion by the govt and be a long long time coming IMHO.
Interestingly the one source of solid medical info turns out to be the VA (because they don't have the adversarial issues of payment and legal liability.) Go figure. That might be a good place to start for a standard with any existing data and some momentum, though. Here's another question with some info.