-
Notifications
You must be signed in to change notification settings - Fork 0
/
known-issues.yml
350 lines (327 loc) · 26.6 KB
/
known-issues.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
---
# The issues here are deliberate deviations from the guidelines, as flagged by the qa tooling.
# For each issue documented, a reason for deviating from the guidelines is given.
issues should occur: true
pattern-NlCoreHealthProfessionalReference:
ignored issues:
StructureDefinition:
- message: "Constraint failed: sd-pg-08: 'The title of the StructureDefinition should conform to the profiling guidelines'"
reason: The title is shown in the hosting profiles as the name of the datatype. Since the title according to the profiling guidelines ("pattern NlCoreHealthProfessionalReference") is deemed confusing in some cases, the title is simply "Reference". See https://bits.nictiz.nl/browse/MM-3854.
pattern-ZibHealthProfessionalReference:
ignored issues:
StructureDefinition:
- message: "Constraint failed: sd-pg-08: 'The title of the StructureDefinition should conform to the profiling guidelines'"
reason: The title is shown in the hosting profiles as the name of the datatype. Since the title according to the profiling guidelines ("pattern ZibHealthProfessionalReference") is deemed confusing in some cases, the title is simply "Reference". See https://bits.nictiz.nl/browse/MM-3854.
zib-AbilityToEat.EatingLimitations:
zib deviations:
Observation.value[x]:valueCodeableConcept:
- cardinality: 0..1 instead of 0..*
reason: The value can only occur once, but this profile is referenced 0..* times via .hasMember, making the effective cardinality 0..* as required by the zib.
ext-LanguageProficiency.CommunicationDetails:
zib deviations:
Extension.value[x]:
- cardinality: 0..1 instead of 0..*
reason: FHIR restricts Extension.value to a max cardinality of 0..1. To use it more than once, the extension is added 0..* in the hosting element.
zib-AddressInformation:
zib deviations:
Address.line.extension:houseNumberIndication.value[x]:
- datatype: string instead of CD
reason: The mapping of zib AddressInformation on the FHIR Address datatype is the result of compatibility with HL7v3, which is the format that a lot of healthcare data in the Netherlands is stored in. As a result of this, the zib concept HouseNumberIndication with CD datatype is mapped to a FHIR string datatype.
Address.line.extension:*.value[x]:
- cardinality: 1..1 instead of 0..1
reason: The value of the extension is required, but the extension itself is optional, making the effective cardinality 0..1 as required by the zib.
zib-ContactInformation-TelephoneNumbers:
zib deviations:
ContactPoint.system:
- cardinality: 1..1 instead of 0..1
reason: Although TelecomType and NumberType are optional in the zib, ContactPoint.system is used to identify the TelephoneNumbers concept itself when this datatype is added to a profile. If only a telephone number is given without TelecomType and NumberType, it will fall in the default slice of the sliced element with datatype ContactPoint.
zib-ContactPerson:
zib deviations:
RelatedPerson.name:
- cardinality: 0..* instead of 0..1
reason: The name information according to zib NameInformation may be split up over multiple instances of RelatedPerson.name.
- datatype: HumanName instead of Reference
for: NL-CM:3.1.4 (RelatedPerson.NameInformation)
reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
- datatype: HumanName instead of ST
for: NL-CM:1.1.5 (Payer.PayerName)
reason: A name in FHIR is represented using the HumanName datatype, not as a string.
RelatedPerson.name:nameInformation:
- datatype: HumanName instead of rootconcept
reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
RelatedPerson.telecom:
- cardinality: 0..* instead of 0..1
for: NL-CM:3.1.6 (ContactPerson.ContactInformation)
reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
- datatype: ContactPoint instead of Reference
for: NL-CM:3.1.6 (ContactPerson.ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
- datatype: ContactPoint instead of rootconcept
for: NL-CM:20.6.1 (ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
- cardinality: 0..* instead of 0..1
for: NL-CM:1.1.12 (Payer.ContactInformation)
reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
- datatype: ContactPoint instead of Reference
for: NL-CM:1.1.12 (Payer.ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
RelatedPerson.telecom:*:
- datatype: ContactPoint instead of container
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a BackboneElement.
RelatedPerson.address:
- datatype: Address instead of Reference
for: NL-CM:3.1.5 (ContactPerson.AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
- datatype: Address instead of Reference
for: NL-CM:1.1.17 (Payer.AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
- datatype: Address instead of rootconcept
for: NL-CM:20.5.1 (AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
zib-HealthcareProvider:
zib deviations:
Location.telecom:
- cardinality: 0..* instead of 0..1
reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
- datatype: ContactPoint instead of Reference
for: NL-CM:17.2.6 (HealthcareProvider.ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
- datatype: ContactPoint instead of rootconcept
for: NL-CM:20.6.1 (ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
Location.telecom:*:
- datatype: ContactPoint instead of container
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a BackboneElement
Location.address:
- cardinality: 0..1 instead of 0..*
reason: The cardinality mismatch between the zib (0..*) and FHIR (0..1) is explained by the restriction of FHIR to limit the Location.address to a physical address while the zib allows for other types of addresses (e.g. a postal address). Other types of addresses than a physical address are given in Organization.address which is referenced by Location.managingOrganization.
- datatype: Address instead of Reference
for: NL-CM:17.2.5 (HealthcareProvider.AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
- datatype: Address instead of rootconcept
for: NL-CM:20.5.1 (AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
zib-HealthProfessional-Practitioner:
zib deviations:
Practitioner.name:
- cardinality: 0..* instead of 0..1
reason: The name information according to zib NameInformation may be split up over multiple instances of Practitioner.name.
- datatype: HumanName instead of Reference
reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
Practitioner.name:nameInformation:
- datatype: HumanName instead of rootconcept
reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
Practitioner.telecom:
- cardinality: 0..* instead of 0..1
for: NL-CM:17.1.8 (HealthProfessional.ContactInformation)
reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
- datatype: ContactPoint instead of Reference
for: NL-CM:17.1.8 (HealthProfessional.ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
- datatype: ContactPoint instead of rootconcept
for: NL-CM:20.6.1 (ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
Practitioner.telecom:*:
- datatype: ContactPoint instead of container
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a BackboneElement.
Practitioner.address:
- datatype: Address instead of Reference
for: NL-CM:17.1.7 (HealthProfessional.AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
- datatype: Address instead of rootconcept
for: NL-CM:20.5.1 (AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
zib-HealthProfessional-PractitionerRole:
zib deviations:
PractitionerRole.telecom:
- cardinality: 0..* instead of 0..1
for: NL-CM:17.1.8 (HealthProfessional.ContactInformation)
reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
- datatype: ContactPoint instead of Reference
for: NL-CM:17.1.8 (HealthProfessional.ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
- datatype: ContactPoint instead of rootconcept
for: NL-CM:20.6.1 (ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
PractitionerRole.telecom*:
- datatype: ContactPoint instead of container
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a BackboneElement.
zib-NameInformation:
zib deviations:
HumanName.family.extension:*.value[x]:
- cardinality: 1..1 instead of 0..1
reason: The value of the extension is required, but the extension itself is optional, making the effective cardinality 0..1 as required by the zib.
HumanName.given:
- short: FirstName / Initial
reason: The zib defines both the complete list of first names and of initials as a single string. In FHIR this is done fundamentally different, by using separate names. Hence, the short has been changed to the singular form.
- alias: first name,middle name,Voornaam,Initiaal
reason: The first two initials are provided by FHIR. For the singular form of the latter two, see the remark above.
- cardinality: 0..* instead of 0..1
reason: See the remark above.
HumanName.prefix:
- cardinality: 0..* instead of 0..1
reason: Both prefix and suffix are mapped to the Titles concept from the zib. There's a mismatch however in the way this information is represented in the zib and in FHIR. The mapping is documented in the profile.
HumanName.suffix:
- cardinality: 0..* instead of 0..1
reason: Both prefix and suffix are mapped to the Titles concept from the zib. There's a mismatch however in the way this information is represented in the zib and in FHIR. The mapping is documented in the profile.
zib-NameInformation.GivenName:
zib deviations:
HumanName.given:
- cardinality: 1..* instead of 0..1
reason: The GivenName is optional according to the zib, but when this datatype profile is used, a name should be provided.
zib-Patient:
zib deviations:
Patient.extension:nationality.extension:code.value[x]:
- cardinality: 1..1 instead of 0..1
reason: Zib Nationality is implemented using the complex core extension patient-nationality. The .value[x] element representing the concept Nationality has a 1..1 cardinality, but the "code" part of the extension itself is 0..1, making the cardinality effectively 0..1 as required by the zib.
Patient.name:
- cardinality: 0..* instead of 0..1
reason: The name information according to zib NameInformation may be split up over multiple instances of Patient.name.
- datatype: HumanName instead of Reference
for: NL-CM:0.1.6 (Patient.NameInformation)
reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
- datatype: HumanName instead of ST
for: NL-CM:1.1.5 (Payer.PayerName)
reason: A name in FHIR is represented using the HumanName datatype, not as a string.
Patient.name:nameInformation:
- datatype: HumanName instead of rootconcept
reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
Patient.telecom:
- cardinality: 0..* instead of 0..1
for: NL-CM:0.1.5 (Patient.ContactInformation)
reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
- datatype: ContactPoint instead of Reference
for: NL-CM:0.1.5 (Patient.ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
- datatype: ContactPoint instead of rootconcept
for: NL-CM:20.6.1 (ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
- cardinality: 0..* instead of 0..1
for: NL-CM:1.1.12 (Payer.ContactInformation)
reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
- datatype: ContactPoint instead of Reference
for: NL-CM:1.1.12 (Payer.ContactInformation)
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a separate resource.
Patient.telecom:*:
- datatype: ContactPoint instead of container
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a BackboneElement.
Patient.deceased[x]:deceasedDateTime:
- short: DateOfDeath instead of DateOfDeath / DeathIndicator
reason: This element is mapped to two zib concepts, DateOfDeath and DeathIndicator. However, the latter is implicit; although the zib recognizes both concepts, FHIR supports populating just one of them, thus DeathIndicator is assumed to be 'true' when DateOfDeath is populated. For clarity reasons, the .deceasedDateTime slice has only DateOfDeath mapped to it.
Patient.address:
- datatype: Address instead of Reference
for: NL-CM:0.1.4 (Patient.AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
- datatype: Address instead of Reference
for: NL-CM:1.1.17 (Payer.AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
- datatype: Address instead of rootconcept
for: NL-CM:20.5.1 (AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
Patient.multipleBirth[x]:multipleBirthInteger:
- short: MultipleBirthSequence instead of MultipleBirthSequence / MultipleBirthIndicator
reason: This element is mapped to two zib concepts, MultipleBirthSequence and MultipleBirthIndicator. However, the latter is implicit; although the zib recognizes both concepts, FHIR supports populating just one of them, thus MultipleBirthIndicator is assumed to be 'true' when MultipleBirthSequence is populated. For clarity reasons, the .multipleBirthInteger slice has only MultipleBirthSequence mapped to it.
Patient.contact:
- datatype: BackboneElement instead of rootconcept
reason: The zib ContactPerson _may_ be represented as Patient.contact. There is a different use case as well, where the ContactPerson is implemented using a RelatedPerson resource.
Patient.contact.extension:contactPerson.value[x]:
- datatype: Reference instead of rootconcept
reason: This is an additional reference to a separate zib-ContactPerson (RelatedPerson) instance, next to the information in Patient.contact. Patient.contact and RelatedPerson can both be used to capture the information from zib-ContactPerson, but each are used within a different context. Information may therefore be duplicated; this is the recommended way.
Patient.contact.name:
- datatype: HumanName instead of Reference
for: NL-CM:3.1.4 (ContactPerson.NameInformation)
reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
- datatype: HumanName instead of rootconcept
for: NL-CM:20.4.1 (NameInformation)
reason: A name in FHIR is represented using the HumanName datatype, not as a separate resource.
Patient.contact.telecom:
- cardinality: 0..* instead of 0..1
reason: The cardinality mismatch between the zib (0..1) and FHIR (0..*) is explained by the missing root element of zib ContactInformation in FHIR. Instead, the two containers of the zib (TelephoneNumbers and EmailAddresses), which both have a cardinality of 0..*, are mapped directly into the resource. Thereby this mapping is still honoring the cardinality requirements of the zib.
- datatype: ContactPoint instead of Reference
for: NL-CM:3.1.6 (ContactPerson.ContactInformation)
reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource.
- datatype: ContactPoint instead of rootconcept
for: NL-CM:20.6.1 (ContactInformation)
reason: ContactInformation in FHIR is represented using the ContactPoint datatype, not as a separate resource.
Patient.contact.telecom:*:
- datatype: ContactPoint instead of container
reason: Contact information in FHIR is represented using the ContactPoint datatype, not as a BackboneElement.
Patient.contact.address:
- cardinality: 0..1 instead of 0..*
reason: Patient.contact is a restricted representation of contact persons containing only information needed to contact a contact person. The full address information should be captured using an instance of the zib-ContactPerson profile on RelatedPerson, which can be linked using an extension. This is explained in the profile.
- datatype: Address instead of Reference
for: NL-CM:3.1.5 (ContactPerson.AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
- datatype: Address instead of rootconcept
for: NL-CM:20.5.1 (AddressInformation)
reason: An address in FHIR is represented using the Address datatype, not as a separate resource.
Patient.communication:
- datatype: BackboneElement instead of rootconcept
reason: The appropriate representation of zib LanguageProficiency in FHIR is Patient.communication, not a separate resource.
Patient.communication.extension:languageControl:
- cardinality: 0..* instead of 0..1
reason: Because of the nature of this extension the cardinality has a mismatch. Three zib concepts are mapped to this extension. Therefore the extension cannot be 0..1, but should be able to repeat.
- datatype: Extension instead of CD
reason: The mapping is placed on the extension and not on the .value[x] because of the nature of this extension. The extension itself contains a .valueCoding that is populated with the value of the zib. This datatype matches the zib CD type.
Patient.communication.language:
- cardinality: 1..1 instead of 0..1
reason: The FHIR profiles are expected to implement zib cardinalities as conceptual cardinalities, but FHIR requires the .language element to be present. This aligns with the intention of the zib, as the Language concept is required for zib LanguageProficiency to make sense.
unmapped zib concepts:
- NL-CM:17.2.10: HealthcareProvider.LocationNumber
reason: This zib concept is problematic to map cleanly to FHIR and it has been deemed too uncommon in practice to warrant an extension.
---
# The following issues are not "real" deviations stemming from design choices, but rather problems that pop up due to
# shortcomings in tooling, the used terminology server, etc.
# These might occur in one or more profiles, or in none if they have been fixed in the meantime.
issues should occur: false
zib-ContactInformation-TelephoneNumbers:
zib deviations:
ContactPoint.extension:comment.value[x]:
- cardinality: 0..* instead of 0..1
reason: The cardinality of the extension itself is 0..1, making the effective cardinality 0..1 as required by the zib. It seems the QA tooling does not take into account the cardinality of the extension element itself.
ContactPoint.extension:purpose.value[x]:
- cardinality: 0..* instead of 0..1
reason: The cardinality of the extension itself is 0..1, making the effective cardinality 0..1 as required by the zib. It seems the QA tooling does not take into account the cardinality of the extension element itself.
zib-ContactPerson:
ignored issues:
RelatedPerson.address:
- message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
reason: The short description is defined on the datatype profile and is not repeated in the differential.
- message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
reason: The alias is defined on the datatype profile and is not repeated in the differential.
zib-HealthcareProvider:
ignored issues:
Location.address:
- message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
reason: The required short description is given by the datatype profile, so it is absent from the differential.
- message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
reason: The required alias is given by the datatype profile, so it is absent from the differential.
zib-HealthProfessional-Practitioner:
ignored issues:
Practitioner.address:
- message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
reason: The required short description is given by the datatype profile, so it is absent from the differential.
- message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
reason: The required alias is given by the datatype profile, so it is absent from the differential.
zib-NameInformation:
zib deviations:
HumanName.extension:nameUsage.value[x]:
- cardinality: 0..* instead of 0..1
reason: The cardinality of the extension itself is 0..1, making the effective cardinality 0..1 as required by the zib. It seems the QA tooling does not take into account the cardinality of the extension element itself.
zib-Patient:
ignored issues:
Patient.address:
- message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
reason: The short description is defined on the datatype profile and is not repeated in the differential.
- message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
reason: The alias is defined on the datatype profile and is not repeated in the differential.
Patient.contact.name:
- message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
reason: The short description is defined on the datatype profile and not repeated in the differential.
- message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
reason: The alias is defined on the datatype profile and not repeated in the differential.
Patient.contact.address:
- message: "Constraint failed: sd-pg-02: 'If mapping.map exists and the mapping is not implicit, short should exist'"
reason: The short description is defined on the datatype profile and not repeated in the differential.
- message: "Constraint failed: sd-pg-04: 'If mapping.map exists and the mapping is not implicit, alias should exist.'"
reason: The alias is defined on the datatype profile and not repeated in the differential.