

Why are so many men pregnant? Data entry mistakes in the health industry - jmah
http://www.straightstatistics.org/blog/2012/04/06/why-are-so-many-men-pregnant

======
ak39
Curious. What's the best method of modeling a relational DB structure to
enforce the rule that only:

Gender=F and isPregnant=True

combinations are allowed?

I know application layer can handle this. Also triggers. But is there any
RDBMS that allows enforcement at DB level for rules like this?

~~~
danielmiller
If you feel resentful toward your coworkers or are planning on quitting your
job soon:

You could have Male, Female, and Transgendered tables, each of which point
back to the Patient table. Only the Female table (and perhaps the
Transgendered table) would have an isPregnant column.

~~~
rmc
'Transgender'? You know that's not just one big lump of people? There are
trans women and trans men. Also it would inaccurate (and possibliy) illegal to
refer to a trans man as anything other than male in some cases (ditto for
trans women).

~~~
danielmiller
Agreed!

"Male" isn't one homogenous lump of people; neither is "female". And, as you
mentioned, neither is "transgender(ed)"[1].

[1]: [http://www.paulinepark.com/2011/03/glaad-is-wrong-on-
transge...](http://www.paulinepark.com/2011/03/glaad-is-wrong-on-transgender-
vs-transgendered/)

~~~
danielmiller
[I can't respond to your comment directly. This is a bit off-topic, but I
think it's interesting!! Here goes.]

 _> It is true that "not all men are the same" (and "not all women are the
same"), but splitting into "trans male" and "trans female" is probably more
accurate than lumping all "trans people" into one category.

> After all, it would be silly to have only 2 chategories "trans" and "cis"
> (trans:cis :: gay:straight)._

My original post was in jest—in fact, it was inspired by some _holy-crap-I-
can't-believe-it's-real_ database schema I've had to work with. Someone made
an effort to hyper-normalize things and saddled us with a disaster: Every
query required seven or eight slow joins, and there was duplicate data
sprinkled everywhere (in my example, the same patient could inadvertently have
records in both the Male and Female tables). The "architect" quit a few weeks
after it went to production.

Anyway, I consider (biological) "sex" to be a sliding scale: one end being
female, the other end being male, and the middle being intersex. I consider
(social) "gender" to be where one self-identifies on that scale. Others might
disagree, but I think this is a useful distinction.

Upon reflection, it's obvious that my schema isn't even remotely helpful! My
inclusion of the "Transgendered" table implied that the three tables were
genders, not sexes. Gender, being a self-identified trait, has nothing to do
with whether one can get pregnant.

So if we wanted to hyper-normalize our schema and indicate that only certain
patients can get pregnant, we should clearly have a "Uterus" table. In fact,
it would probably be wise to have tables for every body part, and inner-join
on all of them whenever we need to grab a patient's information. Or we could
use check constraints... but our schema diagrams would be much less
impressive.

------
robgough
Before anyone get's too excited, note that according to _a comment on_ the
same article 96% of those men where under 1 week old - and thus legitimately
males with midwife episodes.

edit: apologies, that was from a comment on the article.

------
miahi
Also check this: <http://blog.xkcd.com/2010/05/06/sex-and-gender/>

------
DanBC
As a cultural note: hospitals have to code stuff, they are then paid by a
Primary Care Trust based on the coding. Thus, there's a financial incentive to
mis-code, or to "code harder". This is, obviously, fraud and the NHS fraud
unit investigates and punishes it.

The other worry is that this data is potentially used for clinical research,
so let's hope people know about the error rates.

