The Note to Balloters requests includ on categories as a mechanism for managing access control. I would prefer dropping the category expectation. 

In my view, relying on categories for necessary behavior is dangerous:
1) Defining a common set of categories might help people use categories more effectively (e.g., rather than having a proliferation of many similar categories like "lab", "labs", "laboratories", "laboratory", "chem lab", "microbio lab", etc.). But each IG does things differently and creates different (possibly conflicting) expectations.
2) Trying to put sharp definitional edges on categories will be difficult if not futile. What exactly is a "physical activity"?
3) Categories should never be used to differentiate profiles (e.g., "If category is 'laboratory', then this item must follow comply with USCoreObservationLaboratoryResult"). Codes are meant to identify Observations, and the code should be used to determine what the Observation is – not categories. The only solid way to use categories is to have a rule that if   Observation.code is in value set 'PhysicalActivityVS' then you must specify category 'physical-activity' in Observation.category." This provides a way to search using category, with some degree of confidence.

4) To build something solid, categories could be defined in terms of value sets of codes (i.e., if a code from value set V is used in Observation.code, then category C MUST appear in Observation.category). Only then do you have a basis for managing access or efficient search.
5) However, if a value set associated with a category is non-exhaustive ("extendable"), searching by category will not be 100% reliable. (This is a definition, not a binding, so I'm avoiding the use of 'extensible')

That's why categories are unreliable – not something to build a robust system around.