Consistency between SDK and FHIR APIs

[nara-falconeer]

There are lots of things that are available in SDK that aren't available in FHIR, and vice versa. This makes development chaotic, where both are getting intermingled. We came across another example today - Note field of a Condition is only available through API and not through the SDK. Canvas dev team has to take consistency seriously. As developers, the code is really clunky, switching from one to the other constantly.

[aduane]

Hi there, thanks for the feedback! Our FHIR API was developed before our SDK, and at one point was the only option for developers to build integrations with Canvas. When we began working on our SDK, we targeted completely new use-cases which were not possible with just the FHIR API. As we continue to build depth in the SDK capabilities, we're closing some of the gaps between what's possible in the FHIR API vs the SDK, but not as a goal in and of itself. We view the FHIR API and the SDK as complementary.

Right now we are focused primarily on enhancing the SDK, but as a signal of where we're headed in the future for FHIR, we plan to move the FHIR API into a set of plugins developed with the SDK. This will guarantee a few things:

1. Our FHIR API will be extensible, allowing Canvas or developers using the Canvas SDK to develop plugins to support additional resources and interactions.
2. The FHIR API will not have any capabilities not present in the SDK, since it will be built with the SDK.

So you are correct to observe the divergence in capabilities, and we are putting our full efforts into ensuring the SDK is capable enough to handle all development needs, including powering the future of Canvas' FHIR API.

[aduane]

Also, thanks for flagging the notes field being inaccessible from the condition data model in the SDK. I've opened a PR here to close that gap: #1694