Re:   "if you could explain your reconciliation [of FHIR-30686] , it would help me understand whether that is an acceptable disposition to change my vote from negative to affirmative"   Background: Original Comment:  HL7 Core vitals provides redundant and inconsistent advice on constructing panels, specifying the use of Observation.component under #7 and the use of Observation.related under #9. While #9 is out of date (R4 uses "hasMember" rather than the STU3 "related"), the guidance provided for Observation suggests that #9 is correct and #7 is incorrect for Vital Signs. (Viz., "Observation.component is used for any supporting result that cannot reasonably be interpreted and used outside the scope of the Observation it is a component of.") Ramifications of using the incorrect #7 pattern include a collision between appropriate vitals units and units needed for O2 supplementation, a reason for which US Core departs from this specification. US Core repeats  the incorrect #7 guidance from HL7 Core, enforcing the addition of L/min to vitals units\. We should use member\. Existing Wording: 3. Component results Proposed Wording: 3. Member results Disposition for FHIR-30686 : Although Implementers may use this profile as a base for creating one, there is no definition of a vitals "panel" in US Core nor is the hasMember a mandatory or must support element.   Based on prior comments the guidance on components for US Core has been updated here:   http://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-vital-signs.html#mandatory-and-must-support-data-elements Clarification of disposition: The commenter is referencing the FHIR Vitals profile ( http://hl7.org/fhir/R4/vitalsigns.html ) narrative summary items #7 and #9:  We acknowledge that the FHIR vital signs guidance is a) too restrictive a units binding in item 7 and b) referencing an out of date element in 9 as the commenter has noted.    for issue  a) too restrictive a units binding in item 7 : In US Core we have a) acknowledged that there is too restrictive a units binding which results in this collision in the pulse ox profile as an STU Note ( http://hl7.org/fhir/us/core/StructureDefinition-us-core-pulse-oximetry.html#mandatory-and-must-support-data-elements )   for issue   b) referencing an out of date element in 9 : In US core  unlike in the core FHIR vitals profile ( Vital Signs Panel ) , we have not implemented the hasMember element for any vitals profile and therefore is it not an issue that affects US Core.  The US Core Pulse Ox profile has been profiled to use components and not the hasMember element. Note Observation.component  is used for any supporting result that cannot reasonably be interpreted and used outside the scope of the Observation  and   For grouping related observations such as for a "panel" or "battery". In this case the  Observation.code  represents the "panel" code, typically  Observation.value [x]  is not present, and the set of member Observations are listed in  Observation.hasMember    ------------------------------------------------------------------------------------ Re "From the point of view of US Core, this is handled. They could have referred it to the base spec for OO to resolve, since US Core adopts the base profile" The scope and context of the submitted US Core tracker is for US Core.  If it is determined the tracker it out of scope for US Core, but may be addressed through the FHIR specification,  we leave the decision to pursue a new tracker with the proper context of base FHIR  with the commenter.  In our experience forwarding US Core trackers to other work groups leads to confusion in the receiving work group.    Motion: Brett Marquard / Eric Haas : 21-0-2