Vind hier onze Servicedesk om een verzoek in te dienen m.b.t. onze producten en diensten! Klik hier om toegang aan te vragen of voor andere BITS/Jira gerelateerde vragen en/of opmerkingen.

telecomtype waarom verplicht (1..1) in subbouwsteen contactgegevens

Zorginf. bouwsteen

part.Contactgegevens

Zorginf. bouwsteen (oud)

part.Contactgegevens

Fix versions

Parent

Description

telecomtype is verplicht in de subbouwsteen contactgegevens (1..1)

Dat lijkt wat veelgevraagd, zie ook ZIB-761.

Het onderscheid tussen landline en mobiel nummer bijvoorbeeld is vaak helemaal niet relevant, en we willen - bij conversie vanuit oudere standaarden - niet echt op basis van een nummer match als '06' conclusies trekken. Die route moeten we echt niet op willen.

Voorstel is om telecomtype niet verplicht te stellen, dit wordt nu in HL7v3-standaarden ook vaak niet meegegeven.

Proposed solution (NL)

kardinaliteit TelecomType aanpassen van 1 naar 0..1, maar nog bespreken in Architectuurteam

Release notes (NL)

Kardinaliteit TelecomType aangepast van 1 naar 0..1.

is related to

Activity

Show:

Jeroen Windhorst January 29, 2020 at 9:33 AM

Toegewezen aan Former user t.b.v. bespreken met enkele leden van architectuurteam. 

Jeroen Windhorst September 11, 2019 at 7:44 AM

Klopt, daar heb je gelijk in. Wel zie ik een relatie tot de eerdere discussie.

Arianne van de Wetering September 9, 2019 at 12:48 PM

Het is hier wel een (subtiel) andere vraag: namelijk of de 1..1 terecht is.

Jeroen Windhorst September 9, 2019 at 11:43 AM

Former user Ik zal deze intern bespreken, aangezien een soortgelijke discussie als reeds heeft plaatsgevonden met het architectuurteam (zoals je zelf misschien al had gezien in issue zib-761). Wellicht dat deze discussie opnieuw gevoerd moet worden. Wordt vervolgd.

Resolved
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Classification

Minor (Y)

Components

Priority

Better Excel Exporter

Created September 5, 2019 at 2:49 PM
Updated July 23, 2024 at 2:22 PM
Resolved September 29, 2022 at 2:08 PM