Loading...
Help
Login
Busy
Search
Luxembourg CDA specifications - Template mapping

 
Template locked

OK Not OK
Filter
Datasets
Template Associations
Templates
Concept: Concept 1
Idlux-gh-dataelement-1Version2014-10-01 20:14:43
StatusDraftVersion Label
Description
Value
TypeString
/
-
Templates
Name Id Effective date Element or attribute
CDA Level 1
Issues (7)
For future consideration Status = Closed (lux-gh-issue-3): Representation of Telecom
TypeFor future considerationStatusFor future consideration Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2018-01-04 14:49:40: Tracking by Heiko
Description
Fixed, separated representation of Telecom and added Schematron rule for usage of valueset
Tracking / Status = Open 2017-11-13 13:01:59: Tracking by Heiko
Description
Finding:

- As in Word specification chapter 3.1.2  (Page 29) we have Telecom type explicitely defined, this is not in the Art Decor spec yet

Suggestion:

- Check within Art Decor if this causes additional problems or not. And check if the individual representations of telecom within Art Decor comply to what is written in 3.1.2

Further explanation:

-

For future consideration Status = Closed (lux-gh-issue-10): Template-Ids and header representation
TypeFor future considerationStatusFor future consideration Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2018-01-04 14:51:04: Tracking by Heiko
Description
Decision has been taken to separate the Headers per document, using correct set of TemplateIds
Tracking / Status = Open 2017-12-11 14:16:44: Tracking by Heiko
Description
Finding:

-  The current set of template-ids will cause problems as they mix up to many different id's which have different meaning.

Suggestion:

- Check if we should better have, for sake of clarity, a separate CDA-General Header specification on Header Level Template

Further explanation:

-

Request for Information/Education Status = Open (lux-gh-issue-11): Representation of OID
TypeRequest for Information/EducationStatusRequest for Information/Education Status = Open PriorityNormal
Events
Tracking / Status = Open 2017-12-27 09:18:53: Tracking by Heiko
Description
Finding:

- Constraints on id datataype related to OID and mandatoryness as mentioned within the written spec, seem to be fulfilled by oid type and "R" of root

Suggestion:

- No need for further check constraint, to be tested, nullFlavor test also

Further explanation:

-

For future consideration Status = Closed (lux-gh-issue-12): Check 1.3.182.10.10.1 eSante_DocType (DYNAMIC)
TypeFor future considerationStatusFor future consideration Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2018-01-04 15:13:33: Tracking by Heiko
Description
Verified with EBX Version and committed
Tracking / Status = Open 2017-12-27 09:25:29: Tracking by Heiko
Description
Finding:

- Check if Value Set is valid and up to date

Suggestion:

- Verify with data from EBX https://www.agence-esante.lu/ebx/?onwbpID=c0_L_ebx-manager&onwbpPage=2&requestID=on_select_datas&$functionalCategory=data&$instance=valuesets&$branch=valuesets&$xpath=%2Froot%2FValueSet%5B.%2FinternalID%3D10%5D



Further explanation:

-

For future consideration Status = Closed (lux-gh-issue-13): CE Datatype Displayname and Codesystemname
TypeFor future considerationStatusFor future consideration Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2018-01-04 16:00:21: Tracking by Heiko
Description
Decision has been taken to allow relaxation, so that displayname and codesystemname are not checked
codeSystemIdentifier and code are relevant.
Tracking / Status = Open 2017-12-27 11:27:57: Tracking by Heiko
Description
Finding:

- CE Datatype Displayname and Codesystemname are not checked. This is a difference to our former specification, where we checked and required both.
This applies to different elements like <code>, <confidentialityLevel>, ...

Suggestion:

- Two approaches:
1. Clarify with Abderrazek if we can add this checks automatically
2. Allow relaxation of non using displayName as mandatory, which means then also no check-constraint on that

Further explanation:

- This affects: 
--> 2.3.2
--> 3.4.2
--> 3.4.5

Change Request Status = Closed (lux-gh-issue-14): Add condition on versionNumber
TypeChange RequestStatusChange Request Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2018-01-03 14:18:44: Tracking by Samuel
Description
Done on CDA DSP and ePrescription
Tracking / Status = Open 2017-12-27 12:39:14: Tracking by Heiko
Description
Finding:

- version Number bust be present, if setID is present

Description: ClinicalDocument/setId and ClinicalDocument/versionNumber shall either be given both (and then none shall have @nullFlavor) ,or both shall be omitted


Suggestion:

Further explanation:

-

For future consideration Status = Open (lux-gh-issue-20): nullFlavor value limitations
TypeFor future considerationStatusFor future consideration Status = Open PriorityNormal
Events
Tracking / Status = Open 2017-12-27 14:30:35: Tracking by Heiko
Description
Finding:

- Check for limited value set of nullFlavor 's allowed for elements

Suggestion:

-

Further explanation:

-

 
 
Busy