FHIR Chat · Extension Naming Convention harmonization · implementers

Stream: implementers

Topic: Extension Naming Convention harmonization


view this post on Zulip Ken Sinn (Mar 08 2019 at 18:59):

Hi everyone,
In light of Firely's publication of their Profiling Best Practices (https://simplifier.net/guide/profilingacademy/Best-practices), we noticed that their naming convention for extensions ("lowercase for extensions, using the following format: [context]-[name], e.g. patient-age") is mostly consistent with the approach taken by FHIR, as demonstrated on https://www.hl7.org/fhir/extensibility-registry.html. (although FHIR generally takes the approach of [lowercase]-[lowerCamel] for [resourcetype]-[name]

There are a few inconsistencies, for example:
- DiagnosticReport-geneticsAnalysis (UpperCamel-lowerCamel)
- allergyintolerance-reasonRefuted (lowercase-lowerCamel)
- family-member-history-genetics-observation (lowercase-with-dashes)

I know this was last discussed in the context of a different topic over two years ago (https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Searching.20on.20extentions).
Does FHIR have any plans to formalize the naming convention? Are there any plans to harmonize the names used for the current set of published extensions on https://www.hl7.org/fhir/extensibility-registry.html? Even if not formalized, would FHIR consider publishing a set of guidelines as well, to steer implementers/profilers in a common direction? Obviously harmonizing would significantly impact existing implementations, but as least with a formal convention, we would experience less divergence going forward.

view this post on Zulip Eric Haas (Mar 08 2019 at 20:07):

To be precise there is a structuredefinituon id,a computer friendly name, and title , and a url.

view this post on Zulip Lloyd McKenzie (Mar 08 2019 at 22:51):

I'm not thrilled with the guidance here about closed profiles. Constraining maxOccurs to 0 says it's an error if that occurs and that should be exceptionally rare. in almost all cases it's appropriate (and preferable) to just ignore elements that aren't supported. It makes system evolution easier and allows systems to write one interface to talk to multiple APIs - which should always be our objective.
@Michel Rutten

view this post on Zulip Grahame Grieve (Mar 13 2019 at 07:00):

I don't recall where we got with naming consistency on this and whether to change existing extnesions


Last updated: Apr 12 2022 at 19:14 UTC