Extended PDQ - Discussion

From IHE Wiki
Jump to navigation Jump to search

Introduction



Open Issues

  1. Where in the Control Act Wrapper exactly are the Last Update Date/Time and Facility?
  2. Should we write stronger language for conformance when using Version 3 related to the requirement of the source system to send those 2 fields? This language may need more detail to explain how the fields are to be used in the Patient Identity Feed, the Patient Demographics Query, and the Patient Demographics Query Response (i.e. detail the fields).
  3. Numerous errors noticed in the present PIX/PDQ V3 document:
    1. Section 2.2 p. 11 line 240 Why is table labeled "X.2-1"? Carry-over from template use?
    2. Why would LivingSubjectName Parameter state "only certain name parts within teh PN data type (e.g. family name) may be specified"? 3.47 line 1755
    3. Figure 3.47.4.1.211 should be Figure 3.47.4.1.2-11?
  4. Will we need new message examples and ITI Templates?
  5. Needs one final run-through to clean up formatting, remove template artifacts, etc.

Closed Issues

  1. The final list of fields has been reduced to the following six. Other fields were eliminated when we examined the cost vs. benefit of implementing them. Father's name, Father's SSN, Mother's name and Mother's SSN require NK1 segments to be used in V2.5. Although present in ITI-30, these segments are not called out or described in the transaction specifically. It is therefore safe to assume that implementers currently complying with PIX, PDQ and ITI-30 may not parse these segments. Most of the benefit of these fields can be found in the Mother's name. Since Mother's Maiden is in the PID segment in V2.5 currently and can contain first, middle and last names, we felt that most of the benefit of these other four can be captured by Mother's Maiden, at much less potential cost to implementers. We felt this approach had a much greater likelihood of update. Another original field, Birth State, has more to do with finding information across state lines than identification of a single patient. Thus it was felt that this is more like location information than demographic information.
    1. Patient Home Telephone - used to get into the right household for the patient
    2. Patient Multiple Birth Indicator - used to distinguish records for twins. For children, often records for twins have similar demographics, which can result in a false match.
    3. Patient Birth Order - used to distinguish records for twins.
    4. Last Update Date/Time - used to distinguish records for twins. Last Update fields are a "trick" that is used when multiple birth indicator/birth order is not explicitly collected. Twins are usually brought for doctor visits to the same place on the same day but records are stamped with
    5. Last Update Facility - used to distinguish records for twins.
    6. Mother’s Maiden Name - For a child, mother's name provides high quality matching data. First name is as useful as last name (what is usually thought of as maiden name).
  2. We decided to allow email in the V3 PatientTelecom field (Patient Home Telephone).
  3. It became clear that our six pediatric demographic fields really can be grouped into three categories, according to which transactions transactions they are used in and how they are used.
    1. Patient Home Telephone - used in Patient Demographics Query and response, and in Patient Identity Feed and PIX Update.
    2. Mother’s Maiden Name - used in Patient Demographics Query and response, and in Patient Identity Feed and PIX Update.
    3. Patient Multiple Birth Indicator - used only in in response to PDQ, and in Patient Identity Feed and PIX Update.
    4. Patient Birth Order - used only in in response to PDQ, and in Patient Identity Feed and PIX Update.
    5. Last Update Date/Time - used as an oblique substitute for Multiple Birth Indicator/Birth Order, but really are message wrapper fields.
    6. Last Update Facility - used as an oblique substitute for Multiple Birth Indicator/Birth Order, but really are message wrapper fields.
    • In the IHE May ITI Face-to-Face, three alternative approaches to resolving HL7 V2-V3 technology differences in listing PDQ query fields were identified:
    1. Revisit HL7 V3 RMIM to allow more fields
    2. Drop some fields from V2 query requirement
    3. Slightly different solutions appropriate to different technologies
    • A first draft took the latter approach but in the end we decided upon the second approach as more consistent with the theory of the solution and more clear. Appropriate changes to Volume 1 and Volume 2 were made to reflect this.
  4. A corollary issue was whether to have a conformance point (option) on the Patient Demographics Consumer to be able to supply the resulting two search fields in a Patient Demographics Query. We decided to remove this option, but there were dissenting opinions. We ask for public comment on this issue.
  5. We discussed HITSP requirements to include NVAC required and optional fields and AIRA codesets. We decided to forward both the PCC Immunization Content Profile as well as the Pediatric Demographics Option to HITSP. The former defines data for exchange (tracking). The latter defines data for identity management. Between the two, the entire NVAC list (required and option) should be covered (we will double-check). The alternative proposal was to include at least all NVAC required fields in PDO. This would mean adding Patient Birth State and Mother's Last Name back in to PDO. In the end, we couldn’t see asking implementers to add fields to matching algorithms for which a case for necessity in matching can’t be clearly made; so instead, we will cover the required and optional NVAC fields between the two IHE profiles. We will specifically forward the IHE documents for public comment to HITSP when they are ready in June, to give them an opportunity to comment further.


Links

Original profile proposal from 2007 planning period - Extended PDQ
Pediatric Demographics Option (PDO) working documents

Discussion


Final Fields List


  1. We propose that four of the original ten search fields that were part of the original profile proposal be dropped and one field added to replace them to accomplish the same effect. This is because addition of the four fields in question would require new segments to be added to various transactions while the substitute field, while accomplishing essentially the same work, would not. The ten original fields are:
    1. Patient Home Telephone
    2. Patient Birth State
    3. Patient Multiple Birth Indicator
    4. Patient Birth Order
    5. Last Update Date/Time
    6. Last Update Facility
    7. Mother’s Name
    8. Mother’s SSN
    9. Father’s Name
    10. Father’s SSN


These were taken from the CDC/AIRA Implementation Guide.

However, we discovered that the last four fields would change the transactions ITI-30 and ITI-21 substantially by requiring the use of segments not currently described in the transactions. To avoid this complication, Mothers Maiden Name is proposed as a substitute for the last four fields. This field is readily available in the PID segment in V2.5 and also is available in V3. As loading of birth records has become more common in recent years in immunization registries and other public health databases, we find that Mother's Maiden Name is more commonly available than it was when the CDC/AIRA Implementation Guide was first written and can serve the same distinguishing purpose that the four originally proposed Mother's and Father's fields would have served. This approach will make the supplement more implementable.

Finally, we wish to also winnow Birth State from the list as not having as clear a value as the other fields. It was felt that this was more like location information than demographic information.

So, the final list of fields would include:

  1. Patient Home Telephone
  2. Patient Multiple Birth Indicator
  3. Patient Birth Order
  4. Last Update Date/Time
  5. Last Update Facility
  6. Mother’s Maiden Name


Mar Face to Face


  1. In Patient Identity Feed, if you have any of the 15 fields (6 base traits plus 9 extended traits) then send them. Manager is required to deal with them if they receive them. Draw on “best fit” language from the CP.
  2. Karen will write a CP to change ITI-30 to “Patient Identity Feed – 2.5”. Right now there are two separate transactions in Vol 2 called “Patient Identity Feed” – ITI-8 and ITI-30. ITI-30 is HL7 V2.5-based where ITI-8 is V2.3-based.
  3. In this supplement, we will add ITI-30 and the Patient Demographic Supplier actor to PIX.
  4. In V3, we can draw on the Control Act for the last update date/time fields.
  5. Also realize in PIX that you have to support all 15 fields in matching. This will require adding the “best fit” language to Patient Identity Feed (ITI-30) as “best fit” is currently part of Patient Demographics Query.
  6. Karen is interested in being added as an author on this profile.


Nov 7-8 Face to Face


Extended PDQ discussion

Return to ITI Technical Committee

Retrieved from "http://wiki.ihe.net/index.php?title=Extended_PDQ_-_Discussion&oldid=20031"