Difference between revisions of "Extended PDQ - Discussion"

From IHE Wiki
Jump to navigation Jump to search
Line 46: Line 46:
 
'''Other Open Issues'''
 
'''Other Open Issues'''
  
 +
# Include HITSP required NVAC fields?
 
# 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?
 
# 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?
 
# It gets confusing that when talking about PIX and PDQ together, the same system is the "supplier" sometimes and the "consumer" or "manager" at others.  We have occasionally used the word "source" system to mean the system originating the data and sending it.  Is this okay?
 
# It gets confusing that when talking about PIX and PDQ together, the same system is the "supplier" sometimes and the "consumer" or "manager" at others.  We have occasionally used the word "source" system to mean the system originating the data and sending it.  Is this okay?

Revision as of 12:06, 21 May 2008

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.

  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.

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:

  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

The current draft takes the last approach.

  1. PDO uses ITI-30, which includes all six fields, which are available in the HL7 V2.5 PID segment.
  2. Changes to ITI-21 parallel the way the current list of search fields are handled.
  3. 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).
  4. Version 3 Volume 2 changes include only Mother's Maiden Name and Home Telephone in the Patient Demographics Query search fields.
  5. 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

  1. Include HITSP required NVAC fields?
  2. 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?
  3. It gets confusing that when talking about PIX and PDQ together, the same system is the "supplier" sometimes and the "consumer" or "manager" at others. We have occasionally used the word "source" system to mean the system originating the data and sending it. Is this okay?
  4. Double check that PIX Update Notification and PAM do not need to be included in PDO.
  5. Not totally sure what properly goes in introduction vs. summary vs. open and closed issues.
  6. 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?
  7. How to specify edits to RMIMs and HMDs?
  8. Drill down on usage of PatientTelecom. Should email be included (why not?)
  9. Will we need new message examples and ITI Templates?
  10. 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. 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. This way, we are not requiring parsing changes in order to implement the PDO supplement, yet we are getting most of the benefit. 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. The name of the profile has been changed to Pediatric Demographics Option (PDO).
  3. Karen Witting has been added as an author and Sandy Thames dropped.
  4. A change proposal has been written to change the name of ITI-30 from "Patient Identity Feed" to "Patient Identity Feed - 2.5" to distinguish it from ITI-8 "Patient Identity Feed".
  5. ITI-30 is added as an optional transaction to PIX as part of this supplement. Essentially, this adds an HL7 V2.5-based Patient Identity Feed option to PIX. Previously, PIX had only 2.3.1-based and 3.0-based Patient Identity Feed transactions. ITI-30 was formerly associated with PAM, not PIX.


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