2015May core #902 - Why are some relationships named while others use vocabulary?

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Considered - Question answered
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU1 [deprecated]
    • Patient Administration
    • (NA)
    • General
    • Hide

      In most cases it depends whether a/ the type is extensible or not, and b/ how long the type list is. If the type list is not extensible and short, then the former is appropriate. If it's extensible, then the former approach cannot be used. If there's a complex instead ofa single reference, then the former approach should not be used. How short the list should be before the former approach is used is left to the discretion of the committee

      Show
      In most cases it depends whether a/ the type is extensible or not, and b/ how long the type list is. If the type list is not extensible and short, then the former is appropriate. If it's extensible, then the former approach cannot be used. If there's a complex instead ofa single reference, then the former approach should not be used. How short the list should be before the former approach is used is left to the discretion of the committee
    • Grahame Grieve / Ewout Kramer : 7-0-1
    • Clarification

      Comment:

      Why are some relationships to other Resources explicilty named in the Resource or in a profile (e.g., Patient.managingOrganization), with the relationship type defined in the attribute name and definition, whereas in other cases, the relationships use a generic triple approach with a coded relationship type (e.g., Patient.link), in which the relationship type is managed through value sets? It seems inconsistent without a clear justification. Would suggest using the former approach consistently.

            Assignee:
            Unassigned
            Reporter:
            Claude Nanjo (Inactive)
            Claude Nanjo (Inactive)
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: