Written right after the meeting on the plane ride home.
- Identify the primary types (ie: named context of use) of sex/gender classifications/uses that are currently needed
- Name and define these types - SexGenderTypes
- include descriptions of the context of use for each SexGenderType.
- If no real context of use can be identified then place the type on a to-do list and move on. Where agreement exists, link the context of use to existing clinical models/systems.
- It is fine to identify existing model/systems that based on definition or existing allowed values, are linked to multiple sexy types.
- clarify the general context of use (write a definition) for the word “Sex” and the word “gender”
- Identify code/description/definition (ie, concepts, but not necessarily from an existing code system) to be used for each SexGenderType
- While we may draw from a code system, this is not intended to restrict the process to use existing concepts. We’ll match things up later
- Work to align with existing use and existing concepts, but not be hog-tied to them
- Based on the context of use determined for the SexGenderTypes. Decide if the value set associated with the SexGenderType is “closed” or “open”. Perhaps this could change in the future, but it’s not expected to.
- CLOSED - no further concepts are to be used. This means any situation that doesn’t quite seem to fit one of the defined values would have to compromise and pick an existing value.
- This means if we need to support Other or Unknown, we say that. (A so called null type)
- OPEN - the defined set of concepts can be extended if the meaning that needs be sent is not in the provided value set. This is exactly equivalent to the FHIR Extensible binding strength. The expectation is that a concept from a different code system would be sent, and if that is not supported, then a text string.
- If two SexGenderTypes are the same but one context needs to have a null, or needs to not be closed, that is a different context, so it’s a different SexGenderType.