Implementing Non FHIR resources in FHIR API

We have a FHIR server that implements 4 FHIR resources Patient / Appointment / Practitioner / Healthcare Service. Now we are getting more and more requests from the customers to expose Non FHIR resources through the API. E.g. Adverse
Event / Finance data / HR data etc. (please note we are still on DSTU2).

We can implement these Non FHIR resources as a Basic resources with the coding as the FHIR recommends. http://hl7.org/fhir/DSTU2/qicore/basic-adverseevent-example.json.html if we implement this as you may know every attribute will be an extension.

On the other hand we can expose them as non-FHIR resources, [truly most of these resources can be not health related resources] can someone shed some light on best way to handle this [expose as Non FHIR resources or do them as Basic resources].

Thanks

The primary downside of non-FHIR resources is that you can’t use FHIR infrastructure - the reference implementations, test servers, IGPublisher, Validator, etc. won’t work with them (though if you want to go through the work, you can create custom versions of them that will). Another alternative might be to support the “new” capabilities at a separate endpoint that might be able to take advantage of STU3 or even a snapshot of R4. (That would give you AdverseEvent and perhaps what you need of the financial information, though may not cover HR.)

As you’ve noted, the primary downside of using Basic is that everything’s an extension - which makes for large and rather ugly resources.

We’ve talked about adding the ability to support “custom” resources into the infrastructure but the community hasn’t generally been in favor - they see it as a fairly big leap onto the slipperly slope towards proprietary silo-based interfaces. And that, I suppose, is another argument in favor of Basic.

2 Likes

Thanks for the reply. Yeah separate end point on STU3 looks like a better alternative