FHIR interoperability platform choice - interop

Question

I want to create an interoperability platform FHIR compliance with a complex business logic.
Our clients can send FHIR resources to platform.
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:
The first:
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"
}
and so on
The second:
I want to create a ServiceRequest resource with a RelatedPerson linked in the requester tag.
The RelatedPerson is not a fully registry, I know only name and surname and a link to patient.
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:
Create a method createMyMethodName(ServiceRequest serviceRequest, RelatedPerson relatedPerson)
Creation and exposure of this method is it FHIR standard?
If the answer of first quesiton point is YES, in my platform I'll have a lot of custom methods but I have a very strict control on the input informations
Use a CRUD Bundle method where I pass into the Bundle resource the following entries: ServiceRequest, RelatedPerson
In this way I expose only one method to write on my platform, but I must to implement a lot of code to manage all input bundles with several different entries (I suppose a mega switch and then for each branch I apply the business logic controls to accomplish my business logic rules)

Answer 1

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 with identifier queries
"reference" : "Patient?identifier=FISCALCODE"
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.
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.
Which FHIR integration paradigm are you using?
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:
Load data into an existing stand-alone FHIR server
Challenge: Drift between data loaded in FHIR server and other data warehouses
FHIR server queries non-FHIR API
Challenge: Duplication between FHIR API and non-FHIR API
NB: In the limiting case, there is no data stored in the FHIR server proper. Adding to the confusion, some will call this implementation a "FHIR gateway" instead of a "FHIR server."
FHIR server queries staging database for FHIR data
Challenge: Must write data access for each FHIR resource and each data element.
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.
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.
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.
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.
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.
Select a stand-alone server or library
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)
If taking the stand-alone option, popular commercial FHIR servers
Microsoft (hosted in Azure)
Smile CDR (commercial version of HAPI-FHIR)
Firely Vonk