Help
Login
Busy
Search
Consolidated CDA - Templates

 
Template locked

OK Not OK
Templates (External repositories)

Warning Ok
Warning
Filter
true50
US Realm Header (V3)
false
Issues (9)
false
Change Request Status = Closed ( ccda-issue-66 ): Erratum-808 Incorrect binding change of patient name (change Person Name to Patient Name). CONF:5283
Type Change Request Status Change Request Status = Closed Priority Normal
Events
Tracking / Status = Closed 2017-10-03 19:59:07 : Tracking by Lisa Nelson
Assignment 2017-10-03 06:52:09 : Assigned To dr Kai U. Heitmann by Lisa Nelson
Description
Need to learn the correct way to modify/select the correct change static or dynamic etc.
Assignment 2017-09-18 06:09:56 : Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2017-09-18 06:09:55 : Tracking by Lisa Nelson
Description
Finding:

-Incorrect binding change of patient name (change Person Name to Patient Name).

Suggestion:

-Prior Conformance:

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

1. This patient SHALL contain at least one [1..*] US Realm Person Name (PN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1.1) (CONF:1198-5284).

-Conformance After Update:

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

1. This patient SHALL contain at least one [1..*] US Realm Patient Name (PTN.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.1) (CONF:1198-5283). (CONF:1198-5284)


Further explanation:

-CONF: 1198-5283 (1198-5284)

This errata is actually processed against CONF-5284, not CONF1198-5283

Change Request Status = Closed ( ccda-issue-67 ): Erratum-812 Postal code is restricted to US CONF:10025
Type Change Request Status Change Request Status = Closed Priority Normal
Current Labels
 
 (COND) Conditional Conformance 
Events
Tracking / Status = Closed 2017-10-16 16:54:39 : Tracking by Lisa Nelson
 
 COND 
Tracking / Status = Feedback needed 2017-10-12 19:31:18 : Tracking by Lisa Nelson
 
 COND 
Tracking / Status = In Progress 2017-10-09 22:44:52 : Tracking by Lisa Nelson
Assignment 2017-10-03 06:24:35 : Assigned To dr Kai U. Heitmann by Lisa Nelson
Description
Conditional logic.
Assignment 2017-09-18 06:35:02 : Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2017-09-18 06:35:01 : Tracking by Lisa Nelson
Description
Finding:

-

Suggestion:

-Prior Conformance

5. SHOULD contain zero or one [0..1] postalCode, which SHOULD be selected from ValueSet PostalCode urn:oid:2.16.840.1.113883.3.88.12.80.2 DYNAMIC (CONF:81-7294).

a. PostalCode is required if the country is US. If country is not specified, it's assumed to be US. If country is something other than US, the postalCode MAY be present but MAY be bound to different vocabularies (CONF:81-10025).


-Conformance After Update

5. SHOULD contain zero or one [0..1] postalCode, which SHOULD be selected from ValueSet PostalCode urn:oid:2.16.840.1.113883.3.88.12.80.2 DYNAMIC (CONF:81-7294).

a. If the country is US, the postalCode element is required but SHOULD have @nullFlavor if the postalCode is unknown. If country is not specified, it's assumed to be US. If country is something other than US, the postalCode MAY be present but MAY be bound to different vocabularies (CONF:81-10025).

Further explanation:

CONF:10025

-

Change Request Status = Closed ( ccda-issue-71 ): Erratum-818 Add clarification on state requirement for US addresses. CONF:
Type Change Request Status Change Request Status = Closed Priority Normal
Events
Tracking / Status = Closed 2017-10-30 21:52:04 : Tracking by Lisa Nelson
Assignment 2017-10-27 19:15:35 : Assigned To Didi Davis by Lisa Nelson
Tracking / Status = Feedback needed 2017-10-27 19:15:22 : Tracking by Lisa Nelson
Assignment 2017-10-13 22:28:13 : Assigned To Lisa Nelson by Lisa Nelson
Description
Talk this through with Didi to see if we can manage it, or if we should get guidance from Kai regarding the correct approach.

It looks like Brett just added this as narrative guidance, so I added it as narrative too, but it seems like some machine representation should be attempted.

Note Also:  This should have been attached to the US Realm Address template rather than the US Realm Header template.

Also a question...the pattern for adding the narrative constraint. Should it go in the Description above the label, the description below the label or in a constraint element that takes a narrative description.  They all seem to do the very same thing....which is really nothing in terms of machine validation.

Assignment 2017-10-12 21:30:25 : Assigned To Didi Davis by Lisa Nelson
Assignment 2017-09-28 02:46:48 : Assigned To dr Kai U. Heitmann by Lisa Nelson
Assignment 2017-09-18 06:56:12 : Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2017-09-18 06:56:11 : Tracking by Lisa Nelson
Description
Finding:

-Add clarification on state requirement for US addresses.

Suggestion:

-Prior Conformance - 

3...

a. State is required if the country is US. If country is not specified, it's assumed to be US. If country is something other than US, the state MAY be present but MAY be bound to different vocabularies (CONF:81-10024).

5....

a. PostalCode is required if the country is US. If country is not specified, it's assumed to be US. If country is something other than US, the postalCode MAY be present but MAY be bound to different vocabularies (CONF:81-10025).


-Conformance After Update -

3...

a. If the country is US, the state element is required but SHOULD have @nullFlavor if the state is unknown. If country is not specified, it's assumed to be US. If country is something other than US, the state MAY be present but MAY be bound to different vocabularies (CONF:81-10024).

5...

a. If the country is US, the postalCode element is required but SHOULD have @nullFlavor if the postalCode is unknown. If country is not specified, it's assumed to be US. If country is something other than US, the postalCode MAY be present but MAY be bound to different vocabularies (CONF:81-10025).

Further explanation:
10024, 10025

-

Change Request Status = Closed ( ccda-issue-72 ): Erratum-819 US Realm Address Restricts address to 1 line, update to allow up to 4 CONF:7291
Type Change Request Status Change Request Status = Closed Priority Normal
Events
Assignment 2017-09-29 21:59:22 : Assigned To Didi Davis by Lisa Nelson
Description
Didi, this issue is against the wrong template. It should be on US Realm Address. Can I move it?
Tracking / Status = Closed 2017-09-28 02:32:02 : Tracking by Lisa Nelson
Description
This issue was actually fixed on the US Realm Address (AD.US.FIELDED) template  2.16.840.1.113883.10.20.22.5.2
Assignment 2017-09-18 07:01:13 : Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2017-09-18 07:01:12 : Tracking by Lisa Nelson
Description
Finding:

-US Realm Address Restricts address to 1 line, update to allow up to 4 

Suggestion:

-Prior Conformance
6. SHALL contain exactly one [1..1] streetAddressLine (CONF:81-7291).
-Conformance After Update
6. SHALL contain at least one and not more than 4 streetAddressLine (CONF:81-7291).

Further explanation:

-CONF:7291

Change Request Status = Closed ( ccda-issue-155 ): Erratum-1338 Make it clear that only document type codes are legal for ClinicalDocument.code
Type Change Request Status Change Request Status = Closed Priority Normal
Events
Tracking / Status = Closed 2017-10-16 21:35:16 : Tracking by Lisa Nelson
Assignment 2017-09-29 05:17:17 : Assigned To Didi Davis by Lisa Nelson
Description
Accuracy of Errata Documentation.
Assignment 2017-09-28 21:35:06 : Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2017-09-28 21:35:05 : Tracking by Lisa Nelson
Description
Finding:

-Make it clear that only document type codes are legal for ClinicalDocument.code (i.e. not discrete lab test LOINC codes, which should only be used for observation.code)

Suggestion:

-Prior Conformance:

5. SHALL contain exactly one [1..1] code (CONF:1198-5253).

a. This code SHALL specify the particular kind of document (e.g., History and Physical, Discharge Summary, Progress Note) (CONF:1198-9992).


- Conformance After Update:

5. SHALL contain exactly one [1..1] code (CONF:1198-5253).

a. This code SHALL specify the particular kind of document (e.g., History and Physical, Discharge Summary, Progress Note) (CONF:1198-9992).

b. This code SHALL be drawn from the LOINC document type ontology (LOINC codes where SCALE = DOC) (CONF:1198-32948).


Further explanation:

- (LOOK-up NEW CONF-ID from Trifolia)

Change Request Status = Closed ( ccda-issue-177 ): CS20180125-02 LegalAuthenticator Requiring an NPI id
Type Change Request Status Change Request Status = Closed Priority Normal
Current Labels
 
 (CS) Customer Support 
Events
Tracking / Status = Closed 2018-05-31 22:27:43 : Tracking by Didi Davis
 
 CS 
Description
Verified this issue has been resolved.  Reran the same document and the previous error ccda 21330 no longer fires for the document.  See permanent link where this was verified here:  https://gazellecontent.sequoiaproject.org/EVSClient/detailedResult.seam?type=CDA&oid=1.3.6.1.4.1.12559.11.28.13143
Assignment 2018-01-31 00:47:14 : Assigned To Abderrazek Boufahja by Lisa Nelson
Assignment 2018-01-31 00:44:34 : Assigned To Abderrazek Boufahja by Lisa Nelson
Description
This resolution has been reported to the customer.
Tracking / Status = In Progress 2018-01-31 00:26:17 : Tracking by Lisa Nelson
Description
This issue has been resolved.  The fix is in process and we expect it to be available after February 5th. Please confirm that the changes we have made have addressed the issue you reported.

  Thank you for reporting this issue.

Assignment 2018-01-26 02:51:05 : Assigned To Lisa Nelson by Lisa Nelson
Tracking / Status = Open 2018-01-26 02:51:04 : Tracking by Lisa Nelson
Description
Finding:

-I am seeing an unexpected error when attempting to validate a CCD using the Sequoia C-CDA R2.1 validator.  It is requiring that the legalAuthenticator/assignedEntity/id be an NPI.  However, the C-CDA R2.1 spec only indicates that the id/@root MAY be “2.16.840.1.113883.4.6”.  See info and screenshots below.

 

 

File Name         patient_CCDA_CCD_R2_1_altered.xml

OID :    1.3.6.1.4.1.12559.11.28.1638

Schematron :   N/A (Version N/A)

Schematron Validation Result :            N/A

Validation Date :           1/26/18 12:20:02 AM (CET GMT+0100)

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.1638

Data Visibility : Private - Owned By kstevenson / DOD

 

Submitter: Kent.Stevenson@MariTech.com

Suggestion:

-

Further explanation:

-

Change Request Status = Closed ( ccda-issue-183 ): Suspected bad Constraint
Type Change Request Status Change Request Status = Closed Priority Normal
Current Labels
 
 (CS) Customer Support 
Events
Tracking / Status = Closed 2018-12-05 19:43:11 : Tracking by Didi Davis
 
 CS 
Description
Resolved by Abderrazek 

18/May/18 4:29 PM

https://gazellecontent.sequoiaproject.org/EVSClient/detailedResult.seam?type=CDA&oid=1.3.6.1.4.1.12559.11.28.11902&privacyKey=nFmDmsLs7qqWLiOZ

The error resolved, the example contains authenticator with id with a nullFlavor, and it pass the validation

Tracking / Status = In Progress 2018-04-30 22:25:14 : Tracking by Lisa Nelson
 
 CS 
Description
JIRA Ticket SEQUOIA-63
Tracking / Status = In Progress 2018-02-06 00:05:26 : Tracking by Lisa Nelson
Assignment 2018-02-06 00:05:05 : Assigned To Abderrazek Boufahja by Lisa Nelson
Tracking / Status = Open 2018-02-06 00:05:04 : Tracking by Lisa Nelson
Description
Finding:

-2.16.840.1.113883.10.20.22.1.1 USRealmHeaderV3 CONF:1198-16823

legalAuthenticator.assignedEntity.id (you changed that already) but same seems to be the case with authenticator.assignedEntity.id

 I fixed the id for the authenticator/assignedEntity by unchecking the mandatory flag.

Suggestion:

-

Further explanation:

-

Change Request Status = Closed ( ccda-issue-193 ): CS - Validator not validating correctly
Type Change Request Status Change Request Status = Closed Priority Normal
Current Labels
 
 (CS) Customer Support 
Events
Tracking / Status = Closed 2018-12-05 19:46:36 : Tracking by Didi Davis
 
 CS 
Description

Addressed by Abderrazek 
18/May/18 3:59 PM

https://gazellecontent.sequoiaproject.org/EVSClient/detailedResult.seam?type=CDA&oid=1.3.6.1.4.1.12559.11.28.11896&privacyKey=hnor4vXo3ZXdnEaf

The error fixed but few errors where found (and not found in the previous validation) because we missed to add some restrictions in some valuesets.

Assignment 2018-05-16 23:37:32 : Assigned To Didi Davis by Didi Davis
 
 CS 
Description
Regeneration of the tool will be completed once all updates are made - Date TBD.
Tracking / Status = In Progress 2018-05-16 23:36:01 : Tracking by Didi Davis
 
 CS 
Description

This has been corrected by Didi per instructions from Abderrazek:  The Building Blocks need to be rebuilt to make effective.
SEQUOIA-69 response from Abderrazek on 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.

Assignment 2018-05-14 16:20:34 : Assigned To Lisa Nelson by Didi Davis
 
 CS 
Assignment 2018-04-30 23:06:22 : Assigned To Abderrazek Boufahja by Lisa Nelson
 
 CS 
Description
JIRA Ticket SEQUOIA-69

Note that the Mandatory flag is inconsistent between the R2.1 and R1.1 templates for the administrativeGender element.
Assignment 2018-04-29 22:32:44 : Assigned To Lisa Nelson by Lisa Nelson
 
 CS 
Tracking / Status = Open 2018-04-29 22:32:43 : 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:

-

Change Request Status = In Progress ( ccda-issue-203 ): Missing conformance requirement (CONF:1198-32936)
Type Change Request Status Change Request Status = In Progress Priority High
Current Labels
 
 (CS) Customer Support 
 
 (TOOLING) Tooling questions or issues 
Events
Tracking / Status = In Progress 2018-12-05 21:49:55 : Tracking by Kai Heitmann
 
 CS 
 
 TOOLING 
Description
I understand from your feedback that EVERY template containing a C-CDA 2.1 template id shall contain a second one from 1.1 too? Please confirm that it is not only the US Realm Header...
Anyway, if that is the case, we need to find a way to do this by conversion through all templates. It probably can be done by a proper Xquery.

Tracking / Status = Feedback needed 2018-12-05 21:27:24 : Tracking by Didi Davis
 
 CS 
 
 TOOLING 
Description
So what is happening is that the Gazelle Objects Checker code is generating an error when we feel the spec states it should be allowed and not an error. I will email you the actual document and would be happy to discuss this to explain further with the tooling to show you.  In essence, my discussion with Eric Poisseau and Cedric at IHE Services concluded that the Art Decor model needs to account for the missing conformance that relaxes a. and b. in the text found on page 19 of the IG link referenced in section 3.1.2 to allow a vendor to state compliance to both R1.1 and R2.1 within one document.  Does this help?  
Tracking / Status = Feedback needed 2018-12-05 21:15:33 : Tracking by Kai Heitmann
 
 CS 
 
 TOOLING 
Description
I am not quite sure if I understand this.
Does it mean that for the US Header and only for that another template Id (that of C-CDA R1.1) shall be added?
Assignment 2018-12-05 20:00:55 : Assigned To dr Kai U. Heitmann by Didi Davis
 
 CS 
 
 TOOLING 
Tracking / Status = Open 2018-12-05 20:00:54 : Tracking by Didi Davis
 
 CS 
 
 TOOLING 
Description
Finding:

-It appears that Section 3.1.2 of the CCDA R2.1 May 2018 Implementation Guide an issue where the model is not properly documented to align with the IG.  (http://www.hl7.org/documentcenter/public/standards/dstu/CDAR2_IG_CCDA_CLINNOTES_R1_DSTU2.1_2015AUG_2018MAYwith_errata.zip)

Here is the text from that section for your reference:

Volume 2 of this guide includes a requirement that all C-CDA R2.1 conformant instances: 

  • Include a C-CDA R2.1 templateId, 
  • Additionally, when the C-CDA R2.1 templateId includes an extension, the C-CDA R1.1 templateId must also be included. a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.1.2" (CONF:1198-10038). 
  • b. SHALL contain exactly one [1..1] @extension="2015-08-01" (CONF:1198-32516). 
  • c. When asserting this templateId, all C-CDA 2.1 section and entry templates that had a previous version in C-CDA R1.1 SHALL include both the C-CDA 2.1 templateId and the C-CDA R1.1 templateId root without an extension. See C-CDA R2.1 Volume 1 - Design Considerations for additional detail (CONF:1198-32936).

By including both templateIds the sending application is asserting conformance with C-CDA R2.1 and C-CDA R1.1. This requirement is included at each document template. For example, Continuity of Care Document (CCD) (V3): 

SHALL contain exactly one [1..1] templateId (CONF:1198-8450) such that it 

The US Realm Header does not include an explicit compatability statement to allow reuse in other guides. When using a document template in C-CDA R2.1 it is expected systems will include C-CDA R1.1 and C-CDA R2.1 US Realm Header templateId. 

 It appears this template address a and be above but not c.  I need Kai's help in modeling this in Art Decor
Suggestion:

-Need Kai's help in adding this requirement to Art Decor:

  • When asserting this templateId, all C-CDA 2.1 section and entry templates that had a previous version in C-CDA R1.1 SHALL include both the C-CDA 2.1 templateId and the C-CDA R1.1 templateId root without an extension. See C-CDA R2.1 Volume 1 - Design Considerations for additional detail (CONF:1198-32936). 

  • Further explanation: This should be included as part of the contract you have with IHE Services for support. 

-

 
 
Busy
Structure Definitions (External repositories)