We will clarify that resource.profile is always used to document actual or expected behavior of the system across all instances of the resource, e.g. the lowest common denominator of capabilities for lab, vitals, etc. if declared on Observation.  We will split the resource.supportedProfile into 2 elements: The first will retain the name supportedProfile and will indicate a subset of system capability supported by some but not all of the resources of a given type, e.g. one supportedProfile would define observation lab behavior, another vital sign behavior, etc. We will remove mention of _profile from the definition of supportedProfile.  The second will be a standard extension, also 0..* will be named recognizedProfile and will indicate profiles that the system will recognize if declared in meta.profile. If the system supports the _profile search parameter, then the system will be capable of providing search against the recognized profile. Also may support validation against that profile.  Will also require compatible updates here:  http://build.fhir.org/profiling.html#profile-uses