Currently, "core profiles" such as Vital Signs that are part of FHIR Core follow the same development progression from a timeline perspective as FHIR Core.  That means that, e.g., Vital Signs profile, could not change until R5 is balloted/published.  The challenge is that it would be helpful to have the ability to make updates to "core profiles" independent of the FHIR Core version they are built on, but that is currently not possible.  In the case of Vital Signs, having the ability to do that could have enabled potential changes to the profile to better support FHIR US Core as we learned that some constraints were not appropriate/clear enough, particularly as they are likely (as the case for Vital Signs) are STU until better settled while the underlying resource may already be Normative (as the case for Observation).

There are three ways of addressing this:

• Create a FHIR Core Profile "Library/Implementation Guide" that contains all core profiles, thus enabling separation of development progression timelines.
  • A challenge would be that not all profiles within that Library/IG would necessary move at the same pace.  Being able to manage by profile is better
• Allow for a balloting/review process for one or more core profiles that, once it passes, would yield a FHIR Core dot release
• Some combination of the above where the core profiles sit just outside FHIR Core from a publication process perspective, but one or more profiles, but not necessarily all, can be progressed at their appropriate pace.

This is the link to a confluence page where the above can be further iterated between FMG and TSC that then can resolve this JIRA.