Clinical Reasoning Module resources are not consistent with rest of FHIR

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU2
    • Modeling & Methodology
    • STU
    • Clinical Reasoning Module
    • Hide

      1. We will add a section into the datatypes.html page that explains that there are also a set of "complex type" data types that provide re-useable structures shared across certain resources and provide an enumeration of all that exist

      2. We will establish MnM as the vetting point for introducing new complex structures like this and will develop criteria for when a distinct complex type should be introduced and when resources should simply have inline anonymous types (based on BackboneElement) that may mirror structures found in other resources.

      Show
      1. We will add a section into the datatypes.html page that explains that there are also a set of "complex type" data types that provide re-useable structures shared across certain resources and provide an enumeration of all that exist 2. We will establish MnM as the vetting point for introducing new complex structures like this and will develop criteria for when a distinct complex type should be introduced and when resources should simply have inline anonymous types (based on BackboneElement) that may mirror structures found in other resources.
    • Eric Haas/Ron Shapiro: 3-0-0
    • Enhancement
    • Non-substantive
    • DSTU2

      Clinical Reasoning Module resource structures are not consistent with rest of FHIR which is extremely confusing to both the newbie and to those who are familiar with FHIR and viewing these resources for the first time. In FHIR the elements have been either a a datatype, backbone element or a base type element. The introduction of additional element types such as for example the UsageContext element breaks with this style and prevents the reader from seeing everything in a single view.

      I think consistency within the spec is important as is being able to see everything in a single view. I propose that all these these elements need to be changed to:

      1) backbone elements and listing the components inline (and evaluating which are in the 80% and create extensions for those that fall out of the 80%.)

      2) promoted or demoted to Datatypes or Resources.

            Assignee:
            Unassigned
            Reporter:
            Eric Haas
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: