Dates in the file names

[rgouldkc]

We have Third Party administrators that plan to reference the URLS to our In-Network files in what the provide. One of the issues is that generating the In-Network files for our 4 networks is a 52 hour process running non-stop, one network after the other. This results in 4 files with 3 different dates in the file name based on using the current date when the process starts for a given network.

We have been asked to change that and always use the first day of the month the files are for. For example files generated at the end of June for July availability would all use 2022-07-01 as the date in the name instead of 2022-06-28 or 2022-06-29 or 2022-06-30.

What are other organizations doing? Is always using the first day of the next month an issue as far as being in compliance?

[RLTx1391]

Are the TPAs planning to use Table of Contents files referencing your INN files? If so, there's no naming convention for the INN file.

The naming convention section of the read me doesn't really specify the date in the name of the file, but the schema for the INN does include an element that is the date in which the file was last updated.

[rgouldkc]

Based on what they told me I am assuming they are using Table of Contents files. And I realize those files have no naming convention for INN files. Bu we are producing what I consider to be single plan INN files with rates for our 4 networks in 4 separate files with the network name as the file name. To me that means we need to follow the single plan naming standard. What at least one of them will be doing is going to our web site to get the actual URL from our site and using that as the location in their file and apparently it's too difficult for them if the date varies from month to month. Generating all four files takes approximately 52 hours so we end up with 4 files with 3 different dates. And depending on how many days before the end of the month we start and how many days are in the month I do see the complexity for automated processes. And yes I do realize that using our URL effectively makes our repository the storage location for the files and avoids them having to store files from a bunch of networks on their systems. But I have to have them stored in our infrastructure anyway.