Re: Adding new genders for "spayed" veterinary med patients - it worked?

Maria Scappini <[email protected]> Wed, 23 Apr 2025 17:39:59 -0300
Newsgroups gmane.comp.gnu.medical.devel
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------vhrekoGLvZDJfDaO9Ued61f0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello!

> Did you find ?
>
> 	https://www.gnumed.de/documentation/schema/release/

Dumbly I didn't think to look in the docs! I created a new schema "profile"
with postgresql_autodoc, but now I'll just look to that for the up-to-date
database schema! Thank you!

> I have released 1.8.20 (to be packaged for the next Debian
> Stable, hopefully) such that we got some of the any-staff
> shenanigans out of the way.

Thank you so much!! I had been using it and testing almost from its release,
and now version 1.8.21!

> Regarding the neutered/spayed aspect:
>
> The need is clearly understood. Therefore I have updated the
> client code (for 1.9) to
>
> 	- not have a constraint on dem.gender_label.tag
>
> 	- offer a column dem.gender_label.symbol for storing a
> 	(unicode) symbol to denote the gender if so desired
>
> I plan on adding some GUI code to conveniently adjust the
> available gender designations.

Great, and thanks!! I had some trouble with not having the unicode 
symbol set, some features did not work as expected, and had to add the 
missing symbols to the appropiate dictionaries in gmPerson.py .

> Now, some thinking on it seems to reveal that "neutered"
> really isn't a gender as such. It is not even a change of
> gender. It is a "procedure" having been performed on
> patient, and a "tag" attributable to a patient. So, two
> other options, which may also be applied simultaneously, and
> can be searched for (think statistics) are:
>
> A procedure:
>
> 	clin.procedure: document a neutering procedure to have
> 	been performed
>
> A patient "tag":
>
> 	dem.identity_tag -> ref.tag_image: apply a tag
> 	"neutered" to a patient record which will then be shown
> 	in the top panel below the patient name

You are absolutely right. Neutering (orchiectomy, ovariohysterectomy) is a
procedure and should be registered as such! Right now I am registering my
"test" patients that are neutered with: procedure, gender change, and tag.
I have made a pros and cons list of each method of registering, and procedure
+ tag as you mentioned are the most logical options instead of pseudo-genders.

One "disadvantage" (apart from being logically incorrect) of not using
the gender to determine neutering state is that non-clinical staff accounts
(front desk staff mainly) won't be able to note neutering state in the gender
when registering new patients... which is also not totally necessary. This could
be done instead by the medical practitioner during the consultation. Even set up
a reminder (dynamic hint?) so that with each patient this parameter is registered...
I'll be experimeting.

> On a higher level: the whole gender processing thing needs a
> makeover. I can think of needs for all of the following:
>
> 	dem.identity.gender_preferred
>
> 		what a patient "feels like",
> 		the gender "identity",
> 		might change more than rarely
>
> 		relevance: how to properly address the patient (psychological well-being)
>
> 	dem.identity.gender_legal
>
> 		designated, officially-declared-to-be, what's-in-the-passport
>
> 		relevance: interaction with the society at large may
> 		require to use the "legalized" gender on, say, forms
>
> 	dem.identity.gender_biological
>
> 		what a patient is "built like",
> 		organs / chromosomes / hormones / ...
>
> 		relevance: deliver proper care (choice of
> 		medication, symptoms, prevalence of disease, ...)
>
> 	dem.identity.sexual_orientation
>
> 		what a patient is "attracted to"/intimately
> 		interacting with
>
> 		relevance: risk profiles [say, MSM], need for, say,
> 		PREP
>
> This won't end up in GNUmed today, but it's good to be spelt
> out (except that we might get banned in the US q:-{ ) in
> case someone comes along in yet another 15 years ;-D

This all makes a lot of sense! Maybe even my vet patients could benefit,
maybe the sexual_orientation field would be more proper for registering spayed
patients (maybe as asexual? custom label?) since it does influence risk for
certain pathologies in small animals (uterine fluid collection, prostatic problems..),
which is the main reason we register neutering state, apart from identification
purposes.

... And hopefully no countries will ban this project before then :P

Thank you,
María

--------------vhrekoGLvZDJfDaO9Ued61f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre>Hello!</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">Did you find ?

	<a class="moz-txt-link-freetext" href="https://www.gnumed.de/documentation/schema/release/">https://www.gnumed.de/documentation/schema/release/</a>
</pre>
    </blockquote>
    <pre>
</pre>
    <pre>Dumbly I didn't think to look in the docs! I created a new schema "profile"
with postgresql_autodoc, but now I'll just look to that for the up-to-date
database schema! Thank you!

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">I have released 1.8.20 (to be packaged for the next Debian
Stable, hopefully) such that we got some of the any-staff
shenanigans out of the way.</pre>
    </blockquote>
    <pre>
Thank you so much!! I had been using it and testing almost from its release,
and now version 1.8.21!

</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">Regarding the neutered/spayed aspect:

The need is clearly understood. Therefore I have updated the
client code (for 1.9) to

	- not have a constraint on dem.gender_label.tag

	- offer a column dem.gender_label.symbol for storing a
	(unicode) symbol to denote the gender if so desired

I plan on adding some GUI code to conveniently adjust the
available gender designations.</pre>
    </blockquote>
    <pre><span style="white-space: pre-wrap">
Great, and thanks!! I had some trouble with not having the unicode symbol 
set, some features did not work as expected, and had to add the missing 
symbols to the appropiate dictionaries in gmPerson.py .
</span></pre>
    <p><span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">Now, some thinking on it seems to reveal that "neutered"
really isn't a gender as such. It is not even a change of
gender. It is a "procedure" having been performed on
patient, and a "tag" attributable to a patient. So, two
other options, which may also be applied simultaneously, and
can be searched for (think statistics) are:

A procedure:

	clin.procedure: document a neutering procedure to have
	been performed

A patient "tag":

	dem.identity_tag -&gt; ref.tag_image: apply a tag
	"neutered" to a patient record which will then be shown
	in the top panel below the patient name
</pre>
    </blockquote>
    <pre>
You are absolutely right. Neutering (orchiectomy, ovariohysterectomy) is a 
procedure and should be registered as such! Right now I am registering my 
"test" patients that are neutered with: procedure, gender change, and tag.
I have made a pros and cons list of each method of registering, and procedure
+ tag as you mentioned are the most logical options instead of pseudo-genders.

One "disadvantage" (apart from being logically incorrect) of not using 
the gender to determine neutering state is that non-clinical staff accounts
(front desk staff mainly) won't be able to note neutering state in the gender
when registering new patients... which is also not totally necessary. This could
be done instead by the medical practitioner during the consultation. Even set up
a reminder (dynamic hint?) so that with each patient this parameter is registered...
I'll be experimeting.
</pre>
    <pre>
</pre>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <pre wrap="" class="moz-quote-pre">On a higher level: the whole gender processing thing needs a
makeover. I can think of needs for all of the following:

	dem.identity.gender_preferred

		what a patient "feels like",
		the gender "identity",
		might change more than rarely

		relevance: how to properly address the patient (psychological well-being)

	dem.identity.gender_legal

		designated, officially-declared-to-be, what's-in-the-passport

		relevance: interaction with the society at large may
		require to use the "legalized" gender on, say, forms

	dem.identity.gender_biological

		what a patient is "built like",
		organs / chromosomes / hormones / ...

		relevance: deliver proper care (choice of
		medication, symptoms, prevalence of disease, ...)

	dem.identity.sexual_orientation

		what a patient is "attracted to"/intimately
		interacting with

		relevance: risk profiles [say, MSM], need for, say,
		PREP

This won't end up in GNUmed today, but it's good to be spelt
out (except that we might get banned in the US q:-{ ) in
case someone comes along in yet another 15 years ;-D</pre>
    </blockquote>
    <pre>
This all makes a lot of sense! Maybe even my vet patients could benefit,
maybe the sexual_orientation field would be more proper for registering spayed
patients (maybe as asexual? custom label?) since it does influence risk for
certain pathologies in small animals (uterine fluid collection, prostatic problems..),
which is the main reason we register neutering state, apart from identification
purposes.

... And hopefully no countries will ban this project before then :P

Thank you,
María

</pre>
  </body>
</html>

--------------vhrekoGLvZDJfDaO9Ued61f0--