Integrating Third-Party NCIP Requestor Applications with Circulation (NCIP Responder)

To acquire the NCIP Responder product, contact Innovative.

SIP2 does not support NCIP checkin. Consequently, your library cannot use selfcheck units to check in materials borrowed using NCIP Responder.

The NCIP Responder product enables the Innovative system to communicate with third-party NCIP requestor applications, such as Relais D2D and OCLC's VDX, via the NISO Circulation Interchange Protocol (NCIP) Version 2.0 during patron verification and circulation activities.

For more information on how third-party NCIP requestor applications integrate with Circulation, see the following sections:

Requesting an Item

When the patron logs in to the third-party NCIP requestor application and requests an item:

  1. The third-party server requests patron verification information from the Innovative server. To do so, it creates a LookupUser NCIP message and transmits it to the Innovative server to which the patron belongs.
  2. The Innovative server queries the local patron record and creates the LookupUserResponse NCIP message and transmits it to the third-partyserver.
  3. The third-party server uses the data from the LookupUserResponse message to evaluate whether the patron is successfully verified or blocked from requesting.
  4. If the patron is successfully verified, the third-party server creates the RequestItem NCIP message and transmits it to the owning site's Innovative server.
  5. The owning institution receives the RequestItem NCIP message and uses the data in the message to place a hold on the requested item. The system uses an "institutional patron record" to place the hold, which represents the third-party system rather than the specific requesting patron. The owning institution is not provided with any information on the patron at the borrowing institution. The owning institution's Innovative server creates a RequestItemResponse NCIP message confirming receipt of the request.

Requesting a Title

When the patron logs in to the third-party application and requests a title:

  1. The third-party server requests patron verification information from the Innovative server. To do so, it creates a LookupUser NCIP message and transmits it to the Innovative server to which the patron belongs.
  2. The Innovative server queries the local patron record, creates the LookupUserResponse NCIP message, and transmits it to the third-party server.
  3. The third-part server uses the data from the LookupUserResponse message to evaluate whether the patron is successfully verified or blocked from requesting.
  4. If the patron is successfully verified, the third-party server creates the RequestItem NCIP message with fields specifying it as a title-level hold, and transmits it to the owning site's Innovative server.
  5. The owning institution receives the RequestItem NCIP message and determines whether the message contains:
    • A RequestScopeType value of “Title”

    • A BibliographicId field that contains a BibliographicRecordId element, which in turn contains a BibliographicItemIdentifier element. This BibliographicItemIdentifier element contains a bibliographic record number, excluding the check digit. This element can optionally have a prefix of ‘b’.

  6. If these conditions are met, the owning institution uses the data in the message to place a title-level hold on the requested title. The system uses an "institutional patron record" to place the hold, which represents the third-party system rather than the specific requesting patron. The owning institution is not provided with any information on the patron at the borrowing institution. The owning institution's Innovative server creates a RequestItemResponse NCIP message confirming receipt of the request.
  7. The RequestId value from the RequestItem NCIP message is stored in the note field of the newly created title-level hold. This note is appended to the standard note added for standard NCIP holds. This appended hold note appears in the following format:

    NCIP hold:<RequestId>

    Where the variable <RequestId> value is the RequestId value from the RequestItem message.

    This exact "NCIP hold:<RequestId>" text must be appended to the end of the hold note field. For this reason, if the hold note field is edited, the editor must ensure that the text "NCIP hold:<RequestId>" remains appended to the end of the new hold note.

Filling the Request

At the owning institution:

  1. A staff member:
    1. Prints the Title Paging List, which includes third-party NCIP bib-level holds.
    2. Retrieves the item from the shelf.
    3. Uses the third-party application to check out the item to the borrowing institution.
  2. The third-party server creates an CheckoutItem NCIP message and transmits it to the owning site's Innovative server.
  3. The Innovative server receives the CheckoutItem message and updates the institutional patron record and item record to reflect the item checkout. The Innovative server sends a CheckoutItemResponse NCIP message to the third-party server.
  4. The owning institution ships the item to the pickup location of the borrowing institution as specified in the NCIP Request Item message.

Receiving the Item at a Central Processing Location

For consortia using a third-party NCIP requestor application that uses central processing, materials from owning institutions arrive at the central location for processing, where they are then routed to the borrowing institution.

When the item arrives at the central processing location:

  1. The third-party system creates an AcceptItem NCIP message to create a virtual record.
Virtual Item Records

A virtual item record is a temporary record attached to the patron record. This record stores information required for circulation of the item at the borrowing site, and is deleted automatically at the borrowing site when the circulation process is complete.

  1. The staff member checks in the item, which is placed in-transit to the borrowing institution.
  2. A staff member at the borrowing institution checks in the item using the Sierra Desktop Application. During this process, Sierra prompts the user to print a hold slip for the item. Staff can click Yes to print the hold slip or No to continue without printing the slip.
  3. The system:
    1. Places an item-level hold on the item for the requesting patron.
    2. Places the item on the third-party NCIP holdshelf for the patron.
    3. Queues a Hold Pickup notice for the patron.

Receiving the Item at the Borrowing Institution

When the item arrives at the borrowing institution:

  1. A staff member uses the third-party NCIP application to check in the item.
  2. The third-party server creates an AcceptItem NCIP message and sends it to the Innovative server.
  3. The Innovative server:
    1. Creates an AcceptItemResponse NCIP message and sends it to the third-party server.
    2. Creates a virtual item record.
      Virtual Item Records

      A virtual item record is a temporary record attached to the patron record. This record stores information required for circulation of the item at the borrowing site, and is deleted automatically at the borrowing site when the circulation process is complete.

    3. Places an item-level hold on the item for the requesting patron.
    4. Places the item on the third-party NCIP holdshelf for the patron.
    5. Queues a Hold Pickup notice for the patron.

Checking Out the Item to the Patron

Staff at the borrowing site use Circulation to check out the item to the requesting patron. Circulation displays items in the DCB patron information tab of the requesting patron's record. You can modify the due date, but the Claim Returned and Mark Lost functions are not available for these items.

No NCIP messages are created during this checkout.

Checking In the Item from the Patron

When the patron returns the item, staff at the borrowing institution:

  1. Use Circulation to check in the item. The system updates the virtual item record and the requesting patron record to reflect the checkin.
  2. Use the third-party NCIP application to check in the item again. In response:
    1. The third-party server sends a CheckinItem NCIP message to the borrowing site's Innovative server.
    2. The Innovative server deletes the virtual item record and sends a CheckinItemResponse NCIP message to the third-party server. If there are errors in the checkin process, the error messages are communicated in the CheckinItemResponse message.
  3. Ship the item back to the owning institution.

Returning the Item to the Owning Institution

At the owning institution, staff use the third-party NCIP application to check in the item. In response:

  1. The third-party server sends a CheckinItem NCIP message to the owning institution's Innovative server.
  2. The Innovative server updates the status of the item record accordingly and sends a CheckinItemResponse NCIP message to the third-party server. At this point, the institutional patron record is no longer linked to the item.

Marking Items Lost or Claiming Items as Returned

If the patron reports the item as lost or claims the item has been returned, staff at the borrowing institution must check in the request in both Circulation and the third-party NCIP application, as they would if the item had been successfully returned. This step updates the requesting patron record and deletes the virtual item record.

The ILL department of the borrowing institution then should contact the ILL department of the owning institution to advise them of the updated status. At the owning institution, staff use Circulation to mark the item as lost or as claimed returned.

Managing Cancelled Holds after the Item has Shipped

Once the item is shipped, it cannot be cancelled. The system does not prevent the borrowing institution from receiving the item and placing it on the holdshelf. Staff should return an item unwanted when its time on the holdshelf expires according to the loan rule under which it was requested.

Cancellations Outside of Third-Party NCIP Applications

If the owning institution cancels the hold in their own system after the item has shipped, staff from the owning institution should contact the borrowing institution to make arrangements for the item's return. If possible, staff at the borrowing institution should not receive the item and should ship it back to the owning institution without processing. If the item has been received at the borrowing institution, treat it as an unwanted item.

Cancelling a Title-level Hold

When a patron logs in to the third-party application and cancels a title-level hold:

  1. The third-party application generates a CancelRequestItem NCIP message and transmits it to the owning site's Innovative server.
  2. The owning institution receives the CancelRequestItem NCIP message and determines whether the message contains:
    • A non-empty RequestId element
    • A non-empty UserId element
  3. If these conditions are met, the owning institution cancels the hold on the bibliographic record. If either the associated patron (specified by the UserId element) or the specified hold (identified by RequestId) cannot be found, the owning institution sends an error message indicating that the hold cannot be cancelled.
The CancelRequestItem message must use the same RequestId and UserId elements that were used in the original RequestItem message. These elements are used to uniquely identify the hold on the bibliographic record. The third-party application must provide the UserId field to identify the requesting patron. The system cannot use the AuthenticationInput field as the unique patron identifier in this message.

Returning an Unwanted Item

If a patron does not claim an unwanted item:

  1. Staff at the borrowing institution use the third-party application to check in the item. The third-party application generates a CheckinItem NCIP message.
  2. The Innovative server generates a CheckinItemResponse NCIP message, removes the virtual item record, and updates the requesting patron record.
  3. Staff at the borrowing institution ship the item back to the owning institution.
See Also