Loading...
Help
Login
Busy
Search
eHDSI - Templates
 
Template locked

OK Not OK
Templates (External repositories)

Warning Ok
Warning
Filter
epSOS CDA legalAuthenticator
Issues (4)
Change Request Status = Closed (epsos-issue-158): SignatureCode fixed to "S"
TypeChange RequestStatusChange Request Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2017-05-17 09:20:35: Tracking by Giorgio Cangioli
Description
Added fixed code S
Tracking / Status = Open 2017-04-12 13:38:37: Tracking by Giorgio Cangioli
Description
Finding:

the signatureCode is per the CDA R2 fixed to "S" (X code is deprecated)

Suggestion:

Suggest to modify the vocabulary binding

Further explanation:

-

Change Request Status = Closed (epsos-issue-235): hl7:assignedPerson contains twice the element hl7:name
TypeChange RequestStatusChange Request Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2019-12-23 13:50:17: Tracking by Mathias Ghys
Description
Ticket can be closed since the containment was removed already in V2.2.0 RC1
Tracking / Status = In Progress 2017-10-31 18:09:56: Tracking by Dr. Kai U. Heitmann
Description
The hl7:assignedPerson has a containment and and "overriding" inline definition. This is illegal. It should be either one.
For the hl7:representedOrganization our recommendation is to name the representedOrganization element and the include the template (rather than contain).
The same should be done for hl7:assignedPerson if appropriate.
Tracking / Status = Open 2017-10-31 16:22:06: Tracking by Giorgio Cangioli
Description
Included attributes and elements are explicitly specified by the template: is the containment actually needed here ?
Assignment2017-10-31 15:59:27: Assigned To Christof Gessner by Mathias Ghys
Tracking / Status = Open 2017-10-31 15:59:26: Tracking by Mathias Ghys
Description
Finding:

- hl7:assignedPerson contains 2 hl7:name elements. First one as a direct element, and another from the 2.16.840.1.113883.3.1937.777.11.10.113   CDA Person which it includes. This gives the following excaption in the Gazelle validation tool: 
Test :  CDATEMP002(Validation Level : FLATTEN_4 , Type : FATALERROR) 
Location :  //rules/template[1]/element[1]/element[15]/element[3]/element[4]/element[1] 
CDALocation :  /hl7:ClinicalDocument[hl7:templateId/@root='1.3.6.1.4.1.12559.11.10.1.3.1.1.1']/hl7:legalAuthenticator/hl7:assignedEntity/hl7:assignedPerson/hl7:name 
Description :  An element SHALL have be distinguishable [CDATEMP-002] 

Suggestion:

- Remove one element.

Further explanation:

-

Change Request Status = Closed (epsos-issue-249): Set Telecom element in line with usages in other templates
TypeChange RequestStatusChange Request Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2018-01-05 16:58:21: Tracking by Mathias Ghys
Description
Fixed the Telecom element, but I didn't create a separate Template yet...
Assignment2018-01-05 16:57:30: Assigned To Mathias Ghys by Mathias Ghys
Tracking / Status = Open 2018-01-05 16:57:29: Tracking by Mathias Ghys
Description
Finding:

- Validation errors popped up in the gap analysis done by Abderrazek. Telecom element should be the same everywhere.

Suggestion:

- Change the definition of the telecom element. Maybe it's a good idea to create a new template for the Telecom element and reuse it everywhere?

Further explanation:

-

Change Request Status = Feedback needed (epsos-issue-253): Adapt conformancy of family and given elements conform the EXPAND specifications
TypeChange RequestStatusChange Request Status = Feedback needed PriorityNormal
Events
Tracking / Status = Feedback needed 2018-01-09 12:38:14: Tracking by Christof Gessner
Description
OK. I removed the contain statement.

Note that the intention to make those fields mandatory will fail if not all enclosing elements are also mandatory. Otherwise, the sender can just use a nullFlavor on one of the enclosing levels.
Tracking / Status = Feedback needed 2018-01-09 12:11:44: Tracking by Dr. Kai U. Heitmann
Description
It is now a containment AND an subsequent inline definition.
Suggest to remove the containment and to just leave the subsequent inline definition. If the subsequent inline definition is repeatedly used, follow Giorgio's suggestion also to create a separate template and include it there.
Tracking / Status = Feedback needed 2018-01-09 11:47:35: Tracking by Giorgio Cangioli
Description
It is not clear to me what it has been done...I see for the hl7:assignedPerson both 
AND
  • included elements overlapping that template
I suggest to create a specialization of that template with names mandatory or remove the contains and define explicitly all the needed sub-elements of the assignedPerson 
Tracking / Status = Closed 2018-01-09 11:02:20: Tracking by Christof Gessner
Description
I agree and support this change. In order to make this item mandatory, I also changed the enclosing assignedEntity to mandatory. (That's how I would read the EXPAND specs)

I also added the additional text from the EXPAND specs in the description, in order to support the implementers.
Tracking / Status = Closed 2018-01-09 10:10:08: Tracking by Mathias Ghys
Assignment2018-01-09 10:05:09: Assigned To Mathias Ghys by Mathias Ghys
Tracking / Status = Open 2018-01-09 10:05:08: Tracking by Mathias Ghys
Description
Finding:

- In EXPAND, the elements are defined with conformancy 'R' and not 'RNFA', so in ART-DECOR the conformancy should change to 'M' to be consistent. This issue popped up in the gap analysis

Suggestion:

- change the conformancy

Further explanation:

-

 
 
Busy
Structure Definitions (External repositories)