FHIR互操作性平台选择 [英] FHIR interoperability platform choice

问题描述

我想创建一个具有复杂业务逻辑的互操作性平台FHIR.

I want to create an interoperability platform FHIR compliance with a complex business logic.

我们的客户可以将FHIR资源发送到平台.

Our clients can send FHIR resources to platform.

最佳实践文档中最好的体系结构是ibrid系统FHIR + SOA，因为此链接说.

The best architecture by best practise documentation is an ibrid system FHIR + SOA, as this link says.

现在，我写了两个我必须管理的方案示例:

Now I write two examples of scenario I must to manage:

第一个:

我想创建一个ServiceRequest资源，其中的主题我只知道财务代码作为标识符.如果需要有关该主题的其他信息，则可以查询外部数据库，例如，以了解姓名，姓氏和其他信息.

I want to create a ServiceRequest resource with a subject where I know only the fiscal code as identifier. If I need other informations about the subject I can query an external database, for example, to know name, surname and others.

我可以这样做，仅向我的互操作性平台发送以下服务请求吗?

I can do this, send to my interoperability platform only a Service Request as follow?

"resourceType" : "ServiceRequest",
"subject" : {
     "reference" : "Patient?identifier=FISCALCODE"
 }

以此类推

第二个:

我想创建一个带有Requester标记中链接的RelatedPerson的ServiceRequest资源.

I want to create a ServiceRequest resource with a RelatedPerson linked in the requester tag.

RelatedPerson不是一个完整的注册表，我只知道姓名和姓氏以及指向患者的链接.

The RelatedPerson is not a fully registry, I know only name and surname and a link to patient.

我必须创建一个SOA方法createServiceRequest，必须在其中传递两个参数ServiceRequest和RelatedPerson?或者我可以对捆绑资源使用CRUD方法，将ServiceRequest和RelatedPerson作为条目放置在其中?

I must create a SOA method createServiceRequest where I must to pass two parameters the ServiceRequest and RelatedPerson? Or I can use a CRUD method for Bundle resource where I put as entries my ServiceRequest and my RelatedPerson?

因此，如果我尝试总结一下，可能的方法是:

So if I try to summarize, the possible ways are:

1. 创建方法createMyMethodName(ServiceRequest serviceRequest，RelatedPerson relatedPerson)

1. Create a method createMyMethodName(ServiceRequest serviceRequest, RelatedPerson relatedPerson)

• 这种方法的创建和公开是FHIR标准吗?
• 如果第一个问点的答案是是"，那么在我的平台上，我将有很多自定义方法，但是对输入信息的控制非常严格

使用CRUD Bundle方法，将以下条目传递到Bundle资源中:ServiceRequest，RelatedPerson

Use a CRUD Bundle method where I pass into the Bundle resource the following entries: ServiceRequest, RelatedPerson

• 通过这种方式，我只公开了一种在平台上进行写操作的方法，但是我必须实现大量代码，以管理具有多个不同条目的所有输入包(我想是一个大型交换机，然后针对每个分支应用业务逻辑控件来完成我的业务逻辑规则)

推荐答案

此回答并非旨在完整回答您的问题，它来自美国.但是，您可能会发现透视图很有用.

This response is not intended as a complete response to your question and comes from a US perspective; however, you may find the perspective useful.

带有标识符查询的Gotcha

"reference" : "Patient?identifier=FISCALCODE"

按照书面规定，您的?identifier=FISCALCODE将针对所有代码系统查询FISCALCODE键.我认为您想要的是指定一个代码系统，例如?identifier=<CodeSystem>|<FiscalCode> 这是 FHIR搜索文档中埋藏的常见陷阱.

As written, your ?identifier=FISCALCODE will query the FISCALCODE key against all code systems. I think what you want is to specify a code system, e.g. ?identifier=<CodeSystem>|<FiscalCode> This is a common gotcha that's buried in the FHIR search documentation.

您要么必须引用现有的代码系统，例如意大利特定的实施指南，类似于US Core，其中包含FiscalCodes列表，或者您自己编写.

You'll either have to reference an existing code system, e.g. an Italy specific implementation guide analogous to US Core that contains the list of FiscalCodes, or author your own.

您使用的是哪种FHIR集成范例?

在深入探讨createMethod vs Bundle问题之前，我认为退后一步并选择一种整体的FHIR集成方法会很有用.

Before diving into the createMethod vs Bundle question, I think it'd be useful to step back and pick an overall FHIR integration approach.

我认为，主要有以下三种方法:

In my opinion, there are three major approaches:

• 将数据加载到现有的独立FHIR服务器中
  • 挑战:FHIR服务器中加载的数据与其他数据仓库之间的漂移
  • Load data into an existing stand-alone FHIR server
    • Challenge: Drift between data loaded in FHIR server and other data warehouses
    • 挑战:FHIR API和非FHIR API之间的重复
    • NB:在有限的情况下，FHIR服务器中没有适当的数据存储.更加令人困惑的是，一些人将这种实现称为"FHIR网关".而不是"FHIR服务器".
    • 挑战:必须为每个FHIR资源和每个数据元素编写数据访问权限.

    将来，可能会有第四种方法，其中一种方法是从中间源模型到多个目标实时使用FHIR映射语言.

    In the future, there may be a fourth approach where one uses the FHIR mapping language in real-time from an intermediate source model to multiple targets.

    您的"CRUD捆绑方法"与将数据发布到独立FHIR服务器更加一致，而您的"createMyMethodName"更加符合将DAO(数据访问对象)写入外部数据库的要求.

    Your "CRUD Bundle method" is more in-line with POSTing data to a stand-alone FHIR server, whereas your "createMyMethodName" is more in-line with writing DAOs (Data Access Objects) to an external database.

    在不需要维持FHIR服务器与源数据系统之间同步的极限情况下，将数据导入到独立的FHIR服务器中的工作要少得多.

    In the limit where you don't need to maintain synchrony between the FHIR server and source data systems, importing data into a stand-alone FHIR server is much less work.

    在您已经具有到中间数据模型的映射的限制(在美国，许多大型服务提供商将具有到USCDI或Common Clinical Dataset的映射)，您将可以轻松地在数据库中编写CRUD.针对现有数据库的FHIR服务器.

    In the limit where you already have mappings to an intermediate data model (in the US, many large service providers will have mappings to either the USCDI or the Common Clinical Dataset), you'll have an easier lift writing CRUD in the FHIR server against an existing database.

    对于更深入的讨论，在FHIR Dev Days 2018上进行了FHIR集成模式演讲，

    For a more in-depth discussion, there was a FHIR integration patterns talk at FHIR Dev Days 2018, starting at Slide 21. Note that the author assumes a familiarity with architectural patterns such as the facade pattern.

    选择独立服务器或库

    除非您有令人信服的要求或是一家大公司，否则建议使用现有的开源独立服务器或库实现.最受欢迎的三个是:

    Unless you have a compelling requirement or are a large company, it's advisable to use an existing open-source stand-alone server or library implementation. The three most popular are:

    • HAPI-FHIR(Java)
    • Microsoft(.NET)
    • IBM(Java)

    如果采用独立选项，则流行的商用FHIR服务器

    If taking the stand-alone option, popular commercial FHIR servers

    • Microsoft(托管在Azure中)
    • Smile CDR(HAPI-FHIR的商业版本)
    • Firely Vonk

    这篇关于FHIR互操作性平台选择的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！