Difference between plain server and JPA in HAPI FHIR?

Question

I am actually working on a FHIR project and i want to know what is the difference between plain server and jpa server ?

Answer 1

Plain Server is "you have a bunch of data in your company......and is NOT fhir'ized" and you want to put a facade ("plain server") on top of that data. Vonk/Firely calls this approach "facade", but it is the same concept.

My generic example.

You have a bunch of Employee(s) in an Employee table in a custom database in your company.

Employee with properties LastName MiddleName FirstName

You need to "convert" the Employee to an (HL7 FHIR..probably R4 as the FHIR version..."Patient") resource.

You have to map "your" properties to the hl7(prob r4) Patient domain object. Like this:

emp.LastName -> Patient.Family

emp.MiddleName and emp.FirstName to Patient.Given(Names).

..

Then you "ship out" (honor the http-request with) the converted (R4) Patient..... to the calling user or app.

But wait... if it were only that simple... there is "paging" the FHIR-Resources ... so if you get a request

me.my-fhir-server.com/r4/Patient?family=Smith

and you have 200,000 (LastName=) Smith's in your Employee database/table.....you need to page them out. 100 at a time? 10 at a time? You have that choice as to the page-size. But you're probably not gonna send out 200,000 R4-Patients.

So "being a FHIR Server".. for a FHIR-Resource .. It is solvable, but it is not trivial.

......

......

......

With "full approach", you have a data-store that stores data AS FHIR RESOURCES. You have to write "import data" projects/jobs to put your Employee(s) into the FHIR-Server.. AS (R4) Patients, THROUGH THE FHIR-API (Aka, the FHIR Rest Layer).

This is not trivial. A (collection of many) patient(s) is easy enough. But that is only the start of the "foreign reference nightmare".

If you have AllergyIntolerance, the AllergyIntolerance will have a 'reference' to its (parent) Patient. And the reference has to be the fhir-logical-id of the Patient. And this patient-FHIR-logical-id will not be known to you until after the Patient exists in the FHIR-server.

Now rinse and repeat for Observations, Medications, etc, etc. There are a lot of referenced objects that relate to a Patient.

(Note, some products have "bulk import options", usually into an empty FHIR-friendly-data-store...but its more of a super one time (at the BEGINNING of the existence of the FHIR-data-store) thing, not a "update every week" type of situation).

....

Also note, that you need to consider the performance of a JPA data-store (when you are talking about using open source Hapi for example).

Can you do a proof of concept and put in 1000 Patients. Sure.

Can you put in 2,000,000 (2mil) or 3,000,000 (3 mil) patients and other FHIR resources? Well, uh.... go performance test that. (and the idea being..that that is a big jump to having a performant FHIR server backed by some kind of datastore with millions and millions of records in it)

So food for thought items there.

But the short answer is

Plain-Server is a facade. And you "convert the data to FHIR" "on the fly" with each request.

Full-In, you PERSIST your data into the fhir-data-store (jpa in your situation)..... and the framework consumes the data as it is .. in and out of the datastore.

..

Other tidbits.

Hapi Fhir is an open source java framework. It has alot of the plumbing for setting up the Fhir-Server.

SmileCDR is a paid product (subscription ?) .... that builds upon the Hapi Fhir ("free") open source.
But they would have a "real" database/nosql option that ALSO PERFORMS.

Microsoft Azure FHIR Server (or whatever name they're using now) does NOT have a facade pattern.
But they do have a well performing "full in" server. It is open source. You can either run it on-premise with Ms-Sql-Server OR you can run it in the cloud with Ms-Sql-Server or CosmoDB...or you can get is a Saas in azure cloud.

NO, it will NOT support another database besides Ms-Sql-Server. (While they've coded against interfaces, it is NOT coded to ORM). Microsoft is using EVERY Ms-Sql-Server SPECIFIC TRICK they have to get PERFORMANCE out of the Ms-Sql-Server implementation.
The queries executed against the FHIR-data-store are finely tuned for Ms-Sql-Server or Cosmo.

Other:

Vonk supports Facade or Full In. But they are paid subscription, even for facade pattern. (the last time I checked)

And finally, IMHO:::

You should NOT let language (java vs dotnet-core) bias drive your decision. You should let what is available drive your decision.

Answer 2

Basically, a plain server does not include a backend/specific database and schema; it's possible to set up with existing data structures as long as the structures can be mapped to FHIR Resources. An introduction to setting up a plain server is here, and more information directly from HAPI FHIR is here. They include a couple starter servers here.

A HAPI-FHIR JPA server includes a database, using "the JPA 2.0 API to store data in a database without depending on any specific database technology"; if you have existing data, you'd need to move it into that database. You can read more about the architecture here.

There are other JPA servers out there; Smile CDR is one, which is based on the HAPI FHIR JPA server; IBM has its own as well, also using JPA. This isn't unexpected as FHIR is an interoperability standard/spec; anyone can take the specs and build it on whatever platform/module they want as long as it conforms to the FHIR RESTful API spec.