Map a non-standard JSON data from a REST API into FHIR

Question

I'm currently building a REST API 'bridge' that has no database attached and I wanted to convert a JSON response from another API, convert it to FHIR, and then pass it to the client that requests it.

Because of the detailed implementation requirements of FHIR itself, I was thinking to use node-fhir-server-core to do this. Where to implement the non-FHIR-to-FHIR mapping functions? Is it possible to use node-fhir-server-core? If it's not, how to implement FHIR validation/support using plain express application?

Answer 1

Short Version:

You need to figure out if "https://github.com/Asymmetrik/node-fhir-server-core" supports what

Hapi Fhir Server calls "plain server" :: https://hapifhir.io/hapi-fhir/docs/server_plain/introduction.html

and Vonk calls "facade" :: https://fire.ly/products/vonk/vonk-fhir-facade/

In their diagram (below...towards the bottom right) I see "Resource Providers", but I am not sure if that is "your custom resource provider" or "our (asymmetrik's) built in resource provider".

I looked through some of their documentation and I do not see anything about "how to implement your own custom resource provider". (I started here and did ~some digging). https://github.com/Asymmetrik/node-fhir-server-core/blob/master/docs/GettingStarted.md

But hopefully, these breadcrumbs to what others call this kind of setup.. will assist your search.

If you find something concrete, then please report back, I am curious myself.

But with hapi or vonk, you would have a fhir server setup, it would receive the requests (usually GET), translate the request to your (other) internal REST server...get back the data, convert it to a fhir (usually r4 at this point in time) resource........and that would get sent to the end client. In a nutshell, the "adapter" design pattern.

Longer Version:

If you "collect" the data into your proprietary database, that is fine. You will then setup a fhir server to expose that data. Hapi Fhir "plain server" or Vonk (paid product) facade pattern would be the paths to expose that data to the outside world. You will take your proprietary and convert it into fhir objects and expose.

Option 2. Since you have new code, you can try to store you data AS FHIR OBJECTS into your datastore (db or nosql). And then you expose those objects to the outside world.

FHIR is.......a common well known object model. The "language" of healthcare chat.

My personal metaphor is that.. "its like everyone starts talking english with each other, BUT its more of someone talking american english with someone talking british english". What I mean is...its not always perfect. There are fringe cases where the chit-chat is not perfect. But it is close. And much better than having to have a translator for everything.

If you read this article (below) about a "plain server" (a plain fhir server) (this is about converting your EXISTING proprietary data into fhir resources)

https://hapifhir.io/hapi-fhir/docs/server_plain/introduction.html

vs (what hapi calls "jpa", but in general is an "all in" fhir server

https://hapifhir.io/hapi-fhir/docs/server_jpa/introduction.html

......

You'll start to see the different choices for setting up a fhir server.

If you have a blank datastore (database, nosql, etc), there are a few options for setting up a fhir server.

Hapi Fhir + JPA backed datastore.

MS Fhir Server (open source) using CosmoDB or Sql Server.

(Paid product) Vonk "full in" server.

"Spark" is an older (but open source) fhir server.

........

However, most people are not able to start with a blank slate datastore.

Then you have a few options.

Hapi Fhir where you write implementations for an IResourceProvider (where you would write a PatientResourceProvider, (any/most other Fhir resources) .. etc, etc.

Vonk (a paid product) has the same concept that they call Facade Pattern.

.......

Right now, I do not know of hybrids. You have to pick one or the other (blank-slate datastore OR the adapter/iresourceprovider/facade pattern.

........

Ok, that is if you want to create a fhir server.

........

You may just want to use someone else's fhir server. Then you want to look at "fhir clients" to work with someone elses fhir server.

hapi has a fhir client

https://hapifhir.io/hapi-fhir/docs/client/introduction.html

there are probably others.

.........

Now, to your specific choices.

You probably do NOT want to maintain the object model. You want to reuse the work of others who have created object models.

https://www.nuget.org/packages/Hl7.Fhir.R4/2.0.0-beta1

Firely (company behind Vonk) provides a dotnet object library as open source. hapi has a java object library.

you should choose a language that can use these reusable object libraries. if python has one, then i guess you can use python. personally, I would not. i would stay with dotnet-core (which is open source) or java. there may be a python fhir object model library, but if there is not....i would not pick python. Its way too hard to mimic all that library stuff.
.........

Here is some in general documentation start points.

https://hapifhir.io/hapi-fhir/docs/model/working_with_resources.html

(take the below info in the links...with a grain of salt, some of the info is out dated)

https://wiki.hl7.org/Open_Source_FHIR_implementations

https://wiki.hl7.org/Publicly_Available_FHIR_Servers_for_testing

https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources

.......

Personal thoughts.

I would pick dotnet-core or java for fhir projects. Again, find the language(s) that are more mature in fhir (right now, not hopeful future stuff).

Stuff not everybody talks about:

When you expose data that is patient specific (aka, in a non aggregate manner), you have to think about the patient-matching problem. You cannot just say "here are observations". You have to be able to a say "here are the observations for Patient ''John Smith'', and I am 99.9999% sure that I am giving you data for (the CORRECT) John Smith. Do not underestimate this issue.