Extended PDQ - Discussion
Introduction
Open Issue - Field Usage in V3
It has become 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.
- Patient Home Telephone - used in Patient Demographics Query and response, and in Patient Identity Feed and PIX Update.
- Mother’s Maiden Name - used in Patient Demographics Query and response, and in Patient Identity Feed and PIX Update.
- Patient Multiple Birth Indicator - used only in in response to PDQ, and in Patient Identity Feed and PIX Update.
- Patient Birth Order - used only in in response to PDQ, and in Patient Identity Feed and PIX Update.
- Last Update Date/Time - used as an oblique substitute for Multiple Birth Indicator/Birth Order, but really are message wrapper fields.
- Last Update Facility - used as an oblique substitute for Multiple Birth Indicator/Birth Order, but really are message wrapper fields.
The Volume 2 changes do not really require this distinction to be made, because it is not made with the present language or list of fields required by PDQ to be supported. I.e. nowhere is it spelled out that to support matching against required fields, that the required fields have to be supplied in the first place by Patient Identity Feed. Further, an HL7 Version 2 PID segment includes Last Update Date/Time and Last Update Facility, even though these seem like wrapper fields.
In working through the V3 Vol 2 sections, it became clear that V3 will enforce this distinction. This is because the V3 Patient Registry Find Candidates Query RMIM does not include Multiple Birth Indicator or Birth Order. Also, V3 properly puts Last Update Date/Time and Last Update Facility in the Control Act Wrapper.
We are trying to decide how to handle this. See the proposed Volume 2 change for Version 2 in the current draft. The equivalent of this change is not even possible in Version 3 due to the fact that V3 enforces the breakdown of fields into the above mentioned category, and also because the equivalent in the V3 supplement text to the V2 language:
The Patient Demographics Consumer may specify, and the Patient Demographics Supplier shall support ... (fields from the following table).
is not really present. Instead, V3 specifies (under 3.47.1.3.2 Query Parameter Processing:
The patient Demographics Supplier Actor shall be capable of accepting, searching on, and responding with attributes in the Query Person by Demographics message. ... The Supplier shall return at least all exact matches to the query parameters sent by the Consumer; IHE does not further specify matching requirements, except as already discussed in the LivingSubjectName parameter description.
V3 also does not appear to include "ANDed together" language. (This is replaced by "best fit" language in CP 277. At this writing, CP 277 does also modify the Version 3 Supplement of PIX/PDQ.)
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:
- Revisit HL7 V3 RMIM to allow more fields
- Drop some fields from V2 query requirement
- Slightly different solutions appropriate to different technologies
The current draft takes the last approach.
- PDO uses ITI-30, which includes all six fields, which are available in the HL7 V2.5 PID segment.
- Changes to ITI-21 parallel the way the current list of search fields are handled.
- PDO uses ITI-30 instead of ITI-8 to take advantage of the presence of all needed fields in HL7 V2.5 (ITI-8 is V2.3-based).
- Version 3 Volume 2 changes include only Mother's Maiden Name and Home Telephone in the Patient Demographics Query search fields.
- Version 3 Volume 1 clearly specifies that all six fields will be included in the Patient Identity Feed, the Patient Demographics Query. 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).
Other Open Issues
- Where in the Control Act Wrapper exactly are the Last Update Date/Time and Facility? Should we write stronger language for conformance when using Version 3 related to the requirement of the source system to send those 2 fields?
- We have occasionally used the word "source" system to mean the system originating the data and sending it. Is this okay?
- Double check that PIX Update Notification and PAM do not need to be included in PDO.
- Numerous errors noticed in the present PIX/PDQ V3 document:
- Section 2.2 p. 11 line 240 Why is table labeled "X.2-1"? Carry-over from template use?
- 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
- Figure 3.47.4.1.211 should be Figure 3.47.4.1.2-11?
- Will we need new message examples and ITI Templates?
- Needs one final run-through to clean up formatting, remove template artifacts, etc.
Closed Issues
- We discussed HITSP requirements to include NVAC required and optional fields and AIRA codesets.
- 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.
- Patient Home Telephone - used to get into the right household for the patient
- 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.
- Patient Birth Order - used to distinguish records for twins.
- 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
- Last Update Facility - used to distinguish records for twins.
- 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).
- We decided to allow email in the V3 PatientTelecom field (Patient Home Telephone).
Links
Original profile proposal from 2007 planning period - Extended PDQ
Pediatric Demographics Option (PDO) working documents
Discussion
Final Fields List
- 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:
- Patient Home Telephone
- Patient Birth State
- Patient Multiple Birth Indicator
- Patient Birth Order
- Last Update Date/Time
- Last Update Facility
- Mother’s Name
- Mother’s SSN
- Father’s Name
- 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:
- Patient Home Telephone
- Patient Multiple Birth Indicator
- Patient Birth Order
- Last Update Date/Time
- Last Update Facility
- Mother’s Maiden Name
Mar Face to Face
- 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.
- 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.
- In this supplement, we will add ITI-30 and the Patient Demographic Supplier actor to PIX.
- In V3, we can draw on the Control Act for the last update date/time fields.
- 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.
- Karen is interested in being added as an author on this profile.