Loading...
Help
Login
Busy
Search
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
 
 M3 
 
Change RequestCardinality/nullFlavor for address (parts)
Idepsos-issue-52
StatusClosed
PriorityNormal
Last Tracking2017-05-17 14:44:00  by  Giorgio Cangioli
Current AssigneeDr. Kai U. Heitmann
Current Labels
    
 (M3) Milestone 3 
    
Concerns
/
-
/
-

Events
TrackingClosed2017-05-17 14:44:00: Tracking by Giorgio Cangioli
    
 M3 
Description
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
    
 M3 
TrackingOpen2016-03-17 18:16:53: Tracking by Giorgio Cangioli
    
 M3 
Description
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
    
 M1 
Assignment2013-12-02 13:33:24: Assigned To Giorgio Cangioli by Alexander Henket
TrackingOpen2013-12-02 13:31:47: Tracking by Alexander Henket
Description

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"/>
            <city>MILANO</city>
            <country>IT</country>
            <state>ZH</state>
            <city>ROTTERDAM</city>
            <country>NL</country>
            <postalCode nullFlavor="UNK"/>
         </addr>

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.

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