Today when I open volume 1 there is no content, only a purple rectangle. I guess some styling change went wrong.

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104423-expected-actions
"When the Patient Identifier Cross-reference Manager receives the Resolve Patient duplicate message of the Patient Identity Feed transaction, it shall cross-reference the patient identifiers provided by replacing any references it is maintaining internally to the patient identifier provided in the ‘replaces’ link by the patient identifier included in the Patient resource."

The italic part of the sentence is very confusing.

Section Number 1:41.1.1.3 https://profiles.ihe.net/ITI/PIXm/volume-1.html#141113-patient-identifier-cross-reference-manager

Issue slight rewording suggestion below

Proposed Change
Suggest changing this:
The Patient Identifier Cross-reference Manager manages patient identity data from different domains and cross-references patient identity data from different domains assigned to the same patient person.

To this:
The Patient Identifier Cross-reference Manager manages patient identity data from different domains and cross-references patient identity data from different domains for the same patient.

Priority:

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

Section Number 1:41.4.1 https://profiles.ihe.net/ITI/PIXm/volume-1.html#14141-concepts

Issue too many references to PIXm being a front for PIX or PIXv3

Proposed Change
Delete this sentence at the end of concepts. We have the same information in 41.1 and 41.6 (stated better elsewhere).

The actors of this profile may be grouped with corresponding actors of the PIX or PIXV3 profiles and may act as a facade for a PIX or PIXV3 Patient Identifier Cross-reference Manager to provide RESTful interfaces with FHIR patient resources for patient identity cross referencing.

Priority:

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

Section Number several

Issue use consistent terminology

Proposed Change
I did not search the entire IG for uses of Patient Identity Domain vs Patient Identifier Domain
One example...
In https://profiles.ihe.net/ITI/PIXm/volume-1.html#14141-concepts we say "The requirements on Patient Identifier Domain and a Patient Identifier Cross-reference Domain..."

In https://profiles.ihe.net/ITI/PIXm/volume-1.html#141421-multiple-identifier-domains-within-a-single-enterprise we say "This use-case has two Patient Identity Domains"

Priority:

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

In the new PIXm, the PIX Manager is required to support ITI-104 feed. Unless I am misunderstanding this transaction (very possible), the PIX Manager performing 104 must be maintaining patient records as FHIR Patient Resources.

If I have a legacy PIX or PIXv3 Manager who just wants to be able to respond to ITI-83 queries (based on cross-referenced IDs in my database), I cannot support PIXm as a PIX Manager (because I don't store FHIR Patient Resources).

Am I missing something??

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104422-message-semantics is missing explanation on how to perfom the conditional update. Do we update only the survivor? Only the deprecated? Why not both?

I set the revision to 2.2, the current PDF is 2.1.... I could be convinced that because of the feed, this should actually be published as 3.0...

Note that publishing it as 3.0 would be what we do AFTER we resolve comments and publish for TI.

That said, we should agree on the intended version plan.

use manual numbers and tell IG publisher to not auto-number
see MHD IHE/ITI.MHD@6d2fbb9

PIXv2 query response has 6 cases https://profiles.ihe.net/ITI/TF/Volume2/ITI-9.html#3.9.4.2.2.6

So does ITI-45 PIXv3 query

PIXm query response had 3 cases. Is this intentional?

Section Number 1: 41.4.1 https://profiles.ihe.net/ITI/PIXm/volume-1.html#14141-concepts

Issue room for improvement in statements in Concepts about PIX Mgr Capability Stmts. This issue addresses the 2nd and 4th paragraph. It moves the 4th paragraph above the 2nd. (the 3rd paragraph is addressed in a separate issue)

Proposed Change
Suggest changing this:
Patient Identifier Cross-reference Manager may publish the supported attributes, codes and constraints to inform Sources on what is expected and Consumer on what to expect. This profile does not define a new transaction for publishing the supported attributes, codes and constraints. It relies on the FHIR standard instead and recommends to publish the supported attributes, codes and constraints as part of the FHIR capability statement.
…
This profile does neither specify the rules and algorithm applied by the Patient Identifier Cross-reference Manager actor to link or unlink the patient identity data from different domains, nor the point in time the Patient Identifier Cross-reference Manager actually links the data. Patient Identifier Cross-reference Manager may link the patient identity data from the different domains on time of the Mobile Patient Identifier Cross-reference Feed [ITI-104] transactions, but also may provide other triggers (e.g., manual linking or unlinking in case when the rules and algorithms go wrong).

To something like this:
The PIXm Profiles does not specify the rules and algorithm applied by the Patient Identifier Cross-reference Manager actor to cross-reference the patient identity data from different domains. The FHIR CapabilityStatement published by thePatient Identifier Cross-reference Manager enables it to specify the attributes, codes and constraints it has implemented to support its cross-referencing.
The Patient Identifier Cross-reference Manager will cross-reference the patient identity data from the different domains when it receives Mobile Patient Identifier Cross-reference Feed [ITI-104] transactions, but it may also provide other triggers (e.g., manual linking or unlinking in case when the rules and algorithms go wrong).

Priority:

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

The PDF version of ITI-83 shows the differences from the v2 version of the same transaction in ITI-9.

In the IG https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-83.html#238351-security-audit-considerations, you assume FHIR AuditEvent format.

I don't think we should lose the diff with PIX query audit v2.

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#231044-messages

A Patient Identity Source notifies the Patient Identifier Cross-reference Manager for adding or revising patients in his patient identifier domain. The Patient Identity Source notifies the Patient Identifier Cross-reference Manager that duplicate records were resolved in the Patient Identity Source. The Patient Identity Source may notify the Patient Identifier Cross-reference Manager that a patient record was removed in the Patient Identity Source

In the above, in the first sentence, I think you want to follow the pattern in the following two sentences, eg.. "
A Patient Identity Source notifies the Patient Identifier Cross-reference Manager that patient records were added or revised in the Patient Identity Source.

Section Number 1:41.3 https://profiles.ihe.net/ITI/PIXm/volume-1.html#1413-pixm-required-actor-groupings

Issue Add Source actor to required grouping table

Proposed Change see above

Priority:

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

• Consider moving Use Case 3 & 4 prior to Use Case 1 & 2. This enables a reader to understand how the feed works between the Source & Manager, before reading how the cross-referenced IDs are used when the Consumer queries the Manager.
• In 3 & 4, clarify that the "patient administration" of the hospital is acting as the Source actor.
• In use case 4, add a sentence at the end that says, "This enables the Patient Identifier Cross-reference Manager to ...", just as you do in Use Case 3. This enables the reader to know what the PIX Mgr does when resolving duplicates.

EDIT: I misread, the reference was correct, so I close the issue.

In this sentence, change "duplicate" to "subsumed." A link of type 'replaces' SHALL be added with the identifier pointing to the duplicate record.

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#2310443-remove-patient says "The Patient Identifier Cross-reference Manager indicates in the CapabilityStatement if this message is supported."

Usually the server has to support all messages in a transaction, but, if this is truly 'optional', then the Expected Actions should have some indication of what a PIX Manager should send back to the Consumer to indicate that it's not going to respond to the Remove notification.

...OR... does this imply that the Source has to know (via the Manager's Capability Stmt) that the server doesn't support remove, so it shouldn't send this message???

Move this first sentence above to 2:3.104.4.2: The Resolve Patient duplicate trigger signals that duplicate records were resolved in the Patient Identity Source.

Section Number
1:41.1.1 https://profiles.ihe.net/ITI/PIXm/volume-1.html#14111-actor-descriptions-and-actor-profile-requirements

Issue
considerations for consistency on profile, actor & transaction names

Proposed Change
considerations:

• Gazelle Master Model currently has ITI-83 as "Mobile Patient Identifier Cross-Reference Query" , and the transaction is not consistently identified like this across the IG
• PIX and PIXv3 call the source actor "Patient Identity Source"
• ITI-8 is "Patient Identity Feed"
• ITI-44 is "Patient Identity Feed HL7 V3"
• ITI-9 is "PIX Query"
• ITI-45 is "PIXV3 Query"
• Interestingly, the FT profiles are called "Patient Identifier Cross-referencing (PIX)" and "Patient Identifier Cross-referencing HL7 V3 (PIXV3)" I never paid attention to the "ing" before...

Priority:

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

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104423-expected-actions
"The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the Duplicates Resolved message as specified in 3.104.4.2.2.2.1." There is no such "Duplicates Resolved message nor section 3.104.4.2.2.2.1.

Use case 1: https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/volume-1.html#141421-retrieving-documents-from-other-domains

• It seems odd that the use case title is "retrieving documents from other domains". It is really "finding a patient's ID in another domain (to enable retrieving documents)"
• The last sentence in this section is really the first thing that happens in time: the patient is registered by the ADT to get an MRN. Other things are also out-of-order. Re-arrange the section so the events are chronological. i.e. 1. ADT creates MRN. 2. allergy information is stored under that MRN, 3. Accident happens. 4. driver's license via ITI-104 5. PIX Mgr cross-references the IDs, 6. PIXm query & response, etc

Use case 2: https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/volume-1.html#141422-providing-documents-for-other-domains

I don't see the value of this use case for PIXm:

• The first sentence (providing documents) has nothing to do with PIXm
• The second sentence (PIXm query to enable retrieving a doc) is really use case 1

Is there a reason why we are just not reusing the Use cases from PIX? https://profiles.ihe.net/ITI/TF/Volume1/ch-5.html#5.3 (even if we copy them rather than referring to them...)

Section Number 1:41 https://profiles.ihe.net/ITI/PIXm/index.html#1-41-pixm-home

Issue suggestions to improve Vol 1 intro to PIXm

Proposed Change
Replace this:
The Patient Identifier Cross-reference for Mobile Integration Profile provides RESTful transactions for mobile and lightweight browser-based applications to create, update and delete Patient Ressources in a Patient Identifier Cross-reference Manager and to query the Patient Identifier Cross-reference Manager for a list of patient’s cross-domain identifiers assigned to the same patient person by the Patient Identifier Cross-reference Manager.

The Patient Identifier Cross-reference for Mobile Integration Profile requires the Patient Identifier Cross-reference Manager to implement rules and algorithm to link patient records from different domains to provide the cross-domain identifiers assigned to the same patient person.

This profile provides lightweight alternative to the transactions defined in the PIX and PIXV3 profiles, using HTTP RESTful transactions.

with this:
The Patient Identifier Cross-reference for Mobile (PIXm) Profile provides RESTful transactions for mobile and lightweight browser-based applications to create, update and delete patient records in a Patient Identifier Cross-reference Manager and to query the Patient Identifier Cross-reference Manager for a patient’s cross-domain identifiers.

The PIXm Profile requires the Patient Identifier Cross-reference Manager to implement rules and algorithms to cross-reference patient records from different domains. These rules/algorithms are not specified by this profile.

The HTTP RESTful transactions in PIXm are an alternative to the transactions defined in the PIX [add link] and PIXV3 [add link] profiles.

This profile does not assume the Patient Identifier Cross-reference Manager has the ability to act as a full-fledged HL7® FHIR® server. PIXm transactions can be used to provide a RESTful interface to a PIX or PIXV3 Patient Identifier Cross-reference Manager without providing other FHIR services.

==

ALSO, when this wording is agreed upon by ITI Tech, then one of the updated sentences will be copied to the PIXm Overview section 1:41.1 https://profiles.ihe.net/ITI/PIXm/volume-1.html#1414-pixm-overview

Priority:

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

We say this in 4.2.3: The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the Duplicates Resolved message as specified in 2:3.104.4.2.2.1.

But looking in that section, what attributes are we talking about? The link type? If that's it, this is just noise to me.

Suggest changing this:

After the identifier references are replaced, the Patient Identifier Cross-reference Manager shall reapply its internal cross-referencing logic/ policies before providing the updated information via the PIX Query transactions.

to this:

After processing the Remove Patient message, the Patient Identifier Cross-reference Manager shall not return the removed identifier in response to PIX Query transactions.

See model for MHD. Is this a convention to follow for PIXm?

https://ihe.github.io/publications/ITI/MHD/1331_actors_and_transactions.html

PIX has Patient Identity Feed [ITI-8] and PIXV3 has Patient Identity Feed HL7V3 [ITI-44].

This profile has:
Mobile Patient Identifier Cross-reference Feed [ITI-104]

Is there a reason we included "Cross-reference" in the transaction name. Do we only intend it to be used for cross-reference purposes? If yes, then OK. If we think it will be re-used in other profiles, then perhaps we should rename it.

Do we need a paragraph added to explain how the PMIR feed is distinguished from PIXm feed, and the environment in which each is appropriate?

Remember, too, that the PIXm Query transaction is also used in PMIR, so a PMIR Registry responds to ITI-83. For the 2021 Connectathons, (where systems might support both PIX Mgr and PMIR Registry), I wrote explanatory text about how the ITI-83 response might look different in those two environments (https://gazelle.ihe.net/content/pmirconnectathontestpatients). I haven't thought, yet, about whether that explanation will need to be updated when this newer PIXm profiles is published.

Maybe this is future whitepaper material, but it seems like a gap

I have assigned the new PIXm feed to transaction number 104

https://wiki.ihe.net/index.php/ITI_Vocabulary_Registry_and_Data_Dictionary#Volume_2c.2C_Transaction_and_Section_Numbers

| ITI-104
| Patient Identity Mobile Feed

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104423-expected-actions

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the Duplicates Resolved message as specified in 3.104.4.2.2.2.1. <=== Not a valid section number

The Patient Identifier Cross-reference Manager shall perform the Expected Actions similar to the ones specified in ITI TF-2: 3.8.4.2.3. The particular behavior is described below. <=== if the expected actions are 'similar' but not the same, what is the value of the reference??

When the Patient Identifier Cross-reference Manager receives the Resolve Patient duplicate message of the Patient Identity Feed transaction, (<=== match the message name exactly) ...

... it shall cross-reference the patient identifiers provided by replacing any references it is maintaining internally to the patient identifier provided in the ‘replaces’ link by the patient identifier included in the Patient resource. After the identifier references are replaced, the Patient Identifier Cross-reference Manager shall reapply its internal cross-referencing logic/ policies before providing the updated information via the PIX Query transactions. (<=== in the beginning of this text, you say it shall cross-reference... but at the end, you say that the cross-referencing happens after the identifier references are replaced. I think this text needs revision in committee.)

Do we need 1:41.2.1? Doesn't seem like an Options section when there are no options is particularly useful.

If it is needed, then I think it should say "blank" rather than "blanc".

In https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/volume-1.html#14141-concepts:
"This profile assumes that the Patient Identifier Cross-reference Manager performs linking and unlinking based on the patient identity data provided in the Mobile Patient Identifier Cross-reference Feed [ITI-104] transactions from different patient domains."

I don't think the linking/unlinking is done only from the data from ITI-104, as linking and unlinking was already performed in the previous version of PIXm. Why would we limit the linking/unlinking to the data from ITI-104?

In https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#2310443-remove-patient, "The Patient Identifier Cross-reference Manager indicates in the CapabilityStatement if this message is supported.".

Why is this sentence only in the section Remove Patient? Is the Remove Patient optional and are the Add or Revise Patient and Resolve Patient duplicates mandatory to support? In that case, I believe it should be made clear in the document.

Suggest changing this:

When the Patient Identifier Cross-reference Manager receives the Remove Patient message of the Patient Identity Feed transaction, it shall cross-reference the patient identifiers provided by removing any references it is maintaining internally to the patient identifier provided.

to this:

When the Patient Identifier Cross-reference Manager receives the Remove Patient message, it shall remove any references it is maintaining internally to the patient identifier provided.

We should understand and document how PIXm solution compares and contrasts to DaVinci Alerts IG.

http://hl7.org/fhir/us/davinci-alerts/STU1/index.html

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104425-example
In the example, it is not clear which Alice is the survivor and which is the deprecated.

And again, why only updating the survivor?

In https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104413-expected-actions,
"the Patient Identifier Cross-reference Manager MAY create a resource id on a Conditional update/create but is not required to do so, there is no requirement on PIX Manager to managed identities, only to cross-correlate provided identifiers."

• Does this mean that the PIX Manager MAY create a Patient resource on the Conditional update? In this case I would suggest to clarify and replace "resource id" by "Patient resource".
• Or is "id" really meant here, in which case I will argue that a FHIR resource always have an id (https://www.hl7.org/fhir/resource-definitions.html#Resource.id "The only time that a resource does not have an id is when it is being submitted to the server using a create operation.")?
• Or in case by "id" you meant "identifier", then I will ask which domain are we talking about.

In Col 1, add rowspan for the PIX Manager to make it clear that ITI-83 and ITI-104 apply to that actor.

We say here that Maiden has been merged into Mohr. Everywhere else it's backwards to that: x has been subsumed by y. It's like a tense shift. Please use one direction.

Also, the duplicate identifier should be the subsumed identifier.

The first sentence is missing an A in "Patient Identifier Cross-reference Manger".

In https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104421-trigger-events "The Revise Patient trigger" should be The Resolve patient duplicate trigger".

In https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104414-response-message:
See http://hl7.org/fhir/http.html#create for response.

Why is the link referencing to the response of #create and not #cond-update?

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/ITI-104.html#23104431-trigger-events

For a given Patient Identifier Domain there SHALL be one and only one Patient Identity Source Actor, but a given Patient Identity Source may serve more than one Patient Identifier Domain.

Move the above sentence to Vol 1, perhaps here: https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/volume-1.html#141111-patient-identifier-cross-reference-source

https://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/volume-1.html#14142-use-cases

In Vol 1 Use cases, I hope "blank" is a placeholder. We should show the interaction diagrams for the use cases

Section Number 1:41.4.1 https://profiles.ihe.net/ITI/PIXm/volume-1.html#14141-concepts

Issue We rely on PIX define 'domain requirements' but when I followed the link to the PIX Vol 1 header, I didn't realize that the definition was a bit down in the introduction, so I initially assumed it was an inaccurate link.

Proposed Change
"The requirements on Patient Identifier Domain and a Patient Identifier Cross-reference Domain as defined for the PIX profile apply also for this profile. See ITI TF-1 Figure 5-1 and accompanying text."

Priority:

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

Suggest changing this to "Merge" instead. At lease reorder to "Resolve Duplicate Patient"

"This profile does neither specify the rules and algorithm applied by the Patient Identifier Cross-reference Manager actor to link or unlink the patient identity data from different domains, nor the point in time the Patient Identifier Cross-reference Manager actually links the data. Patient Identifier Cross-reference Manager may link the patient identity data from the different domains on time of the Mobile Patient Identifier Cross-reference Feed [ITI-104] transactions, but also may provide other triggers (e.g., manual linking or unlinking in case when the rules and algorithms go wrong)."

Does this include that a Source can explicitly request the PIX Manager to perform a link of two patients?

As an example where it can be needed, let's say we have system A in domain A, system B in domain B (system B is both PIX Source and Consumer), and a PIX Manager.
System A sends a patient referral to system B for a patient P1. P1 has an identifier from domain A.
System B, which does not recognize the identifier from domain A, sends a PIX query to the PIX manager to find existing patients in domain B linked to patient P1.
If the request does not return any patient, system B will create a new patient P2 with the demographics from P1 and an identifier from domain B.
System B will then inform the PIX Manager of the newly created patient P2 via the patient identity feed (ITI-104).
=> Can system B explicitly ask the PIX Manager to link P1 and P2?
The PIX Manager is expected to notice that P1 and P2 are the same patient and link them, but can an external system trigger the link in case the rules and algorithms go wrong?
And would that be part of the PIXm transactions?

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).

Section Number Unit test procedure section https://profiles.ihe.net/ITI/PIXm/5_testplan.html#unit-test-procedure-conformance-testing

Issue add hyperlinks to urls

Proposed Change When I (lynn) created this page, I didn't add hyperlinks to test test definitions, e.g. https://gazelle.ihe.net/content/pmpixquery-patientidentityconsumer

Add them.

Priority:

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

Section Number 1:41.5

Issue Recommended OAuth scopes missing for use with IHE IUA. IHE IUA intentionally does not provide the OAuth2 scopes for all interactions, and leaves that to the profiles that reference IHE IUA. In the current form of the profiles no scopes are defined for the transactions in PIXm, potentially leading to non-interoperability on security level.

Proposed Change Add scopes based on transaction ids for use with IHE IUA. ITI-83 for query API methods, ITI-104 for the feed API methods. These should be added to section 2:3.83.5 and section 2:3.104.5 respectively. This approach is similar to what was done for the IHE MHD profile.

Priority:

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