在这种情况下使用Mirth Connect或任何其他界面引擎是否过度杀伤?

时间:2013-10-09 03:00:44

标签: web-services hl7 mirth

我被分配了一个小项目,并指示使用Mirth Connect作为解决方案的一部分。我们目前不使用Mirth,但因为我们有一个需要接口引擎的即将推出的项目,我被要求将它用于这个项目,所以我可以获得它的经验。但是,我认为这个项目的建议很差;我也知道我的老板不希望我实施一些只是为了学习而增加不必要复杂性的东西。

话虽如此,我想确保我有正当理由建议不要将Mirth Connect用于此项目。我们都不太了解它,但我认为他已经确信它是所有接口/ webservice相关的所有解决方案的最终解决方案。我感谢那些对我们产品有更多经验的人的任何意见。

这是一个非常简单的项目,因为我们有一个客户需要从那里向我们的系统发出一些请求,以便检索和更新数据。例如,他们将提出获取患者人口统计数据的请求,为患者添加入院许可,从我们的应用程序获取可能的护理设置列表的请求等。对于此项目,我们不会使用HL7而是一组预定义的XML消息。

客户端的应用程序和我们的应用程序都驻留在客户端的网络上。

他们不想构建自己的任何服务,因此我们构建的服务需要处理所有工作。响应对服务的调用而返回的结果将以XML格式返回。

在可预见的将来,没有计划将任何其他应用程序与他们或我们的应用程序集成。

在我看来,最好的选择是让我们构建一个独立的Web服务来接收他们的请求并发回XML响应。我只是没有看到任何理由在图片中包含Mirth Connect(除了学习,但可以通过其他方式获得)。

你有什么想法?如果客户端想要从我们的系统接收数据而没有接收机制,那么接口引擎不是一个好的选择吗?换句话说,他们希望进行Web服务调用,例如GetCareSettings,并使用我们系统中所有可能的护理设置的XML表示来获取响应。在我看来,他们需要一个Web服务,以便将Mirth用作发送结果的目的地。所有Mirth将要发回的是ACK消息,对吗? (当然,除非它将数据写入客户端的另一个Web服务,他们已经说过他们不想这样做。)

感谢您花时间阅读本文。我希望我对Mirth Connect的缺乏了解和理解以及界面引擎的使用并没有使这个问题难以回答。

1 个答案:

答案 0 :(得分:0)

据我所知,您的客户似乎是实验室或第三方服务供应商,他们将从您的应用程序中获取输入,如患者人口统计图表,约会,提供者详细信息等。基本上他想查询< / em>你的申请。

A) HL7:它有能力处理人口统计信息的查询请求和响应。我假设你已经完成了,你可能知道QRY消息。

B) XML/webservices/SOAP:仍然提供了一个可行的解决方案,更具体一点,可以扩展为处理自定义请求,如GetCallSettings,或者可以是任何其他。供应商不仅对获取患者相关数据感兴趣,而且还对HL7可能不够的其他输入感兴趣。

如果我们谈论方法,那么它是一个使用接口引擎的专业建议。它不仅限于使用欢乐连接,如果你愿意,你也可以使用鬣蜥。我想到的一个很好的理由是,引擎可以在故障排除,支持和维护活动中为您提供优势。

您的Web服务响应可以通过HTTP发送方连接器类型和RESTful webservices轻松处理。 该引擎还能够同时处理大量请求和响应,以防万一现在不需要,但我认为这将是后来的情况。您在频道中的来源将更改为Web服务侦听器。

另一个好方法是取消XML并使用JSON处理请求和响应,比XML更轻量级,以节省网络开销。我们正在做一些类似的工作,但我们正在通过JSON向网络服务发送请求。

总的来说,欢乐会让你的生活更轻松。

祝你好运!