| 96 | == Files == |
| 97 | |
| 98 | All data sets describing one and the same instance of a person entity form a '''file'''. |
| 99 | |
| 100 | For disambiguation, files are sometimes also called '''case'''s. |
| 101 | |
| 102 | === Central Access === |
| 103 | |
| 104 | All data in a file must be accessible from a central point within the application (the "repository"). Especially the following must be implemented: |
| 105 | |
| 106 | - status of the file as a whole |
| 107 | - opening/closing the file for write access |
| 108 | - permanent removal of the file as a whole from the repository |
| 109 | - a directory of all available record types in that file |
| 110 | - export of a file as a whole |
| 111 | - import of a file as a whole |
| 112 | - merging of files |
| 113 | |
| 114 | === File Level Auditing === |
| 115 | |
| 116 | VITA implementations must be able to log all successful attempts to access and/or manipulate data in a file, even if the application does not require auditing. All logs, regardless of their actual granularity, must be available as a function of the file. |
| 117 | |
| 118 | Data which will naturally change over time (e.g. the location of a person) must be version-tracked in such way that they can be reconstructed for any point or interval of time. |
| 119 | |
| 120 | Data which will only change upon administrative measures (e.g. names) do not need to be version-tracked, with the exception of identities. |
| 121 | |
| 122 | ==== Status ==== |
| 123 | |
| 124 | VITA implementations must be able to handle status information of a personal data file as a whole. |
| 125 | |