Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Demographics: gender is enforced and cannot be null #91

Closed
p2 opened this issue Sep 25, 2012 · 6 comments
Closed

Demographics: gender is enforced and cannot be null #91

p2 opened this issue Sep 25, 2012 · 6 comments
Assignees

Comments

@p2
Copy link

p2 commented Sep 25, 2012

I ran into this when working on Indivo's demographics, cross-posting from chb/indivo_server#36


The gender can only be male or female once it has been set, it cannot be null again. Removing the gender setting should be allowed. This is important should the patient not want to disclose the gender or is not able to because he/she is inter-sexual.

Related: #89

@jmandel
Copy link

jmandel commented Sep 25, 2012

Yes. I think there are two things to do:

  1. Change the allowed values to "male" or "female" or "undifferentiated" (this simply mirrors the HL7 Administrative Gender value set).
  2. Change cardinality to "0 or 1".

Does this capture it?

@p2
Copy link
Author

p2 commented Sep 25, 2012

This would definitely be enough, so you'd have 4 possibilities:

  • female
  • male
  • undifferentiated
  • unspecified (meaning it's not set)

@nschwertner
Copy link

I don't think that we have any restrictions on the values of the gender field defined in the ontology yet (unless I am missing something)... Would it make sense to encode this restriction properly there?

@jmandel
Copy link

jmandel commented Sep 25, 2012

We don't have any restrictions on string literals in the ontology, as far
as I know. There's a lot we could do here!

On Tue, Sep 25, 2012 at 4:32 PM, nschwertner [email protected]:

I don't think that we have any restrictions on the values of the gender
field defined in the ontology yet (unless I am missing something)... Would
it make sense to encode this restriction properly there?


Reply to this email directly or view it on GitHubhttps://github.com//issues/91#issuecomment-8874060.

@nschwertner
Copy link

Perhaps that could be one of the SMART 0.6 improvements then.

@ghost ghost assigned nschwertner Nov 20, 2012
@nschwertner
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants