Ability to query Message Alert entity as regards delivery status

[mdovey]

Message delivery status is a property of the Patron entity, so it is not possible to query the delivery status by accessing the Message\Alert entity (for example if the message has been sent to via Patron Category)

[franciscave]

The reason that we associated delivery status with the Patron rather than with the Message/Alert is that the delivery status for a specific Message/Alert could vary from Patron to Patron. If there is a requirement to anonymise the message delivery status information, i.e. to disassociate it from identifiable Patrons, we would have to add some properties to the Message/Alert entity to allow it to carry aggregated delivery status information. But there are a number of ways this might be done, e.g. absolute numbers of Patrons, percentages, or broader, vaguer categories.

[franciscave]

At the Technical Panel meeting on 27/02/2019 we agreed that some detailed work is needed to add this feature, with particular attention to the status of messages sent to multiple patrons.

[franciscave]

Code list MAD defines three delivery status codes:

• Not yet delivered
• Delivered, not acknowledged
• Delivered, acknowledged

These are currently employed when querying a Patron entity/record, and indicate the status of a specific message/alert associated with that Patron. A Message/alert entity can be associated with one or more Patrons, one or more Patron categories. To fully communicate the delivery status of a specific message/alert, the following would need to be communicated:

1. For a message/alert to be delivered to specific Patrons, there should be an indication for each Patron as to whether or not the message/alert has been delivered and whether or not an acknowledgement has been received. There could also be summary elements stating the total number of Patrons to whom the message/alert has been delivered and the total number of Patrons from whom an acknowledgement has been received.
2. For a message/alert to be delivered to specific Patron categories, there should be an indication for each category as to the number and possibly identity of the Patrons to whom the message/alert has been delivered and whether or not an acknowledgement has been received in each case. There could also be summary elements for each category similar to those for specific Patrons - see above.

The overall structure could be something like the following:

Id	Element	SIP2 ID	Card.	Format	Description
E15C16	Delivery information		0-1
E15D16.1	Total delivered		0-1	Integer	Number of Patrons to whom this message/alert has been delivered
E15D16.2	Total acknowledged		0-1	Integer	Number of Patrons from whom acknowledgements of this message/alert have been received
E15C16.3	Delivery to Patron		0-n		Delivery status for specific Patron
E15D16.3.1	Patron reference		1	String
E15D16.3.2	Delivery status		1	Code	LCF code list MAD If included, the code value must match the current value of E03D34.2 for this Patron
E15C16.4	Delivery to Patron category		0-n		Delivery status for specific category of Patron
E15D16.4.1	Category name		1	String
E15D16.4.2	Total Patrons in category		0-1	Integer	Number of Patrons at whom this message/alert is aimed
E15D16.4.3	Total delivered		0-1	Integer	Number of Patrons in category to whom this message/alert has been delivered
E15D16.4.4	Total acknowledged		0-1	Integer	Number of Patrons in this category from whom acknowledgements of this message/alert have been received
E15C16.4.5	Delivery to Patron		0-n		Delivery status for specific Patron in this category
E15D16.4.5.1	Patron reference		1	String
E15D16.4.5.2	Delivery status		1	Code	LCF code list MAD If included, the code value must match the current value of E03D34.2 for this Patron

A minimal implementation of this enhancement would be to implement composite E15C16 and just two of its sub-elements: E15D16.1 and E15D16.2. This would provide some vague information about the number of Patrons who have received the message/alert and how many of those have acknowledged receipt.

There is only any point in implementing E15C16.3 and E15C16.4 if the delivery status information for each Patron or Patron category is to be included in the Message/alert record. Otherwise, the terminal might as well retrieve the information by selecting Patron records associated with the message/alert and retrieving the delivery status in each case. This could be done by requesting a list of all Patron entities that are associated with a specific Message/alert entity, and arranging for a set of partial Patron records to be embedded in the response.

In summary, there are two ways to resolve this issue:

1. Extend the properties of the Message/alert entity as described above, so that a single Message/alert record can be retrieved containing all the desired information about the message/alert's delivery status.

2. Add support for retrieving a list of partial Patron records that contain only the desired delivery status information for a specific Message/alert. Other issues relate to this alternative - see issues Partial record return #115 and Inclusion of entity objects when retrieving entity instance list #191.

[franciscave]

The Technical Editors discussed this briefly. What is proposed probably contains more information - and more duplicate information that can be retrieved from Patron records - than is needed. A suggestion would be to modify the proposal to remove E15D16.3.2 Delivery status and the whole of E15D16.4.5. But in that case E15D16.3.1 simply duplicates E15D11, which would mean that E15D16.3 is redundant. A simpler structure would therefore be:

Id	Element	SIP2 ID	Card.	Format	Description
E15C16	Delivery information		0-1
E15D16.1	Total delivered		0-1	Integer	Number of Patrons to whom this message/alert has been delivered
E15D16.2	Total acknowledged		0-1	Integer	Number of Patrons from whom acknowledgements of this message/alert have been received
E15C16.3	Delivery to Patron category		0-n		Delivery status for specific category of Patron
E15D16.3.1	Category name		1	String
E15D16.3.2	Total Patrons in category		0-1	Integer	Number of Patrons at whom this message/alert is aimed
E15D16.3.3	Total delivered		0-1	Integer	Number of Patrons in category to whom this message/alert has been delivered
E15D16.3.4	Total acknowledged		0-1	Integer	Number of Patrons in this category from whom acknowledgements of this message/alert have been received

The disadvantage with this simpler structure is that the delivery status information is only available in aggregated form. To determine whether a message/alert has been delivered to a particular Patron, it will still be necessary to retrieve the Patron record.

[franciscave]

To handle the cases where messages are sent to Patrons related to specified Loans or Reservations (message/alert audience code values '03' or '04'), the above could be extended as follows:

Id	Element	SIP2 ID	Card.	Format	Description
E15C16.4	Delivery to related Patrons		0-n		Delivery status for Patrons related to the specified Loans or Reservations
E15D16.4.1	Total Patrons		0-1	Integer	Number of Patrons at whom this message/alert is aimed
E15D16.4.2	Total delivered		0-1	Integer	Number of Patrons to whom this message/alert has been delivered
E15D16.4.3	Total acknowledged		0-1	Integer	Number of Patrons from whom acknowledgements of this message/alert have been received

A single composite is all that is needed, since the message/alert audience cannot be both '03' and '04'.