Changes for page Guidelines for Confidentiality and Embargo in SDMX
Last modified by Artur K. on 2026/05/29 14:28
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -43,9 +43,11 @@ 43 43 44 44 The data’s CONF_STATUS attribute should be set to “Free (free for publication)”. 45 45 46 -{{box}} SDMX representation47 -* **CONF_STATUS**:F{{/box}}46 +{{box}} 47 +**SDMX representation** 48 48 49 +* **CONF_STATUS**: F 50 +{{/box}} 49 49 50 50 == Use case 2: Confidential data == 51 51 ... ... @@ -68,13 +68,12 @@ 68 68 69 69 The forwarding of confidential data is represented as follows in SDMX: 70 70 71 -|((( 72 -(% class="wikigeneratedid" id="HSDMXrepresentation-1" %) 73 -SDMX representation 73 +{{box}} 74 +**SDMX representation** 74 74 75 75 * **CONF_STATUS**: N; 76 76 * **CONF_REDIST **(Observation, Conditional): [Organisation(s)]; 77 - )))78 +{{/box}} 78 78 79 79 === Adding embargo information to a data message === 80 80 ... ... @@ -89,13 +89,12 @@ 89 89 90 90 If the goal is to allow the data recipient to have privileged access to embargoed observations in a data message (message), the embargoed observation’s CONF_STATUS attribute should be coded as “E: Not for publication until the embargo time expires; free for publication after the embargo time expires.” with an observation level attribute EMBARGO_TIME (date/time/time zone). 91 91 92 -|((( 93 -(% class="wikigeneratedid" id="HSDMXrepresentation-2" %) 94 -SDMX representation 93 +{{box}} 94 +**SDMX representation** 95 95 96 96 * **CONF_STATUS**: E; 97 97 * **EMBARGO**_**TIME** (Observation, Conditional): [timestamp] 98 - )))98 +{{/box}} 99 99 100 100 Including a time zone is strongly recommended and the best case is to use the UTC (Coordinated Universal Time) time standard. However, if no time zone is provided then the time zone of the recipient is assumed. 101 101 ... ... @@ -104,7 +104,7 @@ 104 104 * (Recommended) With UTC indicator: 2017-12-15T14:02:29Z 105 105 * With timezone indicator: 2017-12-15T15:02:29+01:00 106 106 107 - **//Enabling the frontloading of data into systems//**107 +=== //Enabling the frontloading of data into systems// === 108 108 109 109 If the goal is to allow frontloading of a whole data message into systems so that the data can be made visible to users at the expiry of the embargo date/time, the header section of the message should contain an embargo date/time attribute. This implies that all information in the data message is under the embargo date/time set in the header. The header attribute EmbargoDate with format date/time/time zone indicates until when the whole data message received cannot be shared with any recipient users. 110 110 ... ... @@ -112,12 +112,11 @@ 112 112 113 113 Note that this scenario presumes that all data in the message cannot be viewed before the header EmbargoDate, and that there is no privileged access before this time. However, observations may be marked with any other confidentiality status that is valid after the frontloading EmbargoDate elapses. 114 114 115 -|((( 116 -(% class="wikigeneratedid" id="HSDMXRepresentation" %) 115 +{{box}} 117 117 SDMX Representation 118 118 119 119 * **CONF_STATUS**: <Set to the required confidentiality status after the embargo time elapses>; <Header>\<EmbargoDate>: [timestamp] 120 - )))119 +{{/box}} 121 121 122 122 The two ways of representing embargoed data exist to provide efficiency in the exchange, allow for differentiating data intended to be frontloaded and data aimed to be provided in advance to a restricted audience, and provide flexibility when few observations need to be embargoed in a large data message. The trade-off is the complication of system implementation to support the two representations of embargo, which has to be done locally on a case-by-case basis. 123 123 ... ... @@ -125,38 +125,34 @@ 125 125 126 126 In data flows that feature confidential data, CONF_STATUS is highly recommended to be a mandatory attribute. However, if CONF_STATUS is optional in the DSD and missing from an observation, it is always implied to be “F” (free). 127 127 128 -== =Use of the CONF_REDIST attribute ===127 +== Use of the CONF_REDIST attribute == 129 129 130 130 The CONF_REDIST attribute defines the secondary recipient(s) to whom the sender allows the primary recipient to forward confidential data. It is recommended to be an optional attribute at observation level. Ideally it should reference a shared code list containing standard organisation codes. To allow several secondary recipients there are these possibilities: 131 131 132 -Use a code that represents multiple organisations, or; 131 +1. Use a code that represents multiple organisations, or; 132 +1. Use several CONF_REDIST attributes to portray the multiple recipients. Each attribute represents one recipient and references the same codelist. This implementation is cleaner than the above point 1, though this will require adding as many attributes to your DSD as there are potential recipients of the redistributed confidential data. 133 133 134 -Use several CONF_REDIST attributes to portray the multiple recipients. Each attribute represents one recipient and references the same codelist. This implementation is cleaner than the above point 1, though this will require adding as many attributes to your DSD as there are potential recipients of the redistributed confidential data. 135 - 136 136 If the EMBARGO_TIME and CONF_REDIST attributes are both used: 137 137 138 138 1. Data is available only to the organisations in CONF_REDIST until EMBARGO_TIME 139 139 1. Data is available to the public after EMBARGO_TIME 140 140 141 -|(% colspan="3" %)((( 139 +(% style="width:768.957px" %) 140 +|(% colspan="3" style="width:766px" %)((( 142 142 (% class="wikigeneratedid" id="HPrivilegedAccess" %) 143 -Privileged Access 142 +**Privileged Access** 144 144 ))) 145 -|**Use case**|**No forwarding**|**Forwarding** 146 -|**Embargo**|((( 144 +|(% style="width:202px" %)**Use case**|(% style="width:207px" %)**No forwarding**|(% style="width:357px" %)**Forwarding** 145 +|(% style="width:202px" %)**Embargo**|(% style="width:207px" %)((( 147 147 CONF_STATUS: E 148 - 149 149 EMBARGO_TIME 150 -)))|((( 148 +)))|(% style="width:357px" %)((( 151 151 CONF_STATUS: E 152 - 153 153 EMBARGO_TIME 154 - 155 155 CONF_REDIST 156 156 ))) 157 -|**No embargo**|CONF_STATUS: N|((( 153 +|(% style="width:202px" %)**No embargo**|(% style="width:207px" %)CONF_STATUS: N|(% style="width:357px" %)((( 158 158 CONF_STATUS:N 159 - 160 160 CONF_REDIST 161 161 ))) 162 162 ... ... @@ -169,17 +169,15 @@ 169 169 * The national statistical institutes send data to Eurostat, and allow the data to be shared with the ECB for statistical coproduction 170 170 * The data may only be shared with the public on the next day 171 171 172 -**CONF_STATUS:**E**;** 167 +* **CONF_STATUS:**E**;** 168 +* **CONF_REDIST: **ECB**;** 169 +* **EMBARGO_TIME=<**T+1 day**, **e.g.** **2017-12-15T10:00:00Z> 173 173 174 -**CONF_REDIST: **ECB**;** 175 - 176 -**EMBARGO_TIME=<**T+1 day**, **e.g.** **2017-12-15T10:00:00Z> 177 - 178 178 The solutions suggested above aim at covering the most common confidentiality and embargo use cases within a single transmission from the primary reporter to the primary recipient. However, for some more complex scenarios it might still be required to make multiple transmissions. 179 179 180 180 It is strongly recommended that use cases are specified in an agreement between organisations involved in regular transmissions up-front in order to avoid unnecessary delay in data publication or – much worse – confidentiality breaches. 181 181 182 - **Annex 1: SDMX Representation of the confidentiality use cases**175 += Annex 1: SDMX Representation of the confidentiality use cases = 183 183 184 184 |((( 185 185 (% class="wikigeneratedid" id="HUsecase" %) ... ... @@ -274,4 +274,5 @@ 274 274 275 275 ---- 276 276 277 - {{putFootnotes/}} 270 + 271 +{{putFootnotes/}}