A base expectation is that all FHIR interfaces SHALL conform with the base FHIR rules.  I.e. syntax must be valid, dates must be valid dates, etc.  Systems having legacy data that is non-conformant have a variety of mechanisms to manage that: use of extensions to convey alternate values (e.g. send "Nov. 31, 2018" as a string text) choosing to send information in narrative only choosing to package information as a rendered PDF in DocumentReference, etc. We will add guidance to the Best Practices for Implementers page about these strategies for dealing with non-base-spec-conformant data.   The expectations for the current binding strengths mean what they mean.  However, we are introducing additional binding capabilities in R5 that will allow more nuanced expression of what designers need to be able to express.  See https://build.fhir.org/ig/FHIR/fhir-tools-ig/StructureDefinition-additional-binding.html  .  For example, U.S. Core Condition might have a 'preferred' binding to the current SNOMED + ICD10 value set as well as an 'additional-binding' extension that declares a 'current' binding to the same value set - which would mean that legacy data SHOULD be mapped, but it's ok if it's not, while net new data SHALL be mapped (because SNOMED will always have an appropriate code at some granularity). We will highlight the availability of this extension on the "Best Practices for Implementers" page as well.   Servers may support a variety of implementation guides.  There is no guarantee that all data they have available on their FHIR interfaces will necessarily comply with all implementation guides.  On the other hand, some clients may not be able to safely consume data that does not comply with a given IG. In environments where there will be a need to expose a mixture of IG-conformant and non-IG conformant data, but some consumers will depend on data being conformant to safely consume, then Resource.meta.profile can be used to explicitly flag the instances that conform.  We will put this statement in the Best Practices for Implementers page as well.   There is still an open issue about whether or how instances should indicate whether they make a tight (e.g. 'current') binding vs. only adhering to the looser base binding.  We will leave this open for now.