Re: Adding Specimen.subject Proposal Add Specimen.subject  MS 0..1,  type reference MS target US Core Patient. Add Should search by patient search parameter. Rationale The main argument against adding Specimen.subject is that it might be unnecessarily restrictive, as not all specimens may have a relevant subject associated with them.  For example, if using the Specimen as a contained resource, or might not be relevant or applicable to all use cases. The main arguments for adding Specimen.subject is better Compliance with USCDI Regulations and access. Since US Core's main focus is accessing patient data, the argument that Specimen.subject is better Compliance with USCDI Regulations and patient access is compelling. RE: Using CodeableReference DataType Proposal: Observation.specimen to remain Reference datatype Rationale: There many arguments against using FHIR R5 datatype CodeableReference in US Core which is based on FHIR R4: Lack of Backwards Compatibility: Using the FHIR R5 datatype CodeableReference in a system based on FHIR R4 could result in compatibility issues, as the newer datatype may not be fully supported by the older version of the specification. Increased Complexity: Implementing the newer datatype could increase the complexity of the system, as it may require additional development resources and may also require updates to existing integrations and interfaces. Incompatible Tools and Libraries: The use of the FHIR R5 datatype may also limit the use of certain existing tools and libraries, as they may not be fully compatible with the new specification. Lack of Adoption: FHIR R5 is a relatively new specification, and there may not be widespread adoption or support for the CodeableReference datatype, leading to potential challenges in implementation and maintenance.     Please note that we have used OpenAI's chatCPG to assist in answering this question. We review these responses and the information provided is based on our experience and implementer feedback and our design choices for US Core.