NMS.KK.ACCESS.004 - Subscription start date following MCTS upload

[larubbio]

If the subscriber does NOT call the IVR long code/s, and is subscribed automatically from the back end via an upload of data from MCTS, then the subscription pack for a beneficiary and the week that the message will start in will be based on the LMP or DOB provided in MCTS Data upon data upload (refer #110 NMS.GEN.MCTS.001) as per following rules:

• If DOB is present (with or without LMP) in the data, then Child pack (12-Months-Pack) shall be subscribed. Service shall be “activated” from the date of data upload (subscription state = Active).
• If LMP is present without DOB then pregnancy pack shall be subscribed. Service shall be “activated” from the date of data upload (subscription state = Active) except for case of “early subscription” (for which refer #160 NMS.KK.ACCESS.007).

If a woman is subscribed to Kilkari via MCTS data, the service could start at any point during the 72 week or 48 week schedule. Since we cannot assume that her ASHA or ANM will have informed her about Kilkari, we will need to play her an initial welcome message before any other content is played. This welcome message will introduce her to Kilkari. Once this welcome message has been played in the first week of the service starting, then the next week’s content, as per the LMP or DOB, will be played.

[larubbio]

[larubbio]

From an email thread:

Handling for following requirement is missing in API specification. 

"If a woman is subscribed to Kilkari via MCTS data, the service could start at any point during the 72
week or 48 week schedule. Since we cannot assume that her ASHA or ANM will have informed her
about Kilkari, we will need to play her an initial welcome message before any other content is played."

To handle this requirement a new field is needed in OBD record (in OBD file) to indicate the first 
OBD message of subscribed pack.

[llavoie]

@larubbio Could you ask for additional clarification on the email thread you mention above?

There are a few more things I think we need to know:

• What do we add to the OBD target file to indicate that the welcome message needs to be played? Is this a new column, or a weekId/filename that indicates the welcome message?
• Do we need to indicate the same in response to an inbox request?
• How do we set the start date for a pregnancy pack when we have an LMP? As I understand it, the pregnancy pack starts at the second trimester. So is the start date something like LMP + 90ish days?

CC @frankhuster re: the implications for OBD target file

[larubbio]

For the first point I think we can add whatever field we want, update the spec and then communicate that to IMI.

For the second point we do not need to add anything. If there is an inbox, but no inbox messages then the assumption is the user is new. However in the list of prompts provided by BBC there was no prompt for that welcome message so it may not actually be a req.

For the third point the text above (copied from the SRS) differs from what was in the email thread (I forwarded the thread to everyone a couple of days ago)

If the subscriber does NOT call the IVR long code/s, and is subscribed automatically from the back end via an upload of data from MCTS, then the subscription pack for a beneficiary and the week that the message will start in will be based on the LMP or DOB provided in MCTS Data upon data upload (refer #110 NMS.GEN.MCTS.001) as per following rules:

• If DOB is present (with or without LMP) in the data, then Child pack (12-Months-Pack) shall be subscribed. Service shall be “activated” (i.e. first OBD shall be sent) on the day-1 of the week (as computed from DOB) that follows the date of data upload (subscription state = Active).
• If LMP is present without DOB then pregnancy pack shall be subscribed. Service shall be “activated” (i.e. first OBD shall be sent) on the day-1 of the week (as computed from [LMP + 3 Months]) that follows the date of data upload (subscription state = Active) except for case of “early subscription” (for which refer #160 NMS.KK.ACCESS.007).

So to answer the third question it is LMP + 3 Months

[llavoie]

Thanks. Right now a subscription has no concept of whether it is "new" so we'll need to add that.

How does IMI expect us to represent an inbox with no messages? Would the JSON response just omit the "inboxWeekId" and "contentFileName" that are shown in section 4.2.2.2 of the API spec? See example JSON for an inbox response below.

{
  "inboxSubscriptionDetailList": [
  {
    "subscriptionId":
    "12345678-9...",
    "subscriptionPack":
    "48WeeksPack", 
    "inboxWeekId": "2_2",
    "contentFileName":
    "xyz.wav"
  },
  {
    "subscriptionId":
    "11111111-1...",
    "subscriptionPack":
    "76WeeksPack",
    "inboxWeekId": "10_1",
    "contentFileName":
    "xyz.wav"
  }
  ]
}

[larubbio]

From that mail thread:

Scenario 2: Kilkari beneficiary is calling inbox service whose subscription is in “Early subscription State”

• User dials the Kilkari Inbox long code
• IVR System shall send the "Get Subscriber Details API" request to the MoTech System.
• MoTech system shall return the language location and the subscription information to IVR system.
• IVR shall retrieve the inbox details using "Get Inbox Details API" request because subscription information is present in the response of "Get Subscriber Details API"
• Motech shall not return the inbox details in the response because there is no inbox created for the subscriber, which is in “Early Subscription State”,.
• In this case IVR shall play different “Promotional Message” and disconnect the call.

Please also note that we have received the prompt list from BBC and we could not find 2 different promotional messages for inbox handling. We are clarifying the same with BBC.

Currently the code "handles" the condition that there is a subscription, but no inboxWeekId or contentFileName:

   <if cond="!lSubscriptionPack || !lInboxWeekId || !lContentFileName">
     <!-- going to the promo message, if no weekly messages exist for user.  This is an error
          since motech didn't return complete json -->
     <if cond="lSubscriptionIndex === 0">
       <log> Required Subcription Details Not Found for Subscription Pack </log>
       <goto next="#PromoMsg" />
     <else />
       <log> All Weekly Messages Played to User. </log>
       <disconnect />
     </if>   
   </if>

However it doesn't play that welcome message (one hasn't been provided yet), instead it logs and disconnects. So I think we can just exclude those fields instead of adding a 'new' flag.