[discussion/brainstorm]: scope of fastreg

[signekb]

There's been some talks in person and on Discord about some more ideas for what this package should cover. Especially in relation to the osdc package, this package could ensure more consistency in the data, so the osdc can be stricter in the expectations of the input data.

E.g., standardising

• data types
• variable casing
• the conversion of the YYWW col?
• other things?

@lwjohnst86 @Aastedet please add to this, so we have an overview of the current ideas 💡

[Aastedet]

I like all these! One thing that is kind of TBD is how LPR_A supersedes LPR_F for LPR3 data without causing duplicates from overlapping years. From what I can gather, we can simply ignore LPR_F (kontakter and diagnoser) and focus on LPR_A. I'm not sure which format(s) of LPR3 data is on DP-Next's project though.

LPR_F is gone, and all LPR3 data/years will come in LPR_A format. For new projects, there's only LPR_A to consider, so there's no issue. However, ongoing projects will already have LPR_F data, and potentially end up with both LPR_F-data for some years, e.g. 2019-2022, and LPR_A-data for 2019-2024.
The cleanest solution seems to be simply ignoring that LPR_F ever existed, since projects using this data will already have data processing pipelines set up and presumably not need to use fastreg. And going forward, all ongoing projects receiving updates to their LPR3 raw data will receive this data as LPR_A for all LPR3 years (as I understand it), regardless of how many of these years are already covered by their previous LPR_F data, so these cases will be able to ignore LPR_F as well.

[lwjohnst86]

I also like these ideas! Especially the date conversions.

[signekb]

@lwjohnst86 Do we want to include functions that:

• Converts YYWW columns to a date?
• Lower case column values?

Or is this outside the scope for now?

[lwjohnst86]

I think thatd be nice! And within scope of making it easier to do faster work with registers