| | 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 | |