我应该使用 HL7 RIM 还是推出自己的数据模型？
我的团队被指派为客户构建一个电子医疗平台，在设计过程中我们遇到了这样的困境：
我们对数据模型有两种选择，HL7 RIM（参考信息模型）和另一个尚未设计的模型。
尽管 RIM 已被广泛记录并且看起来非常完整，但鉴于其复杂性和明显的缓慢性，我不确定它是否是最佳选择。
我想设计一个更简单的模型，只考虑客户的要求，旨在更容易理解，也许更快。
你怎么认为？ 我应该遵循 HL7-RIM 吗？ 或者我应该为客户的要求想出一个更简单的模型？
无论如何，信息交换的需要需要实现 HL7 消息传递协议，因此我们必须独立于底层模型来开发该部分。
My team has been assigned to build a e-health platform for a customer, and in the design process we have arrived at this dilemma:
We have two options for the data model, the HL7 RIM (reference information model) and another one that is yet to be designed.
Although the RIM has been documented extensively and seems very complete, I'm not sure if it is the best choice, given its complexity and apparent slowness.
I would like to design a more simple model which would take into account only the customer's requirements, aiming to be more easy to understand and maybe faster.
What do you think? Should I follow the HL7-RIM? Or should I think up a simpler model for the requirements of my customer?
In any case, the need for interchange of information would require an implementation of the HL7 messaging protocol, so we must develop that part independently of the underlying model.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
答案是使用您自己的模型，特定于客户要求，但功能要求始终能够与 HL7 互换。 在整个开发过程中测试该要求。
The answer is to use your own model, specific to customer requirements, but with a functional requirement to always be able to interchange with HL7. Test that requirement throughout your development process.
您在医疗保健数据方面需要的灵活性越大（您的应用程序越是“存储库或数据仓库”），就越有理由实施 HL7 RIM。 搜索“RIMBAA”（基于 RIM 的应用程序架构）以获取有关此方法的更多信息。
您的应用程序越倾向于支持一组特定的定义良好的工作流程，就越有理由使用针对该特定工作流程优化的数据模型。 我同意 John Saunders 的观点：确保您的“优化数据模型”可以映射到 RIM。 这应该有助于“面向未来”您的应用程序，并使其更容易支持 HL7 接口。
The more flexibility you require in terms of healthcare data (the more of a "repository or data warehouse" your application is), the more the reason to implement the HL7 RIM. Search for "RIMBAA" (RIM Based Application Architecture) for additional information on this approach.
The more your application is oriented to support one particular set of well-defined workflows, the more reason to use a data model that's optimzed for that particular workflow. I agree with John Saunders: make sure your 'optimized data model' can be mapped to the RIM. That should help to 'future proof' your application and to make it easier to support HL7 interfaces.
我会推荐 HL7，但是您应该对其使用有策略。 我假设您的组织已经拥有一整套软件系统。 如果是这种情况，那么在关键服务上公开“HL7 接口”可能是个好主意，但以特定于您的组织的某种规范形式进行内部对话。
HL7 的伟大之处在于它本质上是基于消息的，因此您可以使用 Business Processor Manager (BPM) 软件做各种很酷的事情，您只需让业务人员绘制漂亮的图表来说明如何管理 HL7 消息流。
我可能建议的一件事是对各种“适配器”进行调查，例如“iWay HL7 智能适配器”或 IBM 的 WTX。 这些可以让您专注于需要编写的业务代码，而不必担心传输层的 HL7 消息传递等...
希望有所帮助。
I would recommend HL7 however you should be strategic about its use. I'm assuming you have a whole suite of software systems at your organization already. If that is the case, it's probably a good idea to have "HL7 interfaces" exposed on key services, but have the internal dialog in some canonical form specific to your organization.
The great thing about HL7 is it's inherently message based, so you can do all sort of cool things with Business Proccessor Manager (BPM) software where you are just letting your business people draw nice charts of how the flow of an HL7 message is governed.
One thing I might suggest is doing an investigation of the various "adapters" out there, for instance "iWay Intelligent Adapter for HL7", or IBM's WTX. These let you concentrate on the business code you'll need to write, instead of having to worry about HL7 messaging at the transport layer, etc...
Hope that helps.