FHIR compliance

[akurungadam]

• Restful FHIR
• Exchange format - JSON
• Security
  • OAuth2
• FHIR Versions
• FHIR Profiles
• Doctype changes to accommodate resource mapping

[sidharthramesh]

There are libraries that take care of the serialisation and deserialisation to FHIR. So you can do the mapping just for json, but you’ll get support for XML as well.
Eg: https://github.com/nazrulworld/fhir.resources

Currently R4 is the most popular version of FHIR and is mandated by multiple government programs worldwide.

[akurungadam]

thanks @sidharthramesh, will check this out. btw, our models will mostly be able to support element to element mapping and I feel transforming document json to resource definitions should do it. reworking on some of the existing doctypes to make this possible.

and yes, R4 is what we are currently looking at. we’ll also have to bring in the necessary configurability to deal with other versions + support for profiles.

I feel we’ll be able to get the first cut ready in a few days, will update here

[sidharthramesh]

Hey @akurungadam and @ChillarAnand

I'd like to propose something I've been thinking for a while.

FHIR APIs are usually implemented in the context of a particular use case. This varies from country to country and the format of the FHIR resources also differs. For example, in the US you're expected to implement a REST API with the US Core Profile, while in India it's Document exchange using the NRCeS NDHM Profiles.

These are meant for a particular national use case and the formats and API calls reflect those use cases.

And so far, there has been no "ERP" FHIR profile. This makes a lot of sense in the context of how an ERP can integrate with a larger ecosystem of health care applications. We have already built a FHIR Facade on top of Odoo, and it supports a lot of our applications. I'd like to see if we can come up with a "Common ERP" FHIR profile that we can both agree on.

Something that'll at least cover:

• Encounters
• Patients
• Inventory Items

[akurungadam]

Hi @sidharthramesh
Interesting, we are also working on a design to support multiple FHIR profiles within Frappe Healthcare. We would surely like to understand more about the facade you have in place and are open for collaboration.

[pythonpen]

Why is it required to build our apps / ERP to be FHIR native? Better to keep FHIR adaptor service outside the app where it can be adapted for various s interop purposes. The FHIR adaptor service can support reverse transformation too ie, from FHIR format to our app native data model.

This way lot of benefit as described in this article - https://medium.com/lifen-engineering/should-you-use-fhir-in-your-frontend-apps-283b128863d1