Our prior Jan 2018 ballot comment, GF#14503, has an applied status, but the changes aren't reflected in the Jan 2019 ballot. For example, the resolution states that the PractitionerRole.code and speciality requirements would be relaxed, but the profile still shows code and specialty as required.

We recommend that these requirements be loosened for the base US Core profile, which would be required for any US FHIR server, regardless of use case. Instead, put directory-specific concerns into an IG that directly addresses the needs of a provider directory use case. Required roles, specialties, _include support, and any necessary limits on location should be moved to a directory IG or only required for servers exposing a provider directory. This IG should build off of the less restrictive US Core PractitionerRole. During that process, we may want to consider clarifying the different value sets that would be applicable for a role vs. a specialty.

In STU3, workflow patterns allowed expression of a Practitioner + Organization, such as:
Event.performer.actor (Pracitioner) + Event.performer.onBehalfOf (Organization)
Request.requester.agent (Practitioner) + Request.requester.onBehalfOf (Organization)

Looking forward to R4, this worklfow pattern is being replaced with a reference to PractitionerRole, such as:
Event.performer.actor (Pracitioner | PractitionerRole)
Request.requester (Practitioner | PracitionerRole)

In sum, where implementers in STU3 could convey only Practitioner + onBehalfOf (Organization), the change in R4 would not only require PracitionerRole resource, but this profile would then require additional fields (e.g. role, speciality, etc.), which might not be known.