Uploaded image for project: 'Other Specification Feedback'
  1. Other Specification Feedback
  2. OTHER-2604

Remove non-HL7 ballot questions

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • Cross Paradigm Gender Harmony - Sex and Gender Representation (OTHER)
    • 1.0.0-ballot
    • Terminology Infrastructure
    • DICOM PET Scan Use Case
    • 5.2
    • Hide

      Remove the following text from fhir-gender-harmony/main/input/pagecontent/dicom_use_case.md:

      ### Note to Balloters Public comment, based on this use case is sought on the following Open Issues: 1. Technologist may be in a position to observe a discrepancy between the current medical record and “observed” information. Where and how is this communicated to other actors? Where and how is reconciliation performed? Considerations include: 1. Authoritative sources of observations 2. Official systems of record 3. See also IHE (Integrating the Healthcare Enterprise) [Scheduled Workflow 34.4.2.2 Use Case \#2: Patient Update](https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf#page=276) in which upstream systems (ADT / RIS) perform a patient update or merge. 2. What imaging activities are effected by the discrepant observation, and how should those be handled prior to reconciliation (e.g. protocol selection, post processing, report content)? 3. In the cross-community scenario: 1. How to manage the case if one jurisdiction does not recognize the sex/gender attributes of another? 2. What impact will the patient name change have on the Master Patient Index weighting of search results? 3. Is this likely to require a manual merge of records? [(see IHE ITI-30)](https://profiles.ihe.net/ITI/TF/Volume2/ITI-30.html#3.30.5) 4. A mix of upgraded and non-upgraded systems may result in a scenario in which one system, does not recognize sex attributes of the other. Priors are likely generated by non-upgraded systems. Search reliability may be negatively impacted when there is discrepant information (patient situation change, attributes within records have changed). How is this handled? 5. How does this change in an encounter-based activity? Consider direct in-person clinical care vs tele health? 6. How to deal with the non-communicative patient? 7. Some machine-based algorithms are tuned based on patient age and sex at birth for the application of established reference values. How should this be considered? 8. Are there updates that should be considered for the DICOM attribute, Confidentiality constraint on patient data (0040,3001) VR=LO, to support local confidentiality approaches that may be applied to transgender demographics changes? 9. Should name to use be PN or LT VR? A patient, may want to be referred to as “Commander Bob”. 10. In this Use Case, a single ADT message is created to communicate the patient name change. Is the order of the repeating elements in PID-5 significant? Should there be one ADT message or two (i.e. one message to communicate the new name, a second message to flag the old name as "NOUSE")?

      Show
      Remove the following text from fhir-gender-harmony/main/input/pagecontent/dicom_use_case.md: ### Note to Balloters Public comment, based on this use case is sought on the following Open Issues: 1. Technologist may be in a position to observe a discrepancy between the current medical record and “observed” information. Where and how is this communicated to other actors? Where and how is reconciliation performed? Considerations include: 1. Authoritative sources of observations 2. Official systems of record 3. See also IHE (Integrating the Healthcare Enterprise)  [Scheduled Workflow 34.4.2.2 Use Case \#2: Patient Update] ( https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf#page=276 ) in which upstream systems (ADT / RIS) perform a patient update or merge. 2. What imaging activities are effected by the discrepant observation, and how should those be handled prior to reconciliation (e.g. protocol selection, post processing, report content)? 3. In the cross-community scenario: 1. How to manage the case if one jurisdiction does not recognize the sex/gender attributes of another? 2. What impact will the patient name change have on the Master Patient Index weighting of search results? 3. Is this likely to require a manual merge of records?  [(see IHE ITI-30)] ( https://profiles.ihe.net/ITI/TF/Volume2/ITI-30.html#3.30.5 ) 4. A mix of upgraded and non-upgraded systems may result in a scenario in which one system, does not recognize sex attributes of the other. Priors are likely generated by non-upgraded systems. Search reliability may be negatively impacted when there is discrepant information (patient situation change, attributes within records have changed). How is this handled? 5. How does this change in an encounter-based activity? Consider direct in-person clinical care vs tele health? 6. How to deal with the non-communicative patient? 7. Some machine-based algorithms are tuned based on patient age and sex at birth for the application of established reference values. How should this be considered? 8. Are there updates that should be considered for the DICOM attribute, Confidentiality constraint on patient data (0040,3001) VR=LO, to support local confidentiality approaches that may be applied to transgender demographics changes? 9. Should name to use be PN or LT VR? A patient, may want to be referred to as “Commander Bob”. 10. In this Use Case, a single ADT message is created to communicate the patient name change. Is the order of the repeating elements in PID-5 significant? Should there be one ADT message or two (i.e. one message to communicate the new name, a second message to flag the old name as "NOUSE")?
    • Rob Horn / Steve Nichols : 11-0-2
    • Clarification
    • Non-substantive

      "

      (Comment 46 - imported by: Lloyd McKenzie)

            Unassigned Unassigned
            Rongparker Ron G. Parker
            Steven Nichols
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: