ihe / iti.pdqm Goto Github PK

• Update PDQm as found in the Technical Framework path on profiles.ihe.net to point at the IG publisher version rather than PDF
• Replace PDF with IG publisher
• tag as TI
• update Appendix M.4 table reference to PDQm

The following text appears here http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#2378422-message-semantics but also elsewhere.

"See ITI TF-2:Appendix Z.7 for handling guidance for Access Denied."

How about this instead: "See ITI TF-2: Appendix Z.7 for guidance on Access Denied."

Section Number Figure 38.6-1

Issue Figure 38.6-2 is missing

Proposed Change *
The last sentence of Cross-Profile considerations reads, "The Patient Demographics Supplier may act as a proxy to an existing PDQ or PDQv3 environment as shown in Figures 38.6-1 and 38.6-2."

Figure 38.6-2 referred to in that sentence exists in the PDF but not in this IG.

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number https://profiles.ihe.net/ITI/PDQm/actor_options.html#13821-pediatric-demographics-option-- and message semantics in ITI-78

Issue let's improve how the PDO option is documented, both in Vol 1 and Vol 2

Proposed Change
See change tracked suggestions attached below

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

PDQm adds a subsection to Vol 2 Appx M

This page, http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/appendixm.html, probably in the editor's box, should have a link to Vol 2 Appx M in html: https://profiles.ihe.net/ITI/TF/Volume2/ch-M.html

Section Number *n/a content is missing; see below

Issue The prior PDF version of PDQm contains an update to Vol 2 Appx M. See page 28 in https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PDQm_Rev2-2_TI_2020-08-28.pdf

I don't see that content here. If we decided to omit it in the IG and CP it into the Appx M, or do something else in another way, then I forgot about it.

Note that there are some inaccuracies in the tables in Appx M (eg why is date of death listed?). If we keep the content, then those should be fixed.

Proposed Change

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

From the test plan: https://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/testplan.html

ITI-78 Patient Demographics Query for Mobile
Pediatric Demographics Consumer initiates ITI-78 queries with various combinations of parameters, as supported
Pediatric Demographics Supplier responds to ITI-78 queries as appropriate

This should be "Patient" instead of "Pediatric", right?

PDQm_101: Are there some elements we can get global agreement should be marked as R2 (aka, Must-Support - required to be returned if known)?

For ease of finding the AuditEvent profiles, the Volume 1 Security Considerations section could itemize each of the AuditEvent profiles and point to their transaction specific security considerations definition.

Section Number 2:3.78.4.1.2.1 https://profiles.ihe.net/ITI/PDQm/ITI-78.html#23784121-query-search-parameters

Issue seemingly overlapping and contradictory statements; see below...

Proposed Change
In the table of query parameters, in the definition column for identifier, I read,
This repeating parameter of type token, when supplied, specifies an identifier associated with the patient whose information is being queried (e.g., a local identifier, account identifier, etc.). See ITI TF-2:Appendix Z.2.2 for use of the token data type. If multiple instances of this parameter are provided in the query, the query represents a logical AND condition (i.e., all of the associated identifiers must match). For example, a query searching for patients having identifier145 assigned by authority “1.2.3.4” and SSN 123456789 would be represented as:
?identifier=urn:oid:1.2.3.4|145&identifier=urn:oid:2.16.840.1.113883.4.1|123456789
If no system portion of the identifier parameter is specified, then the matching would be performed on any identifier regardless of issuing system. The identifier specified in this parameter is expressed using the token search parameter type. Please see ITI TF-2:Appendix Z.2.2 for use of the token data type for patient identifiers.

Later, in https://profiles.ihe.net/ITI/PDQm/ITI-78.html#23784123-parameter-modifiers, I read,
"The Patient Demographics Consumer may constrain the domains from which patient identifiers are returned from the Patient Demographics Supplier in the resulting bundle. The Patient Demographics Consumer shall convey this by specifying the patient identity domains in the system component of repeating identifier parameters using the OR format:

&identifier=urn:oid:1.2.3|,urn:oid:4.5.6|

For example, a Patient Demographics Consumer wishing to filter for patients with a last name of SMITH having identifiers from an identity domain with OID 1.2.3.4.5 would convey this search as:

?family=SMITH&identifier=urn:oid:1.2.3.4.5|

The Patient Demographics Consumer shall populate the patient identity domain portion of the token with values described in ITI TF-2:Appendix E."

ok... a logical AND condition written in logical OR format... the contents of these 2 specifications for the identifier parameter are a bit duplicative and also confusing.

I recommend removing this section https://profiles.ihe.net/ITI/PDQm/ITI-78.html#23784124-populating-which-domains-are-returned--, and making the identifier row in the query table the only place where you make rules and give examples of how the identifier parameter is used. ...if you agree to move it, then several references to this section that appear in Expected Actions would need to be updated (which may be an argument against this recommendation).

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Section Number 2: 3.78.4.1.3

Issue *clarify Case 2... there's one matching record...

Proposed Change
Case 2: The Patient Demographics Supplier finds at least one patient record matching the criteria sent in the query parameters. One or more patient identifier domains are requested via the mechanism specified in Section 3.78.4.1.2.4, and Patient Demographics Supplier recognizes all domains.

HTTP 200 (OK) is returned as the HTTP status code.

The Patient Demographics Supplier performs its matching and returns a bundle as described in Case 1. The Patient Demographics Supplier eliminates identifiers from the result set which do not exist in the list specified per Section 3.78.4.1.2.4 (domains to be returned). If all entries in the list of patient identifiers are eliminated, which would leave the patient identifiers list empty, then the entry shall not be present in the response bundle.

Delete the last sentence, right??? the beginning of the case says there is at least one matching record

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#23784121-query-search-parameters

in the identifier row, definitions column, the backslash after urn:oid:2.16.840.1.113883.4.1\ does not exist in the PDF supplement

?identifier=urn:oid:1.2.3.4|145&identifier=urn:oid:2.16.840.1.113883.4.1|123456789

Informal text on the home page
"Click on any of the links above, head on over the table of contents, or if you are looking for a specific artifact, check out the index."

should this just be deleted? It seems this should be obvious to anyone now days.

Note this is common text in MHD, and PIXm.

2:3.78: “…[ITI-78] is used by the Client and Server Actors.” Name the actors

2:3.78.4.1.2: The link to http://hl7.org/fhir/R4/http.html is not a clickable link. Just before the Get in the brown box.

2:3.78.4.1.2.1 See http://hl7.org/fhir/R4/search.html#errors. That link is not a clickable link. Just before table.

            In the table in birthdate, there is an unclickable link.

            In the table in gender, there is an unclickable link.

            At the very bottom of this section is a link to Appendix E that does not work.

2:3.78.4.1.3 The bottom of Case 4 has an unclickable link. I point these out because at least one link to hl7.org/fhir worked, like FHIR Paging.

            Case 5: the section number in the parenthesis should be clickable.  Same with the one right after the table.

2:3.78.4.2.1 I thought it would be just receiving the query. You send the response even if you don’t find any matches.

2:3.78.4.2.2.2 Unclickable link.

2:3.78.4.2.2.5 Unclickable link.

2:3.78.4.3.1 We say this, “it issues a Retrieve Patient Resource operation.” Shouldn’t operation be message?

2:3.78.4.3.2 Section number after the Get format box is not clickable.
2:3.78.4.4 The link to section 3.78.4.2.2.1 goes to section 3.78.4.2.2
2:3.78.4.4.1 Same thing here. The trigger should be they received a request.
2:3.78.4.4.2.1 The link to section 3.78.4.2.2.1 goes to section 3.78.4.2.2. There is also an unclickable link.
2:3.78.5.1.2 There is a PIXm link that does not work.

http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#23784121-query-search-parameters

See the following in the parameters column of the table:

address-city,
address-country,
address-postalcode,
address-state

Section Number 2: 3.78.4.1.3 https://profiles.ihe.net/ITI/PDQm/ITI-78.html#2378413-expected-actions

Issue fix typo

Proposed Change
in the following sentence, change "indicate" to "indicated".
The Patient Demographics Supplier may be able to perform other string matching (e.g., case insensitive, partial matches, etc.) which shall be indicate in its CapabilityStatement Resource

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/appendixm.html

Appx M still contains "2c" references. See title of this issue.

Also, those references could have links added.

ET [base]/Patient?

In the query parameters table, identifier row, find the following text. The URL should be the link to the text IT ITF-2: Appendix Z.2.2

Please see (ITI TF-2:Appendix Z.2.2)[https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html#z.2-query-parameters] for use of the token data type for patient identifiers.

Section Number https://profiles.ihe.net/ITI/PDQm/testplan.html

Issue sometimes profile details change during public comment resolution

Proposed Change
review the contents of the Test Plan page to ensure it's still accurate after public comment is processed

also, existing content is missing tests for audit

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Given FHIR R4 mandates POST for searches, we should follow MHD lead and require both GET and POST.

Section Number 2: 3.78.4.1.3 https://profiles.ihe.net/ITI/PDQm/ITI-78.html#2378413-expected-actions.

Issue there are two possible responses to Case 4, but the Operation Outcome is only returned for the 404, right? In that case, move the alternative response after the operation outcome table.

Proposed Change
recommend to update case 4 as follows:

The Patient Demographics Supplier does not recognize one or more of the domains specified per Section 3.78.4.1.2.4.

There are two different acceptable return results.
The preferred response is a HTTP 404 to indicate that the domain is not recognized,
An OperationOutcome Resource is returned indicating that the patient identity domain is not recognized in an issue having:

Otherwise, when the Patient Demographics Supplier cannot determine that the domain is not recognized, it may return a HTTP 200 and a Resource Bundle representing the zero result set. The Patient Demographics Supplier populates the total with a value of 0 indicating no results were found. No entry attributes are provided in the result.

Priority:

• Medium

Figures 38.6-1 and 38.6-2 show the same thing in slightly different ways. The first makes the facade of the PDQm Patient Demographics Supplier and PDQ patient demographics consumer more clear, while the second makes the transaction flow in this scenario more clear. I think it would be better to combine them into a single figure.

The PDQm home page http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/index.html says "MHD uses Must Support in StructureDefinitions with the definition found in Appendix Z. This is equivalent to IHE use of R2.

Appx Z has this: https://profiles.ihe.net/ITI/TF/Volume2/ch-Z.html#z.10-profiling-conventions-for-constraints-on-fhir. R2 is defined. "Must Support" is not mentioned .

Maybe the Index should say: "MHD uses Must Support in StructureDefinitions This is equivalent to IHE use of R2 as defined in Appendix Z."

Secondarily, we should enhance Appx Z to say that R2 as defined there is equivalent to Must Support as used in FHIR.

This is not a PDQm specific issue.

http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/overview.html#1-38-4-overview contains the information about FHIR version number and the FMM level of resources used by the profile.

For consistency, where should this go in IGs published by IHE (if anywhere). (sorry if this is a duplicate)

From https://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#23784221-patient-resource-definition-in-the-context-of-query-patient-resource-response

"The Patient Resource(s) contained within the Query Patient Resource Response message should conform to Patient Profile for PDQm."

Should this "should" be a "shall"?

Section Number

1:78.5

Issue

Missing IHE IUA scopes for ITI-78. See related PIXm issue here with same proposed change:
IHE/ITI.PIXm#49

Proposed Change
IHE/ITI.PIXm#49

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number https://profiles.ihe.net/ITI/PDQm/artifacts.html#structures-resource-profiles

Issue When the Pediatric Demographics Option is supported, both the Consumer and Supplier have additional requirements. Do we need additional artifacts for this? StructureDefinition? CapabilityStatement?

Proposed Change
When a Supplier Actor supports the Pediatric Demographic Option, these attributes become "Must Support":

• mother's maiden name
• patient.telecom
  --> It seems like we need to constrain this http://hl7.org/fhir/R4/datatypes.html#ContactPoint since the Supplier is required to be able to return Patient Home Telephone
• Patient.multipleBirth http://hl7.org/fhir/R4/patient-definitions.html#Patient.multipleBirth_x_
  --> Interestingly, this can either be a boolean datatype or an integer datatype. Vol 1 https://profiles.ihe.net/ITI/PDQm/actor_options.html#13821-pediatric-demographics-option-- specifies that the Supplier shall be able to return Patient Multiple Birth Indicator and Patient Birth Order, but cardinality of this attribute is 0..1.

When a Consumer Actor supports the Pediatric Demographic Option, it shall be able to query by Mother's Maiden Name.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#2378412-message-semantics

Under ...GET [base]/Patient?... the following sentence is missing:

"This URL is configurable by the Patient Demographics Supplier and is subject to the following constraints"

Section Number https://profiles.ihe.net/ITI/PDQm/actors_and_transactions.html

Issue
PDQm points back to PDQ and PDQv3 transactions as equivalent
PDQV3 points to PDQ transaction as equivalent in Table 24.1-2 https://profiles.ihe.net/ITI/TF/Volume1/ch-24.html#24.1
PDQ has no similar info

Proposed Change
Do we make them consistent or remove this mapping?

How about just pointing to the content we moved to Appendix M? https://profiles.ihe.net/ITI/TF/Volume2/ch-M.html#M.4

When we answer this, consider making the same choice for the PIX family, and then create a traditional CP.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

Given each artifact ends up on a flat narrative on the artifacts page; the narrative for the artifact should be expressive to explain the artifact to a minimal degree. This narrative is markdown so can include markdown friendly expressions like bullet lists. (See MHD for examples).

http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#23784221-patient-resource-definition-in-the-context-of-query-patient-resource-response

This issue is not introduced by the move to IG format; it exists in the current PDF text...

See the first two sentences in the section below.

• "shown below?" We must have deleted a table at some point and deferred to FHIR.
• "detailed description of the message is provided here" Not really.

Should we remove the first 2 sentences? or?

2:3.78.4.2.2.1 Patient Resource Definition in the Context of Query Patient Resource Response

The components of the Patient Resource with cardinality greater than 0 (as shown below) are required, and the detailed description of the message is provided here. All other attributes of the response are optional. The Patient Resource contained within the Query Patient Resource Response message is described at http://hl7.org/fhir/R4/patient.html and is not further constrained by this transaction.

Section Number 1: 38.1 https://profiles.ihe.net/ITI/PDQm/actors_and_transactions.html#1-38-1-actors-and-transactions

Issue note is missing reference to PDQv3 transaction

Proposed Change
Recommend changing this:
Note 1: The transaction defined in this profile corresponds to Patient Demographics Query [ITI-21] in the PDQ Profile (ITI TF-1:8) and provides similar functionality. Note that there is no transaction which corresponds to the Patient Demographics and Visit Query [ITI-22].

To follow the pattern used for the note in the same table in PIXm, ie:
The Mobile Patient Demographics Query [ITI-78] transaction corresponds to the transactions used in the PDQ and PDQV3 Profiles (ITI TF-1: 8 and 24) and provides similar functionality. Note that there is no PDQm transaction that corresponds to the Patient Demographics and Visit Query [ITI-22] in PDQ. See ITI TF-2: Appendix M.4 (https://profiles.ihe.net/ITI/TF/Volume2/ch-M.html#M.4) for a mapping of query fields for PDQ, PDQv3, and PDQm transactions.

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

1:38.3 and 1:38.6

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

Both of these sections have identical content. Is the repetition needed?

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

I think Required Actor Groupings is typically used to indicate which actors/profiles you're required to be grouped with, which I think is none for the PDQ* profiles.

Priority: - Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number 3.78.4.2.3 https://profiles.ihe.net/ITI/PDQm/ITI-78.html#2378423-expected-actions

Issue Suggested improvements below

Proposed Change
Here is the existing text:
2:3.78.4.2.3 Expected Actions
The constraints specified in Section 3.78.4.2.2 represent the minimum set of demographics information that must be implemented by a Patient Demographics Supplier. This does not prevent the Patient Demographics Supplier from sending additional FHIR attributes in a response; such as extensions, text, etc. The Patient Demographics Consumer shall ignore additional attributes and extensions if not understood.

The consumer shall process the response in some manner specific to its application function (for example: displaying on a user interface). This application behavior is not specified by IHE. The Patient Demographics Consumer should be robust as the response may contain Patient Resources that match the query parameters but are not compliant with the PDQm constraints defined in Patient Profile for PDQm.

Here is my suggested reordering of the content
2:3.78.4.2.3 Expected Actions
The Patient Demographics Consumer shall process the response in some manner specific to its application function (for example: displaying on a user interface). This application behavior is not specified by IHE.

The constraints specified in Section 3.78.4.2.2 represent the minimum set of demographics information that must be implemented by a Patient Demographics Supplier. This does not prevent the Patient Demographics Supplier from sending additional FHIR attributes in a response that are not compliant with the PDQm constraints defined in Patient Profile for PDQm.; such as extensions, text, etc. The Patient Demographics Consumer shall ignore additional attributes and extensions if not understood.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

the contents added to MHD are a better model than PIXm

https://profiles.ihe.net/ITI/MHD/testplan.html

much more could be done, but... baby steps...

http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#2378413-expected-actions

Make Case 1: Case 2: bold font, as in the PDF. This follows a pattern for the equivalent PDQv2 and v3 transactions

In PDQm (PDF) https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_PDQm.pdf, Section 38.4 Overview starts with 38.4.1 Concepts

In the IG, http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/overview.html starts with the content from the Forward (usually content that is 'dropped' when we go from TI to FT). If a reader is going through Vol 1, s/he navigates through 3 prior pages before getting to this introductory-type text

Suggestion: Move this to the PDQm "Home" page. Or, remove the "Forward" and "Intro to this supplement" headers and keep the text here

@costateixeira has noted that the new wording in PDQm (and MHD) that has servers "shall" support both GET and POST searches does not seem to allow regions or organizations to write refining Implementation Guides that might pick one of them for their region.
I have presumed that this was allowed, but agree that it is more likely that the wording means it must always support both
Some discussion has used the escape that supporting does include always returning a 405. Don't like that solution.

Section Number n/a

Issue *The PDF that this IG replaces contains these to updates which are intended to be added to the TF when PDQm goes Final Text. These are lost in the IG. See below

Proposed Change *
Below are what was in the PDQm PDF as updates to Vol 1 Final Text. We have added some TI content with "TI" watermarks to the Appendices. We thought this need would be limited, but here is another case. I don't have another proposal, but I am leery of expanding use of the watermark TI method, but I don't have a different proposal yet...

8.6 PDQ Cross Profile Considerations
There are two additional profiles, PDQv3 (Patient Demographics Query HL7v3) and
PDQm (Patient Demographics Query for Mobile), which provide similar functionality to
Patient Demographics Query. These profiles adapt the Patient Demographics Query
transaction of the Patient Demographics Supplier and Patient Demographics Consumer
Actors for HL7v3 and HL7 FHIR. ITI TF-2x: Appendix M.4 provides additional details
about these Patient Demographics Query Profiles and their relationship with one another.

24.6 PDQv3 Cross Profile Considerations
There are two additional profiles, PDQ (Patient Demographics Query) and PDQm (Patient
Demographics Query for Mobile), which provide similar functionality to Patient
Demographics Query V3. These profiles adapt the Patient Demographics Query
transaction of the Patient Demographics Supplier and Patient Demographics Consumer
Actors for HL7v2 and HL7 FHIR. ITI TF-2x: Appendix M.4 provides additional details
about these Patient Demographics Query Profiles and their relationship with one another.

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

It was decided that Appendix E.3 and Appendix Z should be published to profiles.ihe.net despite still being in trial implementation (but designated as such with a watermarked background).

PDQm adds a section M.4 to appendix M. This is currently published as part of the IG: https://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/appendixm.html

Should this be moved to profiles.ihe.net for consistency?

PDQm_102: Normative vs Trial-Implementation - Currently the HL7 FHIR standard components used (e.g., Patient, Bundle, etc) in this profile are at Normative state. Some portions of PDQm are relying on STU content (such as query parameters, mothersMaidenName).

http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#23784222-mothers-maiden-name

Suggests changing this:

Patient Demographics Suppliers shall include the mother’s maiden name, if known, in an extension named mothers MaidenName. See http://hl7.org/fhir/R4/extension-patient-mothersmaidenname.html

to something like this:

Patient Demographics Suppliers shall include the mother’s maiden name, if known, in this extension: http://hl7.org/fhir/R4/extension-patient-mothersmaidenname.html

Section Number 2: 3.78.4.1.3 https://profiles.ihe.net/ITI/PDQm/ITI-78.html#2378413-expected-actions

Issue The Expected Actions say to return a Query Patient Resource Response message, but since the various Cases follow before the reader gets to the specification of that message, I recommend adding a direct link. see below.

Proposed Change
in the sentences below I have added a link that is missing in the IG

The Patient Demographics Supplier shall return demographic records that reflect the match to all of the search criteria provided by the Patient Demographics Consumer. The Patient Demographics Supplier shall respond with a Query Patient Resource Response message synchronously.

Priority:

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.
• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.
• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number https://profiles.ihe.net/ITI/PDQm/index.html

Issue pointer to definition of 'Must Support on index page

Proposed Change
PDQm home page contains this:

Must Support`
PDQm uses Must Support in StructureDefinitions with the definition found in Appendix Z. This is equivalent to IHE use of R2.

Perhaps that should be moved to where the StructureDefinitions reside: https://profiles.ihe.net/ITI/PIXm/artifacts.html#structures-resource-profiles

Note, I have submitted the same issue for PIXm (IHE/ITI.PIXm#84) and PDQm. The resolution should be the same.

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number 2:3.78.4.2.4 - https://profiles.ihe.net/ITI/PDQm/ITI-78.html#2378424-capabilitystatement-resource

Issue consider changing the way we

Proposed Change
we have this:
2:3.78.4.2.4 CapabilityStatement Resource
Patient Demographics Suppliers implementing [ITI-78] shall provide a CapabilityStatement Resource as described in ITI TF-2:Appendix Z.4 indicating the query interaction for the Patient Resource has been implemented and shall include all query parameters implemented for the Patient Resource.

Issues/questions:

1. Now that we have an IG, we can point to Appx Z.4, but also add a pointer to https://profiles.ihe.net/ITI/PDQm/artifacts.html#behavior-capability-statements
2. It's not just Suppliers who Shall provide a Capability Stmt. We should require this of Consumers, too (to document which query parameters their client has implemented.
3. Where should this requirement to have a capability statement exist? PDQm has only one transaction, but what about profiles like PIXm that have two. Do we put the rqmt to have a CapabilityStmt in each transaction? In the actor rqmts in Vol 2? Other suggestions?

Priority:

• Medium: Significant issue or clarification. Requires discussion, but should not lead to long debate.

MHD Vol 1 dropdown menu contains an entry for the introduction section. It goes to MHD Home, which contains the contents of ITI TF-1: 33.

Do this for PDQm.

combine all of volume-1 into one volume-1.md.
explicit named anchors to be used for references to existing file breakdown.
follow pattern used in PIXm.

The PDF version of ITI-78 shows the differences from the v2 version of the same transaction in ITI-21.

In the IG http://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/ITI-78.html#237851-security-audit-considerations, you assume FHIR AuditEvent format.

I don't think we should lose the diff with ITI-21.

Section Number https://profiles.ihe.net/ITI/PDQm/actor_options.html#13821-pediatric-demographics-option--

Issue typo

Proposed Change
In the table in 38.2.1, "Helps creates true positive matches"... change creates to create

Priority:

• Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

I'm not sure this has a section number: https://build.fhir.org/ig/IHE/ITI.PDQm/branches/main/testplan.html#high-level-test-scope

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

We removed the Pediatric Demographics Option as the resolution to #34 but it seems to remain in the PDQm Test Plan Page

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Remove the Pediatric Demographics Option from the test plan.

Priority: - Low: Typo or other minor classification that an editor can manage. Requires no group discussion.