Baseline Canadian FHIR Profiles - Entities Stream Calls

I agree. I think this would be a good topic for discussion on our Governance call.

If it's mustSupport=false, that's less problematic. However, we still need to be cautious. We don't want the baseline to become a 'union' of all of the data elements that are required by a couple of projects across the country. We should still be constraining to those things that are widely implemented. Otherwise the profiles will be complex and overwhelming, even if most of the elements are 'optional'.

Hi Lloyd, my understanding is that some jurisdictions/projects implement the ethnicity, so the goal is to help them communicate ethnicity using FHIR in a consistent way.

I think it would be helpful, if the Canadian baseline profile defines an optional extension that can be used by anyone who has a use case to communicate ethnicity and if we are able to agree on a set of code and bind this extension to a "preferred" value set.

Thanks Lloyd. I understand your point. All I am saying is that, since there is already a recommendation to use a value set published in Terminology Gateway, that the points I raised be considered to further enhance the recommendation.

Hi Finnie,

The question wasn't whether or not there are good reasons for collection. The question is whether existing systems *do* collect the data. (And if so, whether they collect it in a standardized way.)

If most/all EMRs already collect this data in a consistent way, then it's fine for us to put it in the standard. (And the appropriate value set to use would obviously be the one that's already in use.)

However, if they *don't*, then the *baseline* specification shouldn't impose that additional requirement. The baseline standard is expected to act as a lowest common denominator. The only additional requirements it should impose on implementers are the ones that FHIR demands (e.g. what codes are used for gender or certain vital signs) and the need to meet minimal useful interoperability requirements (e.g. you need to support Observation.code and value).

Additional implementation guides can then build on the baseline to propose new capabilities - which vendors can choose to implement or not based on the demands of the market and the business case presented.

The baseline profiles aren't intended to drive changes to implementer behavior beyond defining a very basic FHIR interface. Subsequent changes become easier once that foundation is in place. If we try to drive a bunch of change with the baseline, then implementers will push back on or slow-walk the implementation of the baseline, and we'll have nothing.

Thanks for bringing this up.