Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-39652

Clarify the difference between Simple Observation and Screening Assessment

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • US Core (FHIR)
    • 6.0.0-ballot [deprecated]
    • Cross-Group Projects
    • STU
    • US Core Observation Clinical Result Profile
      US Core Observation Screening Assessment Profile
      US Core Simple Observation Profile
    • Hide

      Decision:

      • remove survey, and social hx categories from the US Core Observation Clinical Result Profile us-core category slice binding 
         category:us-core S 0..* CodeableConcept Classification of type of observation
        Binding: Clinical Result Category Value Set (required)
        • This means creating a new ValueSet: Clinical Result Category Value Set
        • social-history
          vital-signs
          imaging
          laboratory
          procedure
          survey
          exam
          therapy
          activity

      Background

      1. All Observations can be Simple Observations. (superset)
      2. All Screening and Assessment have a  category of "survey" per the existing profile
      3. Clinical tests typically do not have a category of survey or social hx, but is not prohibited.

      This is not a concern for most servers and clients because they look at a superset of profiles.  It is a concern for testers and validators. Although the US Core category slice suggests a non-intersecting set of categories for the Observation profiles in question, it does not prohibit other category slices from using these categories and thus does not guarantee that category can always be used to impute the profile.  Another means may be needed for testing, such as a rule to use a meta.profile if the profile cannot be imputed from its contents.

      Rationale:

      By creating a non-intersecting set of Must Support category codes for the Observation profiles in question, testers and implementers will benefit from greater clarity and guidance.  This approach still allows for flexibility in using other categories based on business needs.

      Show
      Decision: remove survey, and social hx categories from the US Core Observation Clinical Result Profile us-core category slice binding    category:us-core S 0..* CodeableConcept Classification of type of observation Binding: Clinical Result Category Value Set ( required ) This means creating a new ValueSet: Clinical Result Category Value Set social-history vital-signs imaging laboratory procedure survey exam therapy activity Background All Observations can be Simple Observations. (superset) All Screening and Assessment have a  category of "survey" per the existing profile Clinical tests typically do not have a category of survey or social hx, but is not prohibited. This is not a concern for most servers and clients because they look at a superset of profiles.  It is a concern for testers and validators. Although the US Core category slice suggests a non-intersecting set of categories for the Observation profiles in question, it does not prohibit other category slices from using these categories and thus does not guarantee that category can always be used to impute the profile.  Another means may be needed for testing, such as a rule to use a meta.profile if the profile cannot be imputed from its contents. Rationale: By creating a non-intersecting set of Must Support category codes for the Observation profiles in question, testers and implementers will benefit from greater clarity and guidance.  This approach still allows for flexibility in using other categories based on business needs.
    • Eric Haas / Yunwei Wang : 13-0-0
    • Clarification
    • Compatible, substantive

    Description

      Background:

      "US Core Observation Screening Assessment Profile" has Observation.category element binds to these codes:

      "US Core Observation Clinical Result Profile" has Observation.category element binds to value set "ObservationCategoryCodes" which also contains the same code survey

      Question:

      That brings a question that when client searches with Observation?category=survey, what profile(s) do the returned resources conform to? Is it "US Core Observation Screening Assessment Profile", "US Core Observation Clinical Result Profile", "US Core Simple Observation Profile", or all of them?

      The question can also be expressed as, according to US Core 6, all resources conforming to "US Core Observation Screening Assessment Profile" SHALL have Observation.category = survey. Is it also true that all resources having Observation.category = survey SHALL conform to "US Core Observation Screening Assessment Profile".

      This is critical issue for Bulk data interactions because Bulk data export are groups by resource types not profiles. When an export requester get an Observation NDJSON files, it is very tricky to figure out the profiles for each Observation resources.

      Recommendation

      US Core provides a clear instruction on how a resource maps to one or some target profiles.

      Attachments

        Activity

          People

            ehaas Eric Haas
            yunwwang Yunwei Wang
            Yunwei Wang
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: