nl-core-contactpoint contains invalid slicing definitions on multiple levels
Description
Verduidelijking van Impact
Proposed solution (NL)
ContactPoint.system.extension(code-specification) en ContactPoint.use.extension(code-specification) verwijderen.
Drie nieuwe extensies toevoegen ContactPoint.extension(email-address-type), ContactPoint.extension(telecom-type) en ContactPoint.extension(number-type) met elk een enkelvoudige binding op de relevante waardelijst uit de zib Contactgegevens. Dit voorkomt slicing buiten de extensie url. Het levert een volkomen eenduidige mapping op die daardoor ook eenvoudiger te implementeren zal zijn.
Nadeel: het is niet backwards compatible.
Proposed solution (EN)
Release notes (NL)
To aid in a simpler HCIM mapping, the code-specification extensions on the .system and .use element in the nl-core-contactpoint profile where removed and replaced by one new extension: TelecomType. The usage of this extension and the corresponding mapping are added to the profile definition. Also changed the obsolete HCIM term 'TelecomSoort' in the profile and ConceptMaps to the now used 'TelecomType'.
Release notes (EN)
Attachments
is related to
Activity
Niek van Galen July 23, 2020 at 10:35 AM
Wijzigingen zijn doorgevoerd in de ConceptMaps, tevens vermelding in de releasenotes toegevoegd.
Pieter Edelman July 21, 2020 at 11:27 AM
Als onderdeel van dit issue zijn er 2 ConceptMaps gevonden die 'TelecomSoort...' in de naam hebben. Dit bestaat niet (meer) in de zibs, dat moet TelecomType zijn. Dan verandert logischerwijs ook de canonical van de ConceptMap. Naar mijn mening is dit geen probleem, een ConceptMap is alleen informatief. Het moet wel vermeld worden in de release notes.
Niek van Galen July 21, 2020 at 11:07 AMEdited
naar mijn mening hoeven deze qua mapping niet te worden aangepast. De ConceptMaps gaan immers over de mapping naar de FHIR-core-elementen .system en .use en die mappings wijzigen niet.
Ik heb wel wat spelfoutjes gevonden, die pas ik aan.
Nabrander: ik zie dat de laatste 2 ConceptMaps 'TelecomSoort...' in de naam hebben. Dit bestaat niet (meer) in de zibs, dat moet TelecomType zijn. Kunnen we natuurlijk aanpassen, maar dan verandert logischerwijs ook de canonical van de ConceptMap mee. Anders dan dat we goed moeten kijken waar die canonical voorkomt (in bv profielen) lijkt het met niet zo'n probleem. Wat denk jij Former user?
Vincent Goris July 21, 2020 at 9:56 AMEdited
De bestaande conceptmaps moeten ook aangepast worden denk ik. Momenteel bestaan er 5 die hier betrekking op hebben:
conceptmap-EmailSoortCodelijst-to-ContactPointSystem
conceptmap-EmailSoortCodelijst-to-ContactPointUse
conceptmap-NummerSoortCodelijst-to-ContactPointUse
conceptmap-TelecomSoortCodelijst-to-ContactPointSystem
conceptmap-TelecomSoortCodelijst-to-ContactPointUse
Niek van Galen July 17, 2020 at 11:16 AM
HCIM | .ext:TelecomType | .system | .use |
Primary Home Land Line/Telefoonnummer thuis Vast telefoonnummer | LL | phone | home |
Temporary Land Line/Tijdelijk telefoonnummer Vast telefoonnummer | LL | phone | temp |
Primary Work Land Line/Zakelijk telefoonnummer Vast telefoonnummer | LL | phone | work |
|
|
|
|
Primary Home Fax/Telefoonnummer thuis Fax | FAX | fax | home |
Temporary Fax/Tijdelijk telefoonnummer Fax | FAX | fax | temp |
Primary Work Fax/Zakelijk Telefoonnummer Fax | FAX | fax | work |
|
|
|
|
Primary Home Mobile Phone/Telefoonnummer thuis Mobiel telefoonnummer | MC | phone | home |
Temporary Mobile Phone/Tijdelijk telefoonnummer Mobiel telefoonnummer | MC | phone | temp |
Primary Work Mobile Phone/Zakelijk telefoonnummer Vast telefoonnummer | MC | phone | work |
|
|
|
|
Primary Home Pager/Telefoonnummer thuis Pieper | PG | pager | home |
Temporary Pager/Tijdelijk telefoonnummer Pieper | PG | pager | temp |
Primary Work Pager/Zakelijk telefoonnummer Pieper | PG | pager | work |
|
|
|
|
Private email address/Prive e-mailadres |
| home | |
Work email address/Zakelijk e-mailadres |
| work |
Details
Assignee
Niek van GalenNiek van GalenReporter
Job Schipper (Medicore)Job Schipper (Medicore)Classification
Major (X)Informatiestandaard onderdelen
FHIR-packageInformation standard
AlleFix versions
Priority
High
Details
Details
Assignee
Niek van GalenReporter
Job Schipper (Medicore)Classification
Informatiestandaard onderdelen
Information standard
Fix versions
Priority
HighBetter Excel Exporter
Export Excel
Better Excel Exporter
Export Excel
Better Excel Exporter
nl-core-contactpoint heeft op meerdere niveau's ongeldige slicingdefinities omdat op 3 plaatsen meerdere malen dezelfde extensie code-specification voorkomt, maar de slices verder niet uit elkaar worden gehouden. In tegenstelling tot nl-core-address is deze niet eenvoudig op telossen omdat de waardelijsten in iedere slice, overlappende codesystemen hebben. Wellicht is hier een waardelijst die op ieder niveau de waardelijsten op dat niveau importeert een oplossing. Dit behoudt de notie van separate waardelijsten zoals de zib die heeft, zonder de noodzaak te introduceren om nog een slice op basis van waardelijst te introduceren.
Toevoeging 23-06:
Als ik kijk naar:
nl-core-contactpoint.use.extension.EmailAddressTypeCodelist.valueCodeableConcept zie ik dat die verwijst naar binding TelecomSoortCodelijst -> https://simplifier.net/NictizSTU3-Zib2017/2.16.840.1.113883.2.4.3.11.60.40.2.20.6.1--20171231000000
Zou het kunnen dat dit de verkeerde binding is? Ik verwachtte een binding voor EmailSoortCodelijst:
https://zibs.nl/wiki/Contactgegevens-v1.0(2017NL)#EmailSoortCodelijst