epSOS - Issues
Select object
Results (1 / 1)
Id Issue Status Priority Type Date Assigned To Label
52Cardinality/nullFlavor for address (parts)ClosedNormalChange Request2017-05-17 14:44:00Dr. Kai U. Heitmann
Change RequestCardinality/nullFlavor for address (parts)
Last Tracking2017-05-17 14:44:00  by  Giorgio Cangioli
Current AssigneeDr. Kai U. Heitmann
Current Labels
 (M3) Milestone 3 

TrackingClosed2017-05-17 14:44:00: Tracking by Giorgio Cangioli
This is handled by the AD.EPSOS specialization of the AD datatype
Assignment2016-03-17 18:17:37: Assigned To Dr. Kai U. Heitmann by Giorgio Cangioli
TrackingOpen2016-03-17 18:16:53: Tracking by Giorgio Cangioli
The cardinality of the parts of the addresses seems now to be 0..

However the current description does not allow the validation of the condition that at least one element shall be provided if the address is not nullflavored. 

TrackingOpen2015-11-18 12:58:48: Tracking by Giorgio Cangioli
Assignment2013-12-02 13:33:24: Assigned To Giorgio Cangioli by Alexander Henket
TrackingOpen2013-12-02 13:31:47: Tracking by Alexander Henket

In "epSOS_D3.9.1_Appendix_B1_B2_Implementation_v1.4_20110725.pdf" it would appear that addresses are overstated and suffer from some copy/paste problems. You are currently required to either state no address parts or every single mentioned address part with either a value or a nullFlavor (not stated which nullFlavor). Also every address part may appear 1..* R, including city, state, and country. This leads to fragments like:

         <addr use="H">
            <state nullFlavor="NI"/>
            <postalCode nullFlavor="UNK"/>

I.e. multiple types of NULL and multiple colliding address parts. What is the reason behind this? Any addr specification we have encountered in any context has said that unknown address(parts/es) should just be omitted, and with the exception of streetAddressLine no other parts should be use more than once.

PreviewCodeHTML colorDisplay NameDescription
TBATBATo be approved
To be discussed and approved
M1M1Milestone 1
Milestone 1 – before the EXPAND-athon 9-12 December 2015 Lisbon
M2M2Milestone 2
Milestone 2 – final results to be delived at the end of EXPAND
M3M3Milestone 3
Milestone 3 – end of the HL7 International Project
M4M4Milestone 4
Milestone 4 – for consideration in the future / desiderata
WJWJChanges Word/JIRA
Changes in the Word Specification/Open a JIRA issue
Template-ID changes throughout the specification