DICOM Correction Proposal

STATUS

Assigned

Date of Last Update

2019/ 12/13 08/27

Person Assigned

Sex and Gender Ad Hoc

Submitter Name

Sex and Gender Ad Hoc

Submission Date

20180609

 

Correction Number CP- 1927

Log Summary: Patient Sex and Gender

Name of Standard

PS3.2, 3.3, 3.4, 3.6 3.15, 3.16, 3.17, 3.18, 3.20, 3.21, 2019a

Rationale for Correction:

Various jurisdictions are requiring the use of specific gender codes for administrative use on patients. It is unclear as to whether the present Patient’s Sex (0010,0040) specifies a phenotypical sex or the patient’s social context gender. (When the attribute was defined in ACR-NEMA 300-1985, the distinction between sex and gender, and the independence of those concepts, was not well established in healthcare IT.)

At least the following administrative rules have been promulgated:

1.        The California legislature has added a “non-binary” code

2.        Australia has added an “X” value, defined both “sex” and “gender”, and promulgated regulations for their use, https://meteor.aihw.gov.au/content/index.phtml/itemId/635994

The Californian and Australian definitions overlap but are not the same.  Jurisdiction specific codes and definitions are expected in other jurisdictions.  These codes have administrative consequences for the patient and can affect how imaging procedures should be performed.

Further, both sex and gender may change over time (e.g., sex through procedures/medications, gender through patient assertion). The placement of Patient’s Sex in the Patient Module, which cannot vary across different studies, is problematic.  Patient Name (0010, 0010) and other potentially changing attributes are found in both the Patient Module and the Patient Study Module.  This CP clarifies how that situation is handled.

There are also DICOM philosophical rules regarding how changes are made:

1.        The 25 plus years of existing medical image archives cannot be invalidated.

2.        The installed base of thousands of machines cannot be invalidated.

3.        We want to minimize having different meaning for DICOM objects in different jurisdictions when jurisdictions have different definitions.

The proposal is to

1.        Clarify the definition for Patient’s Sex (0010,0040).  It was originally for general use for clinical purposes.  The administrative gender was not the original concern.  The original use and continuing use that has direct impact on safety and efficacy is the use of Patient’s Sex (0010,0040) as part of the formulae for various dose and diagnostic results.

2.        Add an administrative gender attribute Patient’s Gender (0010,xxxx). 

3.        Other attributes may be added based on HL7 Vocabulary Workgroup https://confluence.hl7.org/display/VOC/Vocabulary+Work+Group?src=breadcrumbs-parent work completion,

Existing DICOM objects will lack Patient Gender (0010, xxxx), and administrative gender will need to be obtained from other sources.  (Often, but not always, the administrative gender will match the Patient’s Sex (0010,0040).) 

Jurisdictional rules also change, and implementations and objects will usually lag these changes.  When patients move from one jurisdiction to another, the DICOM objects will not always match.  This is not different than the situation for other kinds of attribute changes, but the audience for this CP may be less aware of that.

A description section is added to explain this in more detail as part of the description for the new administrative gender attribute.

 

 

 

 

Open Issues

3.

Should we create a gender CID to include in TID 1007 Subject Context, Patient?  It has subject sex; does it also need a subject gender?  We need to fix a conflict between description and CID.

5.

Can gender be required on Part 18 search? Should the resulting non-conforming past implementations be accepted? New actor created? Make it optional and deal with it by conformance claim?

 

 

7.

How should HL7 codes be handled?  The current Patient’s Sex (0010,0040) is a Defined Term.  What should be done for Patient’s Gender (0010,xxxx)?

8.

Should we have a “Comment on Patient Sex and Gender”?  Should there be two separate comments?  Should we explicitly refer to Patient Comments (0010,4000)?

Update patient comments description and remove the new attribute.

9.

Should Patient Comments (0010,4000) be moved from C.7.1.1.1 Patient Module to C.7.2.2 Patient Study Module?  NO, never move existing attributes.  But new attributes can be created in other modules. These may vary from study to study because they may reflect temporary, transient, or changed characteristics of the patient.  That would make it more appropriate for comments on patient sex and gender that reflect changes.

Duplicate Patient Comments into Patient Study Module.

10.

What new attributes should be created to capture more specific sub-sets of genotypic and phenotypic parameters? Is this captured in an updated TID 1007?  Should this be part of a later CP?

11.

What are the present models in open literature, implementations, etc.?  Copy bibliography in from HL7.

12.

How do we handle instructions on what algorithm to pick for selecting sex or gender when the other is missing?  What about other sex related instructions?  What new attributes should be created?  What guidance should be given on their use?

 

 

16.

All Supplements that are in progress need to be updated somehow.  Some will be complete and final text before this CP is balloted and need to be added to this CP

18.

Update Part 16 TID 1007, CID 7455 (which is mostly diagnostic codes and non-extensible) and/or CID 7457 (which is M, F, and extensible) to include gender codes?

20.

Should we include a “patient preferred name” in workflow?  This CP? A different CP?  This is an issue for more than gender, e.g., “Herr Professor Doctor Schmidt” vs “Willi”. 

YES – in workflow and storage IODs.

21.

The new attributes are proposed as type 3 so that they do not trigger creation of new SOP classes.  They are a better fit to type 2 so that the concept “attempted but failed to get a value” can be encoded.  Is there a way to finesse this issue?  Is it a problem if that concept cannot be encoded?  Should a code value for this be added to the definition? <wg-06 question, November meeting>

22.

Update Supplement 209, DCS Conformance <necessary?>

E.g., Australia privacy regulations require a statement with justification for maintaining sex information in records.  Will this be part of a conformance statement from DICOM, or put somewhere else by the vendor?

Should this be covered by having a section in the DCS for other regulations that are also complied with, e.g., GDPR, DIN, and UL?  Should this be part of Supplement 209?  These privacy regulation responses could go in such a section.

 

 

 

 

Closed Issues

1.

Should the conformance statement describe how sex/gender is managed?  How does it apply to query? How does it apply to other behavior? Etc.

NO, not in this CP.  Send issue to WG31 for consideration.

2.

Should the use cases be a Part 17 annex or separate document?

4.

Do not update CID 7457.  This is for small animals and groups of small animals where gender is not an issue.

6.

Are there any SOP classes that deserve creating a new SOP class where gender is type 2?  E.g., UPS.

NO

 

 

13.

Does DICOM have a need for an “identity document sex/gender” attribute?  This is the sex/gender that is present on an ID such as a Passport, National ID, or Driving License.  At present HL7 describes this as “sex/gender from an identity document”.  These are needed in some legal and administrative workflows that matter to HL7, such as during patient admission.

No – DICOM workflows do not need Identity document information.  We are not aware of operational workflows where patient identity documents are checked as part of the process.  E.g., confirmed identity from modality worklist against National ID.

15.

Should gender be a study level variable? Should a study level sex attribute be defined?  Yes.

Added text that describes inclusion of both attributes in Patient Module and Patient Study Module.

14.

Is this a supplement or a CP?  <wg-06 question, November meeting>

NO – flag this CP for special public comment.

 

 

17.

Postpone updates to Part 20 until after HL7 completes their work on CDA and WG-20 will take care of this as part of updating Part 20 for those changes

19.

Include both sex and gender, in both image IODs and workflow IODs.

23.

Gender for animals is not prohibited and can be defined if the veterinarians have a use for it.  Not in this CP.

 

Update Part 3, Table C.2-3. Patient Demographic Module Attributes

Table C.2-3. Patient Demographic Module Attributes

 

Attribute Name

Tag

Attribute Description

Patient's Sex

(0010,0040)

Sex of the named Patient.

Sex to be used for Clinical Purposes

Enumerated Values:

M male

F female

O other non-binary , e.g., intersex, other situations where neither male nor female apply clinically. [rjh1]

 

Explain how this will work in practice. (point to annex) [rjh2]   If the code is “O” go read the instructions, comments, and medical record.

 

 

See also section C.7.1.1.1.y

Patient’s Gender

(0010,xxxx)

The codes for the patient’s gender.  See section C.7.1.1.1.x

Gender/Sex Comment

(0010,xxx1)

Description of sex or gender issues that are significant to describing intended or actual performance of a procedure or analysis of procedure results.

 

 

Update Part 3, Table C.4-13. Performed Procedure Step Relationship Module Attributes

Table C.4-13. Performed Procedure Step Relationship Module Attributes

Attribute Name

Tag

Attribute Description

Patient's Sex

(0010,0040)

Phenotypic Sex of the named Patient.

Enumerated Values:

M male

F female

O other non-binary

See also section C.7.1.1.1.y

Patient’s Gender

(0010,xxxx)

Selected gender of the patient.  See section C.7.1.1.1.x

Gender/ Sex Comment

(0010,xxx1)

Description of sex or gender issues that are significant to performance of a procedure or analysis of procedure results.

Gender Comment

(0010,xxx1)

Description of gender issues that are significant to performance of a procedure or analysis of procedure results. [rjh3]

Add sections C.7.1.1.1.x and C.7.1.1.1.y

 

C.7.1.1.1.x Patient's Gender

 

The values for Patient's Gender (0010,xxx1) are categories established by local legal, social, and cultural processes and influence the administrative and social treatment of the patient.  The patient’s gender affects social interactions, such as patient interaction with the office staff. [rjh4]

The Patient's Gender (0010,xxx1) is the same as the Patient's Sex (0010,0040) for most of the population, but any combination of values is possible.

C.7.1.1.1.y Patient's Sex

Patient's Sex (0010,0040) reflects the patient's phenotypic sex (measureable and observable characteristics) . and It is intended for uses such as computing dose and diagnostic parameters.  For example, the formula for SUVlbm [rjh5] depends upon the patient’s phenotypic sex.

The Patient's Sex (0010,0040) is the same as the Patient's Gender (0010,xxx1)   for most of the population , but any combination of values is possible.

The Patient’s Sex Neutered (0010,2203) is required if the patient is an animal.  It may be present otherwise but does not generally apply to humans. 

<A note or reference to Part 17 on transition is needed.  All the existing objects and systems generate only sex.  This will only slowly transition toward systems and objects that have both.  Part 17 will need to discuss issues around that transition.  For example, most people (over 90%, perhaps over 98%) have the same Sex and Gender.  So in the absence of any other information, it makes good statistical sense to assume that they are the same.  The key is to separate assumed values from known values.>

Update Part 3, Table C.7-1 Patient Module Attributes

 

Table C.7-1. Patient Module Attributes

Attribute Name

Tag

Type

Attribute Description

Patient's Sex

(0010,0040)

1

Sex of the named Patient.

Enumerated Values:

M male

F female

O other non-binary

See also section C.7.1.1.1.y

Patient’s Gender

(0010,xxxx)

3

Patient’s gender.  See section C.7.1.1.1.x

Gender/Sex Comment

(0010,xxx1)

3

Description of sex or gender issues that are significant to describing intended or actual performance of a procedure or analysis of procedure results.

 

Modify  Part 3, section C.7.2.2 Patient Study Module

Table C.7-4a defines Attributes that provide information about the Patient at the time the Study started.

Notes:

  1. In the case of imaging a group of small animals simultaneously, the Attributes in this Module can only have values that apply to the entire group, otherwise they are absent (e.g., Patient's Weight (0010,1030)) or empty (e.g., Patient's Sex Neutered (0010,2203).
  2. Some of the attributes in Patient Study Module are also found in the Patient Module.  When an Information Object is encoded this module distinction is lost.  For example, there is only one attribute Patient’s Weight (0010,1030) in a CR SOP Instance although it occurs in both the Patient Module and the Patient Study Module.  In image storage SOP Instances, the Patient Module and Patient Study Module are effectively merged.  The distinction between Patient level and Patient Study level is significant in C-FIND operations, see PS 3.4, section C.3 Standard Query/Retrieve Information Module.

In most situations, the attribute values in both Patient Module and Patient Study Module are expected to reflect the situation at the time of creation, e.g., time of study.  There will be exceptions to this based upon local policies for updating patient demographic information when it changes.

 

Update Part 3, Table C.7-4a. Patient Study Module Attributes

Table C.7-4a. Patient Study Module Attributes

 

Attribute Name

Tag

Type

Attribute Description

Patient’s Sex

(0010,0040)

1

Sex of the named Patient.

Enumerated Values:

M male

F female

O other non-binary

See also section C.7.1.1.1.y

Patient’s Gender

(0010,xxxx)

3

Patient’s gender.  See section C.7.1.1.1.x

Gender/Sex Comment

(0010,xxx1)

3

Description of sex or gender issues that are significant to describing intended or actual performance of a procedure or analysis of procedure results.

 

 

 

 

 

Update Part 3, Table C.30.4-1. Unified Procedure Step Relationship Module Attributes

Table C.30.4-1. Unified Procedure Step Relationship Module Attributes

Attribute Name

Tag

Type

Attribute Description

Patient’s Sex

(0010,0040)

1

Sex of the named Patient.

Enumerated Values:

M male

F female

O other non-binary

See also section C.7.1.1.1.y

Patient’s Gender

(0010,xxxx)

3

Patient’s gender.  See section C.7.1.1.1.x

Gender/Sex Comment

(0010,xxx1)

3

Description of sex or gender issues that are significant to describing intended or actual performance of a procedure or analysis of procedure results.

 

 

 

 

 

Update Part 4, Table C.6-1 Patient Level Attributes for the Patient Root Query/Retrieve Information Model

Table C.6-1. Patient Level Attributes for the Patient Root Query/Retrieve Information Model

Attribute Name

Tag

Type

Patient's Sex

(0010,0040)

O

Patient’s Gender

(0010,xxxx)

O

Gender/Sex Comment

(0010,xxx1)

O

Other Patient IDs Sequence (0010

1002) O

 

 

Update Part 4,  Table C.6-5

Table C.6-5. Study Level Keys for the Study Root Query/Retrieve Information Model

Attribute Name

Tag

Type

Patient's Sex

(0010,0040)

O

Patient’s Gender

(0010,xxxx)

O

Gender/Sex Comment

(0010,xxx1)

O

Other Patient IDs Sequence

(0010,1002)

O

 

Update Part 4,  Table F.7.2-1

Attribute Name

Tag

Req. Type N-Create (SCU/SCP)

Req. Type N-SET (SCU/SCP)

Requirement Type Final State (see Note 1)

Patient’s Sex

(0010,0040)

2/2

Not Allowed

 

Patient’s Gender

(0010,xxxx)

3/3

Not Allowed

 

Gender/Sex Comment

(0010,xxx1)

3/3

Not Allowed

 

 

Update Part 4,  Table F.8.2-1 Modality Performed Procedure Step Retrieve SOP Class N-GET Attributes

Attribute Name

Tag

Req. Type (SCU/SCP)

Patient’s Sex

(0010,0040)

3/2

Patient’s Gender

(0010,xxxx)

3/3

Gender/Sex Comment

(0010,xxx1)

3/3

 

Update Part 4,  Table K.6-1. Attributes for the Modality Worklist Information Model

Description / Module

Tag

Matching Key Type

Return Key Type

Remark/Matching Type

Patient’s Sex

(0010,0040)

O

2

 

Patient’s Gender

(0010,xxxx)

O

3

 

Gender/Sex Comment

(0010,xxx1)

O

3

 

 

Update Part 4, Table Q.4-1. Attributes for the Relevant Patient Information Model

Description / Module

Tag

Matching Key Type

Return Key Type

Remark/Matching Type

Patient’s Sex

(0010,0040)

-

2

 

Patient’s Gender

(0010,xxxx)

-

3

 

Gender/Sex Comment

(0010,xxx1)

-

3

 

 

 

Update Part 4, Table V.6-2. Attributes for the Substance Approval Query Information Model

Description / Module

Tag

Matching Key Type

Return Key Type

Remark/Matching Type

Patient’s Sex

(0010,0040)

-

2

 

Patient’s Gender

(0010,xxxx)

-

3

 

Gender/Sex Comment

(0010,xxx1)

-

3

 

 

Table CC.2.5-3. UPS SOP Class N-CREATE/N-SET/N-GET/C-FIND Attributes

Attribute Name

Tag

Req. Type N-CREATE (SCU/SCP)

Req. Type N-SET (SCU/SCP)

Final State

Req. Type N-GET (SCU/SCP)

Match Key Type

Return Key Type

Remark/Matching Type

Patient’s Sex

(0010,0040)

2/2

Not Allowed

O

3/2

R

2

 

Patient’s Gender

(0010,xxxx)

3/3

Not Allowed

O

3/3

-

3

 

Gender/Sex Comment

(0010,xxx1)

3/3

Not Allowed

O

3/3

-

3

 

 

 

Update Part 6, Table 6-1. Registry of DICOM Data Elements

Table   6-1.   Registry of DICOM Data Elements

Tag

Name

Keyword

VR

VM

 

(0010,xxxx)

Patient’s Gender

PatientGender

 

 

 

(0010,xxx1)

Gender/Sex Comment

GenderSexComment

 

 

 

 

Update Part 15 Table   E.1-1.   Application Level Confidentiality Profile Attributes

<is any discussion needed in the text?  Are the new values right?  Can’t answer for sure until HL7 coding and structure is finished.>

<Should we revise Patient’s Sex confidentiality>

 

Attribute Name

Tag

Retd. (from PS3.6 )

In Std. Comp. IOD (from PS3.3 )

Basic Prof.

Rtn. Safe Priv. Opt.

Rtn. UIDs Opt.

Rtn. Dev. Id. Opt.

Rtn. Inst. Id. Opt

Rtn. Pat. Chars. Opt.

Rtn. Long. Full Dates Opt.

Rtn. Long. Modif. Dates Opt.

Clean Desc. Opt.

Clean Struct. Cont. Opt.

Clean Graph. Opt.

Patient’s Sex

(0010,0040)

N

Y

Z

 

 

 

 

K

 

 

 

 

 

Patient’s Gender

(0010,xxxx)

N

Y

Z

 

 

 

 

K [rjh6]

 

 

 

 

 

Gender/Sex Comment

(0010,xxx1)

N

Y

Z

 

 

 

 

K [rjh7]

 

 

 

 

 

 

Update Part 16 TID 1007, CID 7455 Sex (11 codes mostly diagnostic, non-extensible) and CID 7457 (M, F, extensible) to include gender?

Maybe , wait on HL7 codes

 

Add to Part 17, Use of Patient Sex and Gender, and transition considerations

 

Annex AZ Patient SEX and gender, Use and transition considerations

 

  1. When patient s ex is M and gender is M, or F and F, there are probably no comments.
  2. Patient matching rules.  How do these change? What other query issues arise?
    1. Should we recommend that when gender is missing use sex.
    2.  
  3. Australia strongly discourages use of sex for identification purposes.  Only gender is to be used. Confidentiality discussion need in this section .
  4. How [rjh8] to deal interpret or populate with old medical records recorded p rior to new policy ?
  5. How to interoperate between systems using the older information model and systems using the newer information model?
  6. How to deal with patient sex and gender values that change over time.

Especially worklist and modality upgrade mismatch.   Worklist updated, modality old, RIS/PACS/EHR updated.

Especially query

Vendors be prepared for three behaviors requested by customers:

Update both sex [rjh9] and gender to reflect the most recent values .  (Treat both like patient name).

Update only gender, retaining original sex value.  ( Treat gender li ke name, and sex like weight.)

Do not update sex or gender to reflect changes. (Treat both like weight.)

The policy may be to add a gender when it was not present in the old re cord.

The policy may be to keep gender missing.

This decision will made by the clinicians and medical records practices, not by DICOM.

Especially worklist and modality upgrade mismatch.   Worklist updated, modality old, RIS/PACS/EHR updated.

Especially query

<what about importing foreign records?>

  1. What is the use of sex/gender on ID document, why doesn’t it matter to DICOM.

AZ.5 Workflow Examples

The following examples are for a Patient (John Smith) who is has a sex of “female”, a gender of “male” and whose previous records are for studies performed when his gender was “female”.  He is still registered in the hospital record system with his old name of “Janet Smith”.   He has not updated his records to reflect a new name.

AZ.5.1 Arrival and check-in:

 

<Scenario 1, pick a scenario at next meeting/tcon>

  1. When John arrives at the waiting room for a PET/CT examination he announces himself as “John”.
  2. The clerk asks “John Williams?”, seeing a John Williams in the current worklist.  (This example assumes that the DICOM worklist is being used. Similar scenarios apply when HL7 facilities are used.)
  3. Response, “No, Smith”
  4. The clerk asks “Date of birth”
  5. Mr. Smith: “month, day, year”
  6. The clerk performs a date of birth based lookup and finds:
    1. A DICOM worklist entry for Janet Smith, with Patient’s Sex (0010,0040) “F” and Patient’s Gender (0010,xxxx) “M”, and with a Gender/Sex Comment (0010,xxx1) “Preferred name is John”.
    2. The birth dates match
  7. The clerk asks the necessary sex related preparation questions, e.g., most recent menstruation; and checks in the patient.
  8. Based on clinic policies, the clerk asks whether John wants to go through the name change process at the clinic to reflect his preferred name.

<Scenario 2>

  1. John arrives at the waiting room for a PET/CT examination , and goes to the clerk to check in.
  2. The clerk asks “Date of birth”
  3. Mr. Smith: “month, day, year”
  4. The clerk performs a date of birth based lookup and finds:
    1. A DICOM worklist entry for Janet Smith, with Patient’s Sex (0010,0040) “F” and Patient’s Gender (0010,xxxx) “M”, and with a Gender/Sex Comment (0010,xxx1) “Preferred name is John”.
    2. The birth dates match
    3. The clerk sees John, who appears to be a man, and re- checks the worklist entry.  This time notic ing   P atient’s Gender (0010,xxxx) “M” and a Gender/Sex Comment (0010,xxx1) “Preferred name is John” .  
    4. The clerk confirms “John Smith? Here for a PET/CT exam?”
    5. John agrees.
  5. The clerk asks the necessary sex related preparation questions, e.g., most recent menstruation; and checks in the patient.
  6. Based on clinic policies, the clerk asks whether John wants to go through the name change process at the clinic to reflect his preferred name.

 

AZ.5.2 Patient Preparation

  1. The prep staff checks their worklist for John, and finds the order for “Janet Smith”, Patient’s Sex (0010,0040) “F” and Patient’s Gender (0010,xxxx) “M”, and with a Gender/Sex Comment Preferred Form of Address (0010,xxx 2 1 ) “ Preferred name is   John”.   Sex Comment (0010,xxx 1) contains “Hormonal treatment causes Thrombosis risk”. [rjh10]
  2. The prep staff sets up John’s radiation protection for a female body, confirms menstruation and pregnancy status, and reconfirms birthdate.

 

AZ.5.3 Examination

  1. The technician has checked John’s worklist entry and knows to expect a female body for John this does not trigger a wrong patient concern.  The technician confirms birthdate and other ID for the patient.
  2. The exam is performed.
  3. The study results and RDSR are stored into the archive

AZ. 5.4. Recovery

Recovery nurse monitors for thrombosis using the thrombosis risk pr otocol rather than the normal protocol.

AZ.5. 5 4 Analysis

  1. The application computing SUV to generate results uses the sex “F”.  It notes the Patient’s Gender (0010,xxxx) “M” and presence of     Gender/ Sex Comment (0010,xxx1), and shows a pop-up to confirm that this is the correct value to use.
  2. The RDSR is used to prepare a patient dose report.  Because the Patient Sex (0010,0040) is F, the female body models are used for dose analysis for John.
  3. Gender comment for patient gender “M”, sex “F”, transvaginal ultrasound order, gender comment <something> to avoid humiliation during checkin, prep, etc.   Perhaps around gowning and calling for patient.

 

Add to Part 18, Table 10.6.3-3

<add gender, can’t be required but can be optional>

 

Part 20, Changes are postponed until HL7 completes their CDA work, and WG-20 determines the needed changes.

 

Add to Part 21, Does AIM differentiate? No changes needed according to David Clunie.

 

Update Supplement 202, Real Time Video, which will be Part 22.  <necessary?>

 

Update Supplement 209, DCS Conformance <necessary?>

E.g., Australia privacy regulations require justification for maintaining sex information in records.  Will this be part of a conformance statement from DICOM, or just something put in by the vendor?

Is this covered by having a section in the DCS for other regulations that are also complied with, e.g., GDPR, DIN, and UL?

 


[rjh1] Move all but attribute name to C.7.1.1.1.y.  Make changes to all subsequent tables as appropriate.

[rjh2] Put this into C.7.1.1.1.y and word it properly, not colloquially.

 

We need clinician input to provide a reasonably full list of situations, worded so that the clinicians who fill this field make consistent and appropriate choices.  These are clinical choices that must meet the needs of clinicial users of this field.  (Make sure that clinical users agree that these meets their specific needs.)

[rjh3] Is combined or separate a better choice?  Discuss.

[rjh4] Revise when HL7 has recommendations

[rjh5] Add reference

[rjh6] Really needed? Reduces K anonymization

[rjh7] Really needed? Reduces K anonymization

[rjh8] Wim volunteers

[rjh9] Note that empty ((type 2) does not mean other.

[rjh10] Reflect throughout