We are exchanging CCDs over an HIE. While consuming a CCD from a particular partner, we are having issues parsing the dates provided in the CCD. Most often, we cannot process the effectiveTime in various sections of the CCD.
We have been told that our partner is using a C-CDA conformant CCD. The CCD parser on our side cannot handle any of the effectiveTime values which contain milliseconds, such as:
Our vendor informed us that:
“The schema you referenced (for a CCD) is the general data type specification for CDA. There are additional implementation documents that further constrain the data that should be reported. For example, the sections shown below are from the HL7 Implementation Guide for Consolidated CDA Release 1.1. As you can see, a US Realm date/time field (which includes the ClinicalDocument/effectiveTime element) allows for precision to the second.
The guides for other CCD implementations – C32, C-CDA R2.0, etc. – include identical constraints for /ClinicalDocument/
effectiveTime. These constraints are the basis for our assertion that milliseconds are not acceptable in ClinicalDocument/ effectiveTime/@value.”
The schemas provided for C-CDA and CDA do allow for a milliseconds value, according to their RegEx pattern. The CCDA schematrons have notes that specify:
The content of time SHALL be a conformant US Realm Date and Time (DTM.US.FIELDED) (2.16.840.1.1138184.108.40.206.5.
Even though the schematron may not have the checks to flag a millisecond value, they do make that statement, which does not allow for milliseconds.
Please provide guidance on whether milliseconds are acceptable in C-CDAs and/or CCDs. If milliseconds are not allowed, then why don’t the schemas/schematrons trigger errors when millisecond values are found?
Firstly, some background: The CDA schema is a general schema that applies to all use of the CDA specification anywhere. So the schema allows milliseconds. CCDA is a specification that builds on CDA to make further restrictions. Most of these can’t be stated in schema (because schema does not allow for different content models for elements with the same name). So these extra constraints are made as schematron, so they can also be tested for CCDA documents.
The CCDA specification says, concerning date times, that they SHALL conform to DTM.US.FIELDED, and about dates like that, it says:
1. SHALL be precise to the day (CONF:81-10078).
2. SHOULD be precise to the minute (CONF:81-10079).
3. MAY be precise to the second (CONF:81-10080).
4. If more precise than day, SHOULD include time-zone offset (CONF:81-10081).
It sure sounds like you can’t use milliseconds. But, unfortunately, that’s a wrong interpretation. The DTM.US.FIELDED template on TS is an ‘open template’ which means that anything not explicitly prohibited is allowed.
Since milliseconds are not explicitly prohibited, they are allowed.
(Yes, you can then ask, why say “MAY be precise to the second”? this is careless language for a specification, and creates exactly this kind of trouble)
Note: this answer comes from Calvin Beebe (coming HL7 chair) on the HL7 Structured Documents Email List, and I’m just archiving the answer here so it can be found from search engines.