PIXm22 - Requirement assigning authority Name on Cross-reference Manager

[lynnfel]

Section Number 2.3.104.4.1.3 https://profiles.ihe.net/ITI/PIXm/ITI-104.html#23104413-expected-actions

Issue ITI-8 PIXv2 feed has rqmts for the PIX Mgr if assigning authority is not provided by the Source. Do we need this in ITI-104?

Proposed Change In ITI-8, even though assigning authority is required in the request semantics (as ITI-104 does in 2:3.104.4.1.2.1) there are still rqmts on the PIX Manager for when it receives a feed w/o assigning authority.

ITI-8 Expected Actions says the following; do we need a similar statement in ITI-104? If the PID-3.4 (assigning authority) component is not included in the message (as described in Section 3.8.4.1.2.3) the Patient Identifier Cross-reference Manager shall fill PID-3.4 prior to storing the ID information and performing its cross-referencing activities. The information filled by the Patient Identifier Cross-reference Manager is based on the configuration associating each of the Patient Identity Source Actors with the subcomponents of the correct assigning authority (namespace ID, UID and UID type). (See Section 3.8.4.1.3.1 below for a list of required Patient Identifier Cross-reference Manager configuration parameters).

... and ... 3.8.4.1.3.1 Required Patient Identifier Cross-reference Manager Configuration

The following items are expected to be parameters that are configurable on the Patient Identifier Cross-reference Manager Actor. For each Patient Identification Domain included in the Identification Cross-reference Domain managed by a Patient Identifier Cross-reference Manager Actor, the following configuration information is needed:

• Identifier of the Domain. This identifier shall specify all 3 components of the HL7 assigning authority (including the namespace ID and/or both the universal ID and universal ID type subcomponents) of the PID-3 field for the identification of the domain.
• Patient Identity Source for the domain. This is expected to be the MSH-3 Sending Application and the corresponding MSH-4 Sending Facility fields in the HL7 ADT message. (Alternative identification schemes might include IP address of the Patient Identity Source or Node Authentication if the Audit Trail and Node Authentication Integration Profile is used.)

Priority:

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

[oliveregger]

for PIXm the assigning authority must be provided, otherwise the API will not work. do we need to make it more clear? Now it ist stated: The identifier of the Patient Identification Domain of the Patient Identity Source SHALL be provided.

[lynnfel]

From what you have written, it seems like the PIX Manager in ITI-104 would not add an assigning authority value if it gets a feed with an patient ID without assigning authority.

OK... it is different than ITI-8.

There is nothing in ITI-104 that specifies how the PIX Manager will respond if it receives a feed w/o an assigning authority on patient ID. Your comment above says that the API will not work. Does that mean that FHIR defines the response in this 'error' condition?

[oliveregger]

E.3 FHIR Identifier Type and Z.9.1 Identifier Type both require that system and value are populated.

system can be mapped by the PIX Manager to the assigning authority, since the format may be different (oid or url instead of string) the name can also be directly provided by the source or the cross-reference manager needs to handle it.

For PIX V3 the following is added in Appendix E (E.2.1 Patient Identifier Cross-reference Manager requirements):

In addition, IHE requires that the Patient Identifier Cross-reference Manager populates element assigningAuthorityName. Though there is no additional requirement for the data type of this element than a text string in a HL7 V3 message or CDA document, it shall be the same value as populated in CX.4.1, if the actor participates in transactions of both HL7 V3 and HL7 V2 messages. In this case, element assigningAuthorityName shall contain a value of HL7 V2 data type IS, a code taken from user-defined Table 0363, Assigning Authority, see Section E.1.

The Appendix E.3 FHIR Identifier Type is a bit less strict:

IHE imposes the following restrictions on the FHIR Identifier datatype for a Patient: Both the value and system shall be populated. See Appendix Z.9.1 Identifier Type. The assigner attribute may be populated (the name of the organization which assigned the identifier). When the assigning authority name is provided, the actor shall also populate the display attribute.

how about:

• Appendix E would need to introduce also Patient Identifier Cross-reference Manager requirements (this would cover youre first point raised)
• We could make the profile http://build.fhir.org/ig/IHE/ITI.PIXm/branches/master/StructureDefinition-IHE.PIXm.Patient.html explicit hat for the identifier value and system needs to be populated

if a source would not provide system with the feed FHIR defines the error condition:

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code.

[oliveregger]

discussion at telco: need feedback from someone who has implemented pix v3 and pix, will schedule for "virtual f2f"

[oliveregger]

rereading: the Patient Identity Source is not required to populate assigningAuthorityName in Patient Identity Feed FHIR [ITI-104] (required to provide system, and value) and currently we have not an explicit requirement that the Patient Identifier Cross-reference Manager would need to add it before doing the cross-referencing, does this cause a problem?

[oliveregger]

if we cannot resolve it this meeting we will add it as an open issue and it could be added in the grouping behaviour for the 104 transaction or appendix e

[JohnMoehrke]

why is this still open? @oliveregger

[oliveregger]

@JohnMoehrke we did not come up to a conclusion at the virtual meeting, we listed it as an open issue 22 in the pixm open issue documentation but are pointing from there to here.