UUID schematron error

[DaveSS]

We received the following schematron error when submitting a document with a id/@root attribute using lower-case letters for the UUID.

Description: dtr1-13-II: When UUID is used, the hexadecimal digits A-F SHALL be in upper case (not(@root) or not(matches(@root,$UUIDpattern) and matches(@root,'[a-z]')) / error) [assert]
Start location: 171:60

In the post for Issue #130 , it was indicated that the CDA allows UUIDs in the following format:

<xs:pattern value="[0-9a-zA-Z]{8}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{4}-[0-9a-zA-Z]{12}"/>

Can the requirement for certain UUIDs being upper case be relaxed for the LPR3 documents?

A from one of our documents receiving this error is:

<reference typeCode="REFR">
    <templateId root="1.2.208.176.7.1.10.129"></templateId>
    <templateId root="2.16.840.1.113883.10.12.324"></templateId>
    <externalAct classCode="PCPR" moodCode="EVN">
        <templateId root="1.2.208.176.7.1.10.128"></templateId>
        <templateId root="2.16.840.1.113883.10.12.325"></templateId>
        <id root="a93faa38-7aa3-5f45-8719-046a161c38b0"></id>
    </externalAct>
</reference>

[TueCN]

It is true that the CDA XSD has a pattern for UUID that allows it to be either case.

However, the II datatype defined on art-decor.org has a core rule saying:

dtr1-13-II: Lower case UUID "" found in @root. UUIDs SHALL, under official HL7 V3 Datatypes Release 1 (and 2) rules, have upper case hexadecimal digits A-F. RFC 4122 and HL7 FHIR state lower case UUID display.

The rule is flagged as info on art-decor.org, but the Schematron rule that is generated claims it to be an error, and looks like this:

    <!-- Abstract datatypes 2.15.1
        The literal form for the UUID is defined according to the original specification of the UUID. However, because the HL7 UIDs are case sensitive, 
        for use with HL7, the hexadecimal digits A-F in UUIDs must be converted to upper case.
    -->
    <let name="UUIDpattern" value="'^[0-9a-fA-F]{8}-[0-9a-fA-f]{4}-[0-9a-fA-F]{4}-[0-9a-aA-F]{4}-[0-9a-fA-F]{12}$'"/>
    <assert role="error" test="not(@root) or not(matches(@root,$UUIDpattern) and matches(@root,'[a-z]'))">dtr1-13-II: When UUID is used, the hexadecimal digits A-F SHALL be in upper case</assert>

Whether this is a bug on art-decor or intended, I don't know.

@jkiddo do you have any insight as to what is intended?

[jbraschler]

Our primary concern is that the id/@extension for an Episode of Care is allowed to be a mixed-case UUID by the schematron, but if we later need to link another Episode of Care to that identifier using the Episode of Care Link Act (in which what was previously communicated in the id/@extension is instead communicated in the id/@root), we get this schematron conformance error.

We can hard-code our solution to uppercase all of the identifiers that we send in the Episode of Care Link Act, but there's currently no guarantee that a lowercase UUID sent to LPR3 in the id/@extension for the Episode of Care section will evaluate as equivalent to an uppercase UUID sent in the id/@root of the Episode of Care Link Act.

[TueCN]

Hmm yes, it seems there is an indirect requirement that you must send your id/@extension in upper case if you wish to be able to make an external reference to it later.

[jonigkeit]

We will update the persistence layer introducing case insensitivity for UUIDs.

Consequently any UUID will be exposed in the HL7 V3 specified literal form ANSI/HL7 V3 DT, R1-2004 11/29/2004 - section 2.15.1 Literal Form

The literal form for the UUID is defined according to the original specification of the UUID. However, because the HL7 UIDs are case sensitive, for use with HL7, the hexadecimal digits A-F in UUIDs must be converted to upper case.

[jbraschler]

So, just to be entirely clear, you're saying that once this change is made, all UUIDs in the document will be required to be uppercase, correct?

[jonigkeit]

As we understand the specification all UUIDs must be sent in uppercase. For LPR to be in comformance with CDA it should reject any non-uppercase UUID.

However, SDS may make an exception regarding the conformance requirement that DXC must meet. If SDS makes this exception, LPR will in its inwards processing of literal representations of UUIDs uppercase them as well as uppercase all literal representations of UUIDs that LPR communicates outwards.

[jkiddo]

I can't see the spec being understood in any other way. UUID's must be uppercased according to spec

[ahenket]

Please note that the DTr1_II.sch lists the aforementioned check not as "error" but as "info". Here's the full fragment.

<!-- Abstract datatypes 2.15.1
    The literal form for the UUID is defined according to the original specification 
    of the UUID. However, because the HL7 UIDs are case sensitive, for use with 
    HL7, the hexadecimal digits A-F in UUIDs must be converted to upper case.
-->
<!--let name="UUIDpattern" value="'^[0-9a-fA-F]{8}-[0-9a-fA-f]{4}-[0-9a-fA-F]{4}-[0-9a-aA-F]{4}-[0-9a-fA-F]{12}$'"/-->
<!-- 2018-01-19 HL7V3 DTr1 and DTr2 state that UUIDs shall be upper case. 
    HL7 FHIR states that UUIDs shall be lower case. The RFC 4122
    https://tools.ietf.org/html/rfc4122 appears to say that the display of a UUID 
    only contains lower-case characters. 
    After discussion in the HL7 community and the ART-DECOR Expert Group, 
    we agreed that we should NOT enforce the DTr1 and DTr2 requirement for 
    upper-case characters, because it leads to real world mismatches.
   (https://chat.fhir.org/#narrow/stream/implementers/subject/UUID.20to.20lower-case())
-->
<assert role="info" test="not(matches(@root, $UUIDpattern) and 
    matches(@root, '[a-z]'))" see="https://art-decor.org/mediawiki/index.php?title=DTr1_II"
    >dtr1-13-II: Lower case UUID "<value-of select="@root"/>" found in @root. 
       UUIDs SHALL, under official HL7 V3 Datatypes Release 1 (and 2) rules, 
       have upper case hexadecimal digits A-F. RFC 4122 and HL7 FHIR state 
       lower case UUID display.</assert>

[DaveSS]

Have we heard back from SDS about this issue? We receive referrals based on Medcom specifications that do not require upper case UUIDs, so we prefer sending out the UUIDs in the case that we are receiving them. Also, has Art-Decor been consulted to see if this is a bug on their end? From the note above, it appears that they intended to NOT enforce this constraint.

[TueCN]

@DaveSS I suspect the issue regarding why the Schematron rule flags it as error instead of info is that we run our own installation of art decor on lpr-art-decor which is version 1.8. Art-Decor is running version 2.0

@jonigkeit or @jkiddo can you confirm if the version difference can account for the Schematron rule difference? Or can the updated Schematron rules from art-decor.org be imported into lpr-art-decor?

[jkiddo]

@TueCN correct - in the newer version of art-decor the schematrons does not flag mixed or lowercase UUID's as errors.

[jonigkeit]

RESOLUTION We will be updating the art-decor installation so that non-uppercase lexical representations of Universal Unique Identifiers will give a schematron info instead of an error. This should take care of the issue with HL7 CDA in-conformance with RFC 4122, as UUID internally are stored as bytes defined in RFC 4122 section 4.1.2

[TueCN]

Closing due to inactivity, as the enhancement was delivered per 15th of January.