How would you model sex and gender in a patient record?

One field cannot serve five consumers

The reason this is an interview question rather than a lookup is that the single sex column in most legacy schemas is being read simultaneously by things that need different answers. The registration desk and the insurer need what the patient's identity documents say. The laboratory needs to know which reference interval to apply to a haemoglobin or a creatinine. The screening service needs to know which organs the patient has. The letter template needs a name and a pronoun. The clinician on the ward needs to know how to address the person in front of them. When one value is asked to answer all five, it is wrong for at least one of them for a meaningful part of your population, and the failure lands hardest on the patients least able to absorb it.

So the design starts by naming the concepts separately. The HL7 Gender Harmony work does exactly this, and its vocabulary is worth borrowing because it gives you words for the distinctions: gender identity as the person describes it, recorded sex or gender as it appears on a specified document or in a specified system with that source named, sex parameter for clinical use as an explicit input to a clinical decision, and name to use and pronouns for interaction.

What each element is for

Administrative sex is a registration attribute. It matches documents, it flows on claims and eligibility transactions, and it exists because external parties demand a value in a small coded set. It is not a clinical fact and it should not be treated as one.

Recorded sex or gender is a family of values, not a single one: what is on the birth registration, what is on the passport, what a previous care provider sent. The important modelling insight is that these are not competing versions of one truth to be reconciled — they are separate assertions, each true about its own source, and the record should hold them with the source attached rather than overwriting one with another. This is the same reasoning that makes onboarding evidence immutable in other domains: you keep the assertion and its provenance, because the question "why does our record say this" has to be answerable.

Gender identity is what the person says. It can change, it is recorded with a date, and it is patient-supplied rather than derived.

Name to use and pronouns govern how the person is addressed in the interface, on a screen, in a conversation and in correspondence. Getting these wrong is not a cosmetic defect; it is a documented driver of people disengaging from care, which makes it a clinical outcome. The legal name still has to exist and be reachable, because a claim, a prescription label and a legal document need it, so the model needs both with a clear rule about which surface uses which.

The sex parameter for clinical use is the most important one and the one that is almost always missing. It is not a demographic value at all. It is a context-specific input meaning roughly "for this decision, treat this patient's physiology as this", and it exists because a reference range or a risk calculation depends on hormonal state and organ inventory rather than on any identity or document. It can legitimately differ between two decisions about the same patient at the same time, which is precisely why it cannot be a column on the patient.

The interoperability reality

In FHIR, Patient.gender is defined as administrative gender. That is a deliberate, narrow definition and it is the single most useful fact to bring to this discussion, because an enormous amount of bad clinical logic is built on the assumption that it means something clinical. Gender identity, pronouns and clinical sex parameters travel as extensions or as observations depending on the implementation guide you conform to, and which guide you are following determines what a receiver will understand — national and specialty guides differ, and this is an area where they are still moving. An HL7 v2 estate is more constrained again: the administrative sex field in the patient identification segment is one coded value from a small set, and many downstream systems will accept nothing else.

That constraint does not go away by wishing, so the design has to state how it degrades. When you emit to a system that accepts only a small set, you map deliberately, you record what you sent and what was lost, and the mapping is a documented artefact rather than an implicit truncation in a transformation script. A silent degradation is the thing that gets found later, when a receiving system's clinical logic acts on a value your system never intended it to have.

Where the safety failure happens

The concrete harm is not abstract. A reference interval applied from the wrong parameter can make an abnormal result print as normal, and a normal result print as abnormal; a clinician reading a flagged or unflagged value is entitled to assume the flag was computed correctly. A screening recall driven by a demographic field will invite people who do not need the test and omit people who do. A dosing calculation that uses an estimated renal function stratified by sex inherits the same error.

Two design rules follow. Clinical algorithms must take the clinical parameter as an explicit named input, and when it is unknown they must decline to compute and say so rather than fall back to a default. A calculation that silently defaults is worse than one that refuses, because a refusal prompts a human and a default does not. And organ inventory is a better model than any sex field for anything anatomical: recording whether a patient has a cervix, a prostate, ovaries or a uterus answers the screening question directly, is true of far more patients than an inferred rule, and is also correct for patients whose anatomy differs for reasons entirely unrelated to gender — a hysterectomy, a prostatectomy, a congenital variation.

Change, history and access

All of these values change over time and the record has to hold that as history rather than as a current value. Two properties matter. Past clinical decisions must remain interpretable: a result reported against a reference range in 2023 was reported against the range then in force for the parameter then recorded, and rewriting the demographic does not retrospectively change what the clinician saw. And a change must propagate as an observable event to the systems that hold copies, for exactly the same reason a patient merge does.

Finally, these are among the most sensitive elements in a record. Gender identity, a history of transition, and the relationship between a recorded document sex and a current identity can each expose someone to discrimination or harm, and they are frequently not needed by the majority of systems that would receive them by default. So the sharing decision is per element rather than per record: what flows on a claim, what flows to a regional exchange, what is visible on a shared summary, and what requires a specific reason to view. Designing the access rules at the same time as the data model is what separates an answer that has thought about the patient from one that has only thought about the schema.