Loading...
Help
Login
Busy
Search
Consolidated CDA (Sequoia) - Templates
 
Template locked

OK Not OK
Templates (External repositories)

Warning Ok
Warning
Filter
US Realm Header
Issues (6)
Change Request Status = Closed (ccda-issue-16): Erratum-229 C-CDA cannot represent multiple patient names (CONF-5284)
TypeChange RequestStatusChange Request Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2017-08-23 14:55:03: Tracking by Lisa Nelson
Description
Updated title of issue to include the affected CONF#
Tracking / Status = Closed 2017-08-23 14:52:33: Tracking by Lisa Nelson
Description
The change appears to have been made already.
Tracking / Status = In Progress 2017-08-23 14:51:38: Tracking by Lisa Nelson
Tracking / Status = Open 2017-08-23 14:49:17: Tracking by Lisa Nelson
Description
Finding:

-C-CDA cannot represent multiple patient names such as alias / maiden name because it is restricted to a single patientRole with a single US Realm name element. Suggestions have been posed which use multiple 'given' attributes, but these are misleading since a maiden name is a family name, not a given name (plus, conformance statement 7163 states the 2nd given name SHALL be the middle name or initial).


C83 allowed for (and recommended) multiple name elements, so CCDA should likewise allow multiple name elements.

Suggestion:

-Prior Constraints:

iv. This patientRole SHALL contain exactly one [1..1] patient (CONF:5283).

1. This patient SHALL contain exactly one [1..1] name (CONF:5284).

...Down in US Realm Patient Name, it ...

2. SHALL contain exactly one [1..1] family (CONF:7159).

-Constraints After the Change:

iv. This patientRole SHALL contain exactly one [1..1] patient (CONF:5283).

1. This patient SHALL contain at least one [1..*] name (CONF:5284).

a. The content of name SHALL be a conformant US Realm Patient Name (PTN.US.FIELDED) (2.16.840.1.113883.10.20.22.5.1) (CONF:10411).

Further explanation:

- CONF-5284

Change Request Status = Closed (ccda-issue-17): Erratum-275 Clarify how to model multiple race codes (CONF:5322, CONF-7263)
TypeChange RequestStatusChange Request Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2017-09-10 03:37:51: Tracking by Lisa Nelson
Description
Adding a note is just a description.
Assignment2017-08-30 18:44:21: Assigned To dr Kai U. Heitmann by Lisa Nelson
Assignment2017-08-28 22:24:21: Assigned To Abderrazek Boufahja by Lisa Nelson
Tracking / Status = Feedback needed 2017-08-28 22:24:12: Tracking by Lisa Nelson
Description
Reviewed on 8/28/ TCON.

We would like to review all gray option available from the gear tool.
Need to know how to add a note.
Assignment2017-08-23 19:17:28: Assigned To Didi Davis by Lisa Nelson
Description
Need to learn how to add a "note" to a conformance constraint.
Tracking / Status = Feedback needed 2017-08-23 19:16:39: Tracking by Lisa Nelson
Description
The conformance constraints appear to be accurate, but we need to learn how to add a "Note:" 
Tracking / Status = In Progress 2017-08-23 18:56:19: Tracking by Lisa Nelson
Tracking / Status = Open 2017-08-23 18:54:50: Tracking by Lisa Nelson
Description
Finding:

-Conformance statements 5322 & 7263 should be clarified regarding how to model multiple race codes.

Suggestion:

-Prior Conformance Statements:

6.This patient MAY contain zero or one [0..1] raceCode, which SHALL be selected from ValueSet Race ... (CONF:5322)

7.This patient MAY contain zero or more [0..*] sdtc:raceCode, where the @code SHALL be selected from ValueSet Race ... (CONF:7263}

Conformance Statements After Update:

6. This patient MAY contain zero or one [0..1] raceCode, which SHALL be selected from ValueSet Race urn:oid:2.16.840.1.113883.1.11.14914 DYNAMIC (CONF:5322).

Note: To record additional raceCode, use the extension element sdtc:raceCode.

7. This patient MAY contain zero or more [0..*] sdtc:raceCode, which SHALL be selected from ValueSet Race urn:oid:2.16.840.1.113883.1.11.14914 DYNAMIC (CONF:7263).

Further explanation:

-CONF:5322, CONF:7263

Change Request Status = Closed (ccda-issue-19): Erratum-346 Add guidance for how to record an unknown NPI (CONF:5449)
TypeChange RequestStatusChange Request Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2017-09-13 03:16:01: Tracking by Lisa Nelson
Description
We copied the solution from the newer version of the template. Note we fixed a broken assert by turning it into a literal constraint.
Assignment2017-08-28 23:06:14: Assigned To dr Kai U. Heitmann by Lisa Nelson
Tracking / Status = Feedback needed 2017-08-28 23:05:57: Tracking by Lisa Nelson
Description
Reviewed in TCON on 8/28 . We need to show this to Kai and see what happened to this constraint CONF:16786.  We can't seem to find it in the spec.

i.      This assignedAuthor SHALL contain exactly one [1..1] id (CONF:5449) such that it

1.   SHALL contain exactly one [1..1] @root (CONF:16786).

a.    If this assignedAuthor is an assignedPerson the assignedAuthor id SHALL contain exactly one [1..1] @root="2.16.840.1.113883.4.6" National Provider Identifier (CONF:19521).

ALSO - where does the CONF:32882 - CONF:32885 come from. 

Tracking / Status = Feedback needed 2017-08-25 14:23:21: Tracking by Lisa Nelson
Tracking / Status = In Progress 2017-08-25 14:22:53: Tracking by Lisa Nelson
Description
Conformance numbers in the errata description don't match quite right in the [After update] information.  Could it be that this information is mixing up conformance numbers from R1.1 and R2.1.  Something isn't making sense because the CONF:5449 seems to be right, but the other CONF numbers don't exist.  

Looks like we are missing the statement about (CONF:1198-32885).

Something seems seriously wrong.  The conditional aspect of the IF author is a person and iF id is with root for NPI.  I don't see how this is to be addressed.

 

- Conformance Statements After Update

If this assignedAuthor is an assignedPerson


ii. This assignedAuthor SHOULD contain zero or one [0..1] id (CONF:1198-32882) such that it

If id with @root="2.16.840.1.113883.4.6" National Provider Identifier is unknown then

1. MAY contain zero or one [0..1] @nullFlavor="UNK" Unknown (CodeSystem: HL7NullFlavor urn:oid:2.16.840.1.113883.5.1008) (CONF:1198-32883).

2. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-32884).

3. SHOULD contain zero or one [0..1] @extension (CONF:1198-32885).

Tracking / Status = In Progress 2017-08-23 20:46:28: Tracking by Lisa Nelson
Assignment2017-08-23 20:46:08: Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2017-08-23 20:46:07: Tracking by Lisa Nelson
Description
Finding:

-Add guidance for how to record an unknown NPI. 

Suggestion:

-Prior Conformance Statements:

I. This assignedAuthor SHALL contain exactly one [1..1] id (CONF:5449) such that it


  1.SHALL contain exactly one [1..1] @root="2.16.840.1.113883.4.6" National Provider 

  Identifier (CONF:16786).

- Conformance Statements After Update

If this assignedAuthor is an assignedPerson


ii. This assignedAuthor SHOULD contain zero or one [0..1] id (CONF:1198-32882) such that it

If id with @root="2.16.840.1.113883.4.6" National Provider Identifier is unknown then

1. MAY contain zero or one [0..1] @nullFlavor="UNK" Unknown (CodeSystem: HL7NullFlavor urn:oid:2.16.840.1.113883.5.1008) (CONF:1198-32883).

2. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.4.6" National Provider Identifier (CONF:1198-32884).

3. SHOULD contain zero or one [0..1] @extension (CONF:1198-32885).

Further explanation:

- CONF:5449

Change Request Status = Closed (ccda-issue-33): Erratum 693 Update to allow nullFlavor on performer type
TypeChange RequestStatusChange Request Status = Closed PriorityNormal
Events
Tracking / Status = Closed 2017-11-08 17:35:11: Tracking by Lisa Nelson
Assignment2017-09-05 22:53:31: Assigned To Abderrazek Boufahja by Lisa Nelson
Tracking / Status = Feedback needed 2017-09-05 22:51:27: Tracking by Lisa Nelson
Description
This needs to have an Assert Test added.
Assignment2017-09-01 20:35:33: Assigned To dr Kai U. Heitmann by Lisa Nelson
Tracking / Status = Feedback needed 2017-09-01 20:35:25: Tracking by Lisa Nelson
Description
See spreadsheet tab 693 for further details and questions.
Assignment2017-08-30 12:41:57: Assigned To Didi Davis by Lisa Nelson
Tracking / Status = Feedback needed 2017-08-30 12:41:39: Tracking by Lisa Nelson
Description
The CONF numbers don't line up.  I don't see the constraints identified as what the Conformation Statements look like "Prior to Change". What is the right action to apply here?
Tracking / Status = In Progress 2017-08-30 12:35:31: Tracking by Lisa Nelson
Tracking / Status = Open 2017-08-30 12:35:11: Tracking by Lisa Nelson
Description
Finding:

-Update US Realm Header to allow nullFlavor on peformer type

Suggestion:

-Conformance Statements Prior to Change:

US Realm Header

[ClinicalDocument: templateId 2.16.840.1.113883.10.20.22.1.1(open)]


This assignedEntity SHOULD contain zero or one [0..1] code (CONF:14842).

i.The code, if present, SHALL contain exactly one [1..1] @code, which SHOULD be selected from CodeSystem NUCCProviderTaxonomy (2.16.840.1.113883.6.101) (CONF:14843).

Conformance Statements After Update:
b. This assignedEntity SHOULD contain zero or one [0..1] code, which SHOULD be selected from CodeSystem Healthcare Provider Taxonomy (HIPAA) (urn:oid:2.16.840.1.113883.6.101) DYNAMIC (CONF:14842).

Further explanation:

-CONF:7731, 8309, 8304, 8254

Change Request Status = In Progress (ccda-issue-188): CS-20180326- Validation too tight on Ustructured Document
TypeChange RequestStatusChange Request Status = In Progress PriorityNormal
Current Labels
 
 (CS) Customer Support 
Events
Assignment2018-07-02 23:45:59: Assigned To Didi Davis by Didi Davis
 
 CS 
Tracking / Status = In Progress 2018-07-02 23:45:31: Tracking by Didi Davis
 
 CS 
Description
This issue should have been logged to R1.1 2013-01-31 version of template.  This was corrected   in ART-DECOR the cardinality to 1..* ; this needs to remain in progress until validation tool is regenerated by rebuilding the building blocks. 
Tracking / Status = Open 2018-05-30 21:51:37: Tracking by Didi Davis
 
 CS 
Description

From JIRA - Abderrazek Boufahja

Friday May 25, 2018 4:49 PM

In ART-DECOR we define that the author have the cardinality 1..1. The validation tool created the check accordingly. If we want to have more than one author per document, sequoia need to update in ART-DECOR the cardinality to 1..* ; and then we regenerate the validation tool.

Assignment2018-05-25 16:56:01: Assigned To Abderrazek Boufahja by Didi Davis
 
 CS 
Tracking / Status = Open 2018-05-25 16:55:48: Tracking by Didi Davis
 
 CS 
Description

Abderrazek requested additional information including the testing permanent link.  Didi added the following to the JIRA ticket on 5/25/18. 

The issue reported referenced this permanent link:
https://gazellecontent.sequoiaproject.org/EVSClient/detailedResult.seam?type=CDA&oid=1.3.6.1.4.1.12559.11.28.11125

  • I am seeing an unexpected error when attempting to validate an Unstructured Document using the Sequoia C-CDA R1.1 validator. It is not allowing multiple <author> attributes. The constraint the validator indicates is being violated states that there can be only a single author/assignedAuthor in an <author> element, but doesn’t limit the document to only having a single <author> element.

However, the validator is enforcing only a single <author> element rather than a single <assignedAuthor> element.

Assignment2018-04-30 22:26:03: Assigned To Lisa Nelson by Lisa Nelson
 
 CS 
Description
JIRA ticket SEQUOIA-60
Tracking / Status = Open 2018-03-26 23:13:30: Tracking by Lisa Nelson
 
 CS 
Description
Added a label.
Tracking / Status = Open 2018-03-26 18:02:29: Tracking by Lisa Nelson
Description
I can't even find Conf-7640 in the Unstructured document of the US Realm header....not sure where this error is coming from.
Assignment2018-03-26 17:57:08: Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2018-03-26 17:57:07: Tracking by Lisa Nelson
Description
Finding:

-The constraint indicated requires that the <author> element have exactly one <assignedAuthor> child element (the US Realm Clinical Docment Header :

Suggestion:

-However, the validator is enforcing only a single <author> element rather than a single <assignedAuthor> element.

Further explanation:

-

Change Request Status = In Progress (ccda-issue-192): CS - Validator not validating correctly
TypeChange RequestStatusChange Request Status = In Progress PriorityNormal
Current Labels
 
 (CS) Customer Support 
Events
Tracking / Status = In Progress 2018-05-17 00:16:50: Tracking by Didi Davis
 
 CS 
Description
SEQUOIA-69 in progress
Assignment2018-05-17 00:15:25: Assigned To Didi Davis by Didi Davis
 
 CS 
Description
This is related to Issue #193 in ART DECOR and SEQUOIA-69 in JIRA.  Didi to verify with Abderrazek that regenerating the tool will correct the NULL issue as well as not changes were made to R1.1 template.  Per issue #193, R2.1 template administrativeGender was updated to required from mandatory. 
Assignment2018-05-14 16:22:39: Assigned To Lisa Nelson by Didi Davis
 
 CS 
Tracking / Status = Open 2018-05-14 16:19:34: Tracking by Didi Davis
 
 CS 
Description

JIRA update from Abderrazek - May 14, 2018:

The definition in ART-DECOR is wrong in C-CDA 2.1 indeed:  https://gazellecontent.sequoiaproject.org/art-decor/decor-templates--ccda-?section=templates&id=2.16.840.1.113883.10.20.22.1.1&effectiveDate=2015-08-01T00:00:00&language=en-US

In administrativeGender you need to update mandatory with required , after that we need to regenerate the validation tool. I though that sequoia is managing these kind of modifications in ART-DECOR, and I remark that this modification is still not performed. Modifications in ART-DECOR should not ber performed by Gazelle team in order to keep consistency for sequoia.

Mail Attachment.png Mail Attachment.png
Assignment2018-04-30 23:04:13: Assigned To Abderrazek Boufahja by Lisa Nelson
 
 CS 
Description
JIRA Ticket SEQUOIA-69
Assignment2018-04-30 23:01:55: Assigned To Abderrazek Boufahja by Lisa Nelson
 
 CS 
Description
The language in C-CDA Volume 1 in chapter 3.6  says,

Any SHALL, SHOULD or MAY conformance statement may use nullFlavor, unless the nullFlavor is explicitly disallowed (e.g., through another conformance statement which includes a SHALL conformance for a vocabulary binding to the @code attribute, or through an explicit SHALL NOT allow use of nullFlavor conformance).

We think the validation behavior needs to take this rule into consideration.

Also note, the Mandatory Flag is set in the R2.1 template version which is inconsistent with the R1.1 template.  This also needs to be looked at.
Assignment2018-04-30 22:47:28: Assigned To Abderrazek Boufahja by Lisa Nelson
 
 CS 
Assignment2018-04-29 22:32:00: Assigned To Lisa Nelson by Lisa Nelson
 
 CS 
Tracking / Status = Open 2018-04-29 22:31:59: Tracking by Lisa Nelson
 
 CS 
Description
Finding:

-Stevenson, Kent J <Kent.Stevenson@ManTech.com>
Thu 4/26/2018 12:57 PM

I am seeing an unexpected error when attempting to validate an Unstructured Document using the Sequoia C-CDA R1.1 validator.  It is not allowing the use of nullFlavor for/ClinicalDocument/recordTarget/patientRole/patient/administrativeGenderCode.  The constraint the validator indicates is being violated doesn’t say that nullFlavor cannot be used.  Rather, it says that administrativeGenderCode element is required and must use the Administrative Gender (HL7 V3) value set.  In section 3.6 of C-CDA R2.1 it states that unless nullFlavor is specifically prohibited or unless the terminology binding is to the @code attribute, a nullFlavor is allowed for required elements.  The nullFlavor is not specifically prohibited for administrativeGenderCode and the terminology binding is to the element, not the @code attribute—so the use of nullFlavor should be allowed.

 

File Name  patient1666580073_34133-9_2.16.840.1.113883.3.198^1666580073_34133-9_BFD....xml

OID : 1.3.6.1.4.1.12559.11.28.11289

Schematron : N/A (Version N/A)

Schematron Validation Result : N/A

Validation Date : 4/25/18 4:14:49 PM (CEST GMT+0200)

Model Based Validator : HL7 - C-CDA R2.1 - Meaningful Use Stage 3 (Version N/A)

Model Based Validation Result : FAILED   SC

Permanent link : https://gazellecontent.sequoiaproject.org/EVSClient/detailedResult.seam?type=CDA&oid=1.3.6.1.4.1.12559.11.28.11289

Data Visibility : Public


Suggestion:

- The validator is not producing the correct behavior.  The assessment provided by the submitter is an accurate assessment of the validation expectations.

Further explanation:

-

 
 
Busy
Structure Definitions (External repositories)