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

ServiceRequest.category:us-core should be required?

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Published (View Workflow)
    • Highest
    • Resolution: Not Persuasive with Modification
    • US Core (FHIR)
    • 4.1.0
    • Cross-Group Projects
    • STU
    • US Core ServiceRequest Profile
    • 10.137.1.1 10.137.1.2
    • Hide

      Background:

      In the Conformance Requirements page we document how to represent an extensible bindings when slicing by valueset ( which is a technical artifact of the Profile's StructureDefinition):

      Required Bindings When Slicing by Value Sets

      FHIR profiles use slicing when a coded element is a repeating element and a particular value set is desired for at least one of the repeats. This is a special case where a required value set binding is used to differentiate the repeat. In this guide, the minimum cardinality for these ‘slices’ is set to 0 so that other codes are allowed when no suitable code exists in the value set (equivalent to Extensible Binding below). The example in figure 5 below illustrates this structure for the repeating Condition.category element:

      • This structure allows 0..* concept(s) from the required value set.
      • This structure, by being 0..*, allows servers to send concepts not in the required value set.

      Figure 5: US Core Condition.category

       Basically this will look like an extensible valuest "over the wire" and to a validator.

       As the commenter points out

      Profile specific implementation guidance:

      Reasoning:

      We agree that the text seems to mismatch the formal structure and should be clarified

      Proposed Changes:

      Change:

       

      Profile specific implementation guidance:

      to: 

      Profile specific implementation guidance:

      Show
      Background: In the Conformance Requirements page we document how to represent an extensible bindings when slicing by valueset ( which is a technical artifact of the Profile's StructureDefinition): Required Bindings When Slicing by Value Sets FHIR profiles use  slicing  when a coded element is a repeating element and a particular value set is desired for at least one of the repeats. This is a special case where a  required  value set binding is used to differentiate the repeat. In this guide, the minimum cardinality for these ‘slices’ is set to 0 so that other codes are allowed when no suitable code exists in the value set ( equivalent to Extensible Binding below). The example in figure 5 below illustrates this structure for the repeating Condition.category element: This structure allows 0..* concept(s) from the  required  value set. This structure, by being 0..*, allows servers to send concepts not in the required value set. Figure 5: US Core Condition.category  Basically this will look like an extensible valuest "over the wire" and to a validator.  As the commenter points out Profile specific implementation guidance: ... T he  ServiceRequest.category  binding must support at a minimum the  US Core ServiceRequest Category Codes . Within this categorization scheme/axis, other categories codes may be supported and alternate codes may be provided  in addition  to the standard codes. See  Using multiple codes with CodeableConcept Datatype  for examples. Other categorization schemes to be used as well. Reasoning: We agree that the text seems to mismatch the formal structure and should be clarified Proposed Changes: Change:   Profile specific implementation guidance: ... The  ServiceRequest.category  binding must support at a minimum the  US Core ServiceRequest Category Codes . Within this categorization scheme/axis, other categories codes may be supported and alternate codes may be provided  in addition  to the standard codes. See  Using multiple codes with CodeableConcept Datatype  for examples. Other categorization schemes to be used as well. to:  Profile specific implementation guidance: ... The  ServiceRequest.category  binding must support at a minimum the  US Core ServiceRequest Category Codes .   However this valueset can be treated as extensible and other categories codes can be used instead.
    • Brett Marquard/Eric Haas: 15-0-0
    • Clarification
    • Non-substantive

    Description

      "Profile specific implementation guidance" states that "The ServiceRequest.category binding must support at a minimum the US Core ServiceRequest Category Codes."

      In the StructureDefinition, the slice for category:us-core is [0..*].

      If the implementation must support at a minimum the US Core ServiceRequest Category Codes, should the cardinality of category:us-core be [1..*]?

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              yunwwang Yunwei Wang
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: