Questions about BeCSPopulationScreeningNextInvitationType

[kridhaen]

• Is it possible to use CammelCase in the code type or is the current implementation preferred? CammelCase will make the codes more readable. https://build.fhir.org/ig/hl7-be/public-health/branches/master/CodeSystem-be-cs-populationscreening-next-invitation-type.html
• What is the difference between the designation and the property https://www.ehealth.fgov.be/standards/fhir/public-health/CodeSystem/be-cs-display-template? The properties are not visualized in the IG https://build.fhir.org/ig/hl7-be/public-health/branches/master/CodeSystem-be-cs-populationscreening-next-invitation-type.html, only the designations. Since these will be used for Flemish screenings, we prefer as much as possible the use of dutch (to the patients). I suspect that the default display in the IG is in english for consistency with other IG's, but we also want to be sure that dutch is adequately supported and visualization software can correctly handle dutch translations. Currently we are waiting for confirmation from CvKO for a proposed dutch translation for both the display and the template.
  • Will all software be able to know what to do with the templates?
  • Should we also add a designation for dutch?
  • Is there a default language and what is the default language that is shown to consumers of the data?

@bdc-ehealth The Dutch displays and templates will be provided on this issue when I get confirmation from CvKO.

[bdc-ehealth]

@kridhaen

1) CamelCase is no problem for me (do we go for lowerCamelCase or UpperCamelCase?) 2) The difference between designation and the display-template property is that the designation is a translation/synonym for the code (readable rendering for the code itself), the display-template property that we added is to indicate that it is a template text with placeholders.

I give an example:

concept: inch

code: in

designation nl-BE: duim designation fr: pouce designation en: inch

display template nl-BE: "{0}"" display template fr: "{0} po" display template en: "{0} in"

2a) We will add it to the textual part of the implementation guide. 2b) Yes, all languages are created equally 2c) There is no default language, only the standard description of the code, which is in English. Softwares will be able to choose the language they like from the designations/templates.

[kridhaen]

1. We prefer UpperCamelCase (PascalCase).

[costateixeira]

Do we want codes to be case sensitive? I would prefer not, and all codes lower case (possibly separated-by-dash)

On Tue, Jan 17, 2023 at 9:23 AM kridhaen @.***> wrote:

1. We prefer UpperCamelCase (PascalCase).

— Reply to this email directly, view it on GitHub https://github.com/hl7-be/public-health/issues/26#issuecomment-1385010706, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUFI3RGYBNLBL574EFDWSZJJDANCNFSM6AAAAAATYCXSFE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[kridhaen]

@costateixeira I would prefer the codes to be as readable as possible, so lowercase can, but preferably serarated-by-dash or '_'. @bdc-ehealth Here are the proposed codes and translations for EN/nl-BE. I'm still waiting for confirmation from CvKO, so it is possible the translations will change.

  | Display (en) | Display (en) template with date -- | -- | -- NextInvitation | Next invitation will be around the indicated date. | Next invitation will be around {0}. DefinitivelyExcluded | Excluded from invitations. | == NotInTargetGroup | No invitations will be sent, you are not part of target group. | == Refusal | No invitations because of refusal. For more information about this investigation, contact your GP. | == TemporarilyExcluded | According to our data, this investigation is either not necessary or not appropriate for you. For more info, contact your GP. Next invitation will be around the indicated date. | According to our data, this investigation is either not necessary or not appropriate for you. For more info, contact your GP. Next invitation will be around {0}. ToBeDetermined | The date for a new investigation depends on the current one. | == Unknown | Insufficient information to determine the next invitation date. | ==

  | Display (nl-BE) | Display (nl-BE) template with date -- | -- | -- NextInvitation | De volgende uitnodiging is voorzien op de opgegeven datum. | De volgende uitnodiging is voorzien rond {0} DefinitivelyExcluded | Je ontvangt geen volgende uitnodiging meer. | == NotInTargetGroup | Je ontvangt geen volgende uitnodiging, je behoort niet tot de doelgroep. | == Refusal | Je ontvangt geen volgende uitnodiging omdat je hebt laten weten dat je geen uitnodiging meer wou ontvangen. Indien je meer informatie wenst over dit onderzoek kan je dit best bespreken met je arts. | == TemporarilyExcluded | Volgens onze gegevens is dit onderzoek voor jou op dit moment niet nodig of niet aangewezen. Daarom ontvang je tijdelijk geen uitnodigingen meer. De volgende uitnodiging is voorzien rond de opgegeven datum. Indien je hierover meer wenst te weten, kan je dit bespreken met je arts. | Volgens onze gegevens is dit onderzoek voor jou op dit moment niet nodig of niet aangewezen. Daarom ontvang je tijdelijk geen uitnodigingen meer. De volgende uitnodiging is voorzien rond {0}. Indien je hierover meer wenst te weten, kan je dit bespreken met je arts. ToBeDetermined | De datum van volgende uitnodiging is afhankelijk van de uitslag van het verdere onderzoek. | == Unknown | We kunnen niet bepalen wanneer u de volgende keer zal uitgenodigd worden. | ==

[bdc-ehealth]

WG: we decide to make all codes all uppercase with underscores and case sensitive.

[costateixeira]

Late in the discussion but for the record:I advise to use the common practice.  Underscores are not common (not sure if the FHIR tooling is accepting this, see e.g resource ids cannot have underscore. I'd use dashes as most codes in FHIR. Codes are not meant to be displayed but it's ok that they form words. so lower-case-separated-with-dashes would be my recommendation

[kridhaen]

In that case, lower-case-separated-with-dashes is also OK for me. We have no real preference, except for it to be case sensitive for simplicity in the used tools for @smals-bvv.

[smals-bvv]

It's ok for Vitalink.

[bdc-ehealth]

WG: conclusion: lower-case-separated-with-dashes + and @smals-bvv confirms that case-insensitive is also fine.