Stream: V2
Topic: QPD-3 Segment
Jake Aitchison (Feb 16 2022 at 10:25):
example:
QPD|IHE PDQ Query|20220215130712|@PID.5.2^fname~@PID.7.1^20220202~@PID.8^M|||||^^^IHEFACILITY&1.3.6.1.4.1.21367.3000.1.6&ISO~^^^IHEBLUE&1.3.6.1.4.1.21367.13.20.3000&ISO
Is this valid from what I understand QPD-3 is not repeatable.
if you wanted to provide multiple QPD-3 would that mean you should include multiple QPD segments?
@Frank Oemig or others?
Craig Newman (Feb 16 2022 at 13:24):
I will admit to not knowing much about the IHE specs, but in general, it appears that QPD-3 (and subsequent fields) can be defined as repeating in a query profile (from Chapter 5 of v2.9):
The client data is presented as a sequence of HL7 fields. Beginning at QPD-3-User parameters, the remaining fields of the QPD segment carry user parameter data. Each QPD user parameter field corresponds to one parameter defined in the Query Profile, where each name, type, optionality, and repetition of each parameter has been specified
So it appears that in a query profile, the parameter can be defined as repeating.
IHE seems to do something completely different (at least in the spec I found at https://profiles.ihe.net/ITI/TF/Volume2/ITI-22.html#3.22). They seem to put all of their parameters into a repeating instance of QPD-3 (as opposed to different parameters per QPD field):
QPD-3-Demographics and Visit-Related Fields consists of one or more repetitions, each of which contains two components that together contain the name and value of a distinct parameter to the query.
The only other QPD profile I've seen is from Immunizations where they are more in line with what the base standard says. They do define QPD-3 as the patient ID and allow it to repeat. But that profile is built specifically for their use case(s).
René Spronk (Feb 16 2022 at 13:31):
QPD-3 and higher (by design) offer total flexibility - as such the IHE usage is perfectly OK.
Jake Aitchison (Feb 16 2022 at 13:35):
@Craig Newman , @René Spronk Thank you, it wasn't super obvious as the usual tables which normally indicate repeatability having nothing.
I saw this also, which suggests cardinality of [0..1].
http://www.hl7.eu/refactored/segQPD.html
image.png
Craig Newman (Feb 16 2022 at 13:36):
I'll argue that because the base standard says " Each QPD user parameter field corresponds to one parameter defined in the Query Profile" that the IHE approach is a bit off standard, but does offer a lot of flexibility in terms of sending data (don't have to specify a field for each parameter), but it doesn't have limitations in terms of sending multiple patient ids and such as you can't link occurrences in QPD-3 into groups of related values (ie, the ID and the assigning authority) if you send multiple of a single parameter type.
Craig Newman (Feb 16 2022 at 13:38):
@Jake Aitchison I think that site inherits that information from the v2.9 standard, where the RP/# column isn't populated (so it defaults to a max cardinality of 1), but given the text for QPD-3, I think the intent was that it could potentially be defined as repeating in the Query profile.
René Spronk (Feb 16 2022 at 13:39):
Agree that this is probably a glitch in the publication of v2.x
René Spronk (Feb 16 2022 at 13:42):
Remember: the word version of HL7 v2 is authoritative/normative, any other v2 publications are derived/informative only.
Jake Aitchison (Feb 16 2022 at 14:10):
@Craig Newman @René Spronk maybe the hl7 access database which was probably used to generate those tables should be updated to have cardinality of [0..0] or whatever represents 0 or more maybe its [0..]
@Frank Oemig does this feel like a possible mdb amendment?
Frank Oemig (Feb 16 2022 at 16:43):
Well, QPD-3 does not repeat. Instead the field "repeats", i.e. it occurs as QPD-3, -4, -5 etc.
In the db the segment is marked as "last field repeats".
Technically the question arises how an XML Schema should look like? Do we want to generate a few more fields?...
Frank Oemig (Feb 16 2022 at 16:44):
Btw, a few segments have this behavior.
Craig Newman (Feb 16 2022 at 18:55):
@Frank Oemig what do you make of the text "Each QPD user parameter field corresponds to one parameter defined in the Query Profile, where each name, type, optionality, and repetition of each parameter has been specified". To me this implies that the fields from QPD-3 on, can be defined as repeating, otherwise "repetition" would need to be included in this list if it was constrained to 1 occurrence.
Frank Oemig (Feb 16 2022 at 19:09):
QPD-3 is one parameter, QPD-4 another, etc. Repetitions does not make sense if there is no specification how to combine them: and, or, ..
Craig Newman (Feb 16 2022 at 20:07):
Base standard seems to default to "and" with a caveat:
"While these parameters are understood to be usually "anded" together, the user SHALL inspect the required Query Profile to properly understand each. "
René Spronk (Feb 17 2022 at 07:30):
The spirit of QPD-3 etc. is 'do as you please' in derived profiles. IHE has a use-case whereby they don't know at design time how many parameters, and what parameters, will be used. The use of a repeating QPD-3 is a good solution to their use case.
Jake Aitchison (Feb 17 2022 at 08:33):
What's the closest to "official" answer then? :smile:
If it is "do as you please" should the cardinality be updated to 0 or more? that would seem to suggest the flexibility of "do as you please"
René Spronk (Feb 17 2022 at 14:11):
Given that some of the HL7v2 'old-hands' disagree, this'll need to go to the InM committee within HL7, for them to resolve this, and amend the standard to clarify. @Anthony(Tony) Julian @Nick Radov @Nick Radov
Nick Radov (Feb 17 2022 at 16:27):
René Spronk said:
Given that some of the HL7v2 'old-hands' disagree, this'll need to go to the InM committee within HL7, for them to resolve this, and amend the standard to clarify. Anthony(Tony) Julian Nick Radov Nick Radov
I think there are actually defects in both HL7 V2 Chapter 5 and IHE ITI-22. My interpretation is that QPD-3 should be a repeating field in order to align with the narrative definition because a Query Profile can allow repetitions for a user parameter field. So I created new Jira issue V2-25343 to fix that. @Anthony(Tony) Julian could you add that to the next InM conference call agenda?
However, each QPD-3, 4, ..., n field is only supposed to be used for a single user parameter field. It appears that IHE has misunderstood the specification and jammed multiple different user parameter fields together all in QPD-3 repetitions. That was not appropriate. I am no longer actively involved in IHE so can someone else submit a formal Change Proposal to fix that?
Nick Radov (Feb 17 2022 at 17:10):
Frank Oemig said:
Well, QPD-3 does not repeat. Instead the field "repeats", i.e. it occurs as QPD-3, -4, -5 etc.
In the db the segment is marked as "last field repeats".
Technically the question arises how an XML Schema should look like? Do we want to generate a few more fields?...
For the HL7 V2 XML encoding I don't think we can reasonably accommodate a variable number of QPD fields within the informative XML Schema files. Instead we should just set the expectation that Query Profile authors need to define their own custom QPD XML Schema based on the number and type of user parameter fields they want to support. As a practical matter I'm not aware of any implementers who are actually using that segment with the XML encoding, so it might be a moot issue.
Anthony(Tony) Julian (Feb 17 2022 at 20:15):
Riki?
Tony Julian
Vassil Peytchev (Feb 17 2022 at 22:41):
However, each QPD-3, 4, ..., n field is only supposed to be used for a single user parameter field.
And when that single user parameter field is "patient demographics", and it is defined as repeating field, and the data type is QIP, what exactly is there to change?
Nick Radov (Feb 17 2022 at 23:21):
Vassil Peytchev said:
However, each QPD-3, 4, ..., n field is only supposed to be used for a single user parameter field.
And when that single user parameter field is "patient demographics", and it is defined as repeating field, and the data type is QIP, what exactly is there to change?
The way I interpret the intent of HL7 V2 chapter 5 it's not really ideal for all patient demographics to be in a single user parameter field. It seems like each patient demographic data element ought to be a separate parameter. But the specification is ambiguous on that point.
Ioannis Petrakis (Feb 18 2022 at 07:28):
Hi,
I have evaluated this also with IHE tools and it is successful with repeatable QPD-3 as you can see here:
https://gazelle.ihe.net/EVSClient/hl7v2Result.seam?&oid=1.3.6.1.4.1.12559.11.1.2.1.4.1664549
Also, based on the IHE TF (https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev10.0_Vol2a_FT_2013-09-27.pdf) it should be. It defines for ITI-21 transaction that:
"Field QPD-3-Demographics Fields consists of one or more repetitions, each of which contains
two components that together contain the name and value of a distinct parameter to the query. "
Anthony(Tony) Julian (Mar 01 2022 at 17:07):
InM Invites all interested parties to the next teleconference scheduled for March 8, 2022 at 11:00 Eastern. https://hl7-org.zoom.us/j/3910526094?pwd=QzVuZTJYc2s2S0dUcVpWR3VLNm9tQT09
René Spronk (Mar 04 2022 at 07:34):
I have a conflicting meeting, allow me to state my position on this forum:
In the 'Query By Simple Parameter' variation of v2 queries (see section 5.2.5), each parameter is assigned to a different field in QPD (QPD 3,4, etc). These parameters express a logical AND between the various parameters. However, there is a common use case for ANDing parameters whilst (ORing parameter values per parameter), as is also reflected by FHIR e.g. supporting Observation?code=123,765,222&patient.name=Smith,Jones. Allowing QPD-3,4,etc. to repeat would support this logic.
This has the side effect of formally allowing what IHE is doing in its 'QSC-variant' query.
Frank Oemig (Mar 04 2022 at 20:32):
So the ORing has a stronger relationship, as being in patenthesis
René Spronk (Mar 05 2022 at 12:25):
If one has a repeating QPD-x field, the intent will probably be that these values should be ORed (if we were to look at the FHIR searches as an example). But this can be left to a query conformance statement, it could define whether AND or OR logic should apply to repeating values.
Anthony(Tony) Julian (Mar 07 2022 at 14:41):
Noted: Will be discussed march 8, 2022 at 11:00 Eastern.
Above comments have been added to https://confluence.hl7.org/pages/viewpage.action?pageId=94634524.
Anthony(Tony) Julian (Mar 08 2022 at 16:46):
The image depicts the first change relative to this to be proposed for v2+
image.png
Anthony(Tony) Julian (Mar 08 2022 at 16:47):
Vassil will craft a further explanation of the use cases - approx 12Apr2022
Last updated: Apr 12 2022 at 19:14 UTC
