HL7 Patient Administration workgroup is looking at better
defining the patient merge/link functionality in FHIR. We will follow
this work and collaborate with HL7 to keep these efforts aligned. See
https://confluence.hl7.org/display/PA/Merge+Operation

I don't think we need to do this before the $match goes to TI.
I think once $match is TI, we then tweek PIMR

@lukeaduncan does that seem reasonable?

If other domain patient identities are included in the feed,
should there be expected actions on the Patient Identity Registry or
Patient Identity Consumer?

output\Bundle-30e285b5-a28c-444f-a898-a15159c82f38​.html warning The html source has duplicate anchor Ids: 30e285b5-a28c-444f-a898-a15159c82f38/76354729-8458-434c-ace5-007e6ff32464,hc30e285b5-a28c-444f-a898-a15159c82f38/76354729-8458-434c-ace5-007e6ff32464,hc30e285b5-a28c-444f-a898-a15159c82f38/76354729-8458-434c-ace5-007e6ff32464-und

output\Bundle-3594fe3c-31af-4695-b533-550e3bc0f1c9​.html warning The html source has duplicate anchor Ids: 3594fe3c-31af-4695-b533-550e3bc0f1c9/070b3907-883b-4f20-af66-88a5db6b73ad,hc3594fe3c-31af-4695-b533-550e3bc0f1c9/070b3907-883b-4f20-af66-88a5db6b73ad,hc3594fe3c-31af-4695-b533-550e3bc0f1c9/070b3907-883b-4f20-af66-88a5db6b73ad-und

output\Bundle-72681afa-2bee-4422-bdf7-d0363e113b65​.html warning The html source has duplicate anchor Ids: 72681afa-2bee-4422-bdf7-d0363e113b65/76c55983-0800-41f2-80b7-a49719e8334d,hc72681afa-2bee-4422-bdf7-d0363e113b65/76c55983-0800-41f2-80b7-a49719e8334d,hc72681afa-2bee-4422-bdf7-d0363e113b65/76c55983-0800-41f2-80b7-a49719e8334d-und

output\Bundle-d97b9e33-4b48-4190-8622-0b4b5be9770d​.html warning The html source has duplicate anchor Ids: d97b9e33-4b48-4190-8622-0b4b5be9770d/6119323c-93c7-4972-9ba7-f90686f6c370,hcd97b9e33-4b48-4190-8622-0b4b5be9770d/6119323c-93c7-4972-9ba7-f90686f6c370,hcd97b9e33-4b48-4190-8622-0b4b5be9770d/6119323c-93c7-4972-9ba7-f90686f6c370-und

Publish the TI version of the PMIR IG (Rev. 1.5.0)

Section Number 2:3.94

Issue See Proposed Changes

Proposed Changes

1. Table 2:3.94.2-1 needs to be bold
2. In Table 2:3.94.2-1, the last row, remove the period for consistency
3. In Section 2:3.94.4.1 Remove the italics from Subscription Resource in the sentence "The Subscribe to Patient Updates message is a FHIR create operation on a Subscription Resource."

Priority:

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

I am capturing this here because it's fast. Will translate into a CP later

I have discovered a number of changes that enable a much better rendering of the CapabilityStatements

1. don't include a text element, so as to allow IG builder to create narrative
2. don't include publisher, this will come from the IG details
3. don't include contact, this will come from the IG detail
4. don't include copyright, this will come from the IG detail
5. don't include a version, this will come from the IG detail
6. don't include a publisher, this will come from the IG detail
7. set status to active
8. set experimental to false
9. description is markdown, so leverage markdown for things like links
10. do not put an empty implementationGuide element
11. fhirVersion should be 4.0.1 (later, hope this comes from the IG detail)

I have added IHE/ITI.PIXm#120 to PIXm.

There should be mention of this in the PMIR section on Merge, so that when a Merge happens it is clear PIXm query is expected to react these ways.

The security for the feed transaction is currently being
debated in IHE and HL7. The mutual authentication solution in ATNA may
be used. The IUA solution with OAuth identities may be used. These
solutions aren’t straight-forward and resolution of IHE’s recommendation
requires trial implementation feedback.

Should we require maintaining resource versioning
information when updates are made to resources?

Should we include shall, should, or may for Provenance
resources in the Mobile Patient Identity Feed transaction? This version
doesn’t provide any guidance on Provenance, should it?

Should we include an option on the Patient Identity Registry
to support the FHIR $match operation on patients? This would require an
additional actor and transaction.

CP 1224 is lost, but appears to want a profile of Patient for the feed transaction.

When adding the $match transaction from PDQm this should be added by starting with a combination of PDQm and PIXm Patient profiles.

The e.g. text in 2:3.93.4.1.3.1 Post Merge/Delete Expectations looks like it's for PIXm when that isn't the correct format. It should be moved to the PDQm section.

CP-ITI-1203 changed the name of a PMIR actor from “Patient
Identity Manager” to “Patient Identity Registry” to better reflect the
passive role that the actor plays in PMIR. There was a suggestion at
that time to change the name of the profile from “Patient Master
Identity Registry” to “Patient Master Identity Registration.” Should the
profile be renamed?