In context of https://jira.hl7.org/browse/FHIR-28375 we propose that the intent is for any data type from the base standard to be valid, but that the Query Responder only needs to support those data types and their components where it actually manages and maintains data in the data type format.  We also propose that the intent is clarified that if there is no binding for the data at hand when using CodeableConcept then only .text is required.   

The intent was not to require underlying systems to add new functionality to manage additional data formats they currently do not support, rather to make the data they do have available using the appropriate data type that FHIR has available to express that.  For example, Integer is a Quantity without a unit.  Labs don’t result a ratio or a range in a separate low/high field.  Those would likely be a CodeableConcept or a string.  Booleans would likely be expressed as CodeableConcept.  Laboratories that outsource their testing will not be able to meet all the date type requirements, because interfaced tests are usually configured as a string only. 

EHRs typically do not save and forward (via API or other means) raw, unvalidated sampled data (SampledData), e.g., for ECG. Rather, a clinician first validates the data within specialized systems, upon which time it is appropriate to make available via API based on an EHR while a specialized system may have the need to expose the sampled data.  Consequently, it is more likely that EHRs would connect to other systems to enable accessing/viewing such data using dedicated viewers/capabilities provided by other specialized systems.  Therefore, while some specialized systems may have use for this, others such as EHRs should not be encumbered to support that data type as well.

Other non-Lab data may have a need for SampledData, but those are out of scope, e.g., EKG, and not every system would necessarily need to manage the raw data as per above

The Period data type is not relevant for lab results as there are no known lab results that have a value of a date range.

As the FHIR US Core profile is used for accessing and exchanging data based on what the source system has, this should not require the data source system to add functionality to enable SampledData and Period as part of Observation.value[x]. Additionally, C-CDA does not impose this requirement either.

Links to pages:

http://hl7.org/fhir/us/core/STU3.1/StructureDefinition-us-core-observation-lab.html

https://build.fhir.org/ig/HL7/US-Core-R4/StructureDefinition-us-core-observation-lab.html