Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix continue exposure #23

Conversation

MatthewCaseres
Copy link
Contributor

related to issue #22

@alecloudenback
Copy link
Member

I can review this weekend if you want and you think it’s ready

@MatthewCaseres
Copy link
Contributor Author

Another validation exercise with actxps might be valuable, the first one didn't check end dates or AnniversaryCalendar. If you'd like that done before reviewing the code then I can do that.

I am pretty sure you will find the logic to the opened issue is fixed though.

@MatthewCaseres
Copy link
Contributor Author

I don't have permissions to convert this to a draft PR but I'll be looking into this a bit deeper, would wait to review.

@MatthewCaseres
Copy link
Contributor Author

According to actxps, we shouldn't be extending exposures in this way.

Application of the annual exposure method. If the termination event of interest appears on a post-anniversary record, policy exposures will be 1 and calendar exposures will be the fraction of the year spanning the anniversary to December 31st. Conversely, if the termination event of interest appears on a pre-anniversary record, calendar exposures will be 1 and policy exposures will be the fraction of the policy year from January 1st to the last day of the current policy year. While it may sound confusing at first, these rules are important to ensure that the termination event of interest always has an exposure of 1 when the data is grouped on a calendar year or policy year basis.

Here is an image that shows the difference, columns on the left from Julia, columns on the right from R. NA values means the row does not exist in actxps.

Screenshot 2024-05-31 at 7 23 00 PM

It isn't clear how this idea fits into the existing design, since exposure calculations are done after the fact.
Asking the user to do this -

df.exposure_fraction =
        map(e -> yearfrac(e.from, e.to + Day(1), DayCounts.Thirty360()), df.policy_year) 

won't work. The exposure calculation would probably have to be performed by the package. Does that sound right?

@alecloudenback
Copy link
Member

Sorry, not quite following yet. What are the column headers on that screenshot?

@alecloudenback
Copy link
Member

For this example:

library(actxps)
library(dplyr)


census <- data.frame(pol_num = 1, 
                      status = "Death", 
                      issue_date = as.Date("2011-05-27"), 
                      term_date = as.Date("2012-03-17"))
census <- rbind(census,data.frame(pol_num = 2, 
                      status = "Death", 
                      issue_date = as.Date("2011-05-27"), 
                      term_date = as.Date("2012-09-17")))

exposed_cal <-  census |> 
  expose(end_date = "2022-12-31", cal_expo = TRUE, target_status = "Death")

split <- expose_split(exposed_cal)
image

I don't follow how this matches the documentation you quoted ("Application of the..."). Some questions I have looking at it:

  • The sum of exposures for policy 1 is 1.4 and 2.0 on a policy/calendar year basis respectively even though the policy never made it through one full year?
  • Similarly for policy 2, the exposures sum to 2.4 and 2.6 even though the policy only made it <1.5 years.

Irrespective of what actexps is doing, let me think some more about calculating the year fraction on a policy versus calendar year basis. Besides the SOA paper, do you know any authoritative papers that get into this sort of thing?

@MatthewCaseres
Copy link
Contributor Author

I'm not aware of any other authoritative resources. If some institution like SOA research institute could provide a dataset and maybe SQL implementation of expected functionality for experience analysis systems like that it would be quite valuable I feel.

I raised a bug on actxps - mattheaphy/actxps#46

Left cols are from Julia, right columns are from R. Nulls on right indicate left join didn't find matches.

Screenshot 2024-06-01 at 10 21 45 AM

@alecloudenback
Copy link
Member

Closed in favor of #24

@mattheaphy
Copy link

Just as a heads up, the example @alecloudenback shared looks odd because no value was passed to the default_status argument in expose(). In practice, default_status is rarely used, but for toy examples like this it can become necessary. This argument represents that status that should be filled in while a policy is active. It defaults to the most common status found in the data itself.

Here's an adjusted version of the example.

library(actxps)
library(dplyr)

census <- tribble(
  ~pol_num, ~status, ~issue_date, ~term_date,
  1, "Death", as.Date("2011-05-27"), as.Date("2012-03-17")
  2, "Death", as.Date("2011-05-27"), as.Date("2012-09-17"))

exposed_cal <-  census |> 
  expose(end_date = "2022-12-31", cal_expo = TRUE, target_status = "Death",
         default_status = "Active")

# output
> expose_split(exposed_cal)

Exposure data

 Exposure type: split_year 
 Target status: Death 
 Study range: 1900-01-01 to 2022-12-31

# A tibble: 5 × 9
  pol_num status issue_date term_date  cal_yr     cal_yr_end pol_yr exposure_cal exposure_pol
    <dbl> <fct>  <date>     <date>     <date>     <date>      <int>        <dbl>        <dbl>
1       1 Active 2011-05-27 NA         2011-05-27 2011-12-31      1        0.6          0.598
2       1 Death  2011-05-27 2012-03-17 2012-01-01 2012-05-26      1        1            0.402
3       2 Active 2011-05-27 NA         2011-05-27 2011-12-31      1        0.6          0.598
4       2 Active 2011-05-27 NA         2012-01-01 2012-05-26      1        0.402        0.402
5       2 Death  2011-05-27 2012-09-17 2012-05-27 2012-12-31      2        0.598        1    

An issue was created in actxps to catch situations where default_status is the same as target_status. mattheaphy/actxps#48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants