FHIR Chat · Schematron issue in R4 · implementers

Stream: implementers

Topic: Schematron issue in R4

view this post on Zulip Alexander Henket (Dec 02 2019 at 19:08):

I downloaded the R4 schemas/schematrons today. I found a number of technical errors that seem to stem from fhirPath conversions. Shouldn't these be fixed? I've added the existing Jira tracker items to them for as far as I could find them.

  • dom-3 says
    • <sch:assert test="not(exists(for $id in f:contained//f:id/@value return $contained[not(parent::/descendant::f:reference/@value=concat('#', $contained/*/id/@value) or descendant::f:reference[@value='#'])]))"> but should be
    • <sch:assert test="not(exists(for $id in f:contained//f:id/@value return $id[not(parent::/descendant::f:reference/@value=concat('#', $id/*/id/@value) or descendant::f:reference[@value='#'])]))">
  • ppc-2, ppc-3, ppc4, ppc-5 have one closing ) too many, e.g
    • <sch:assert test="exists(f:patient) or not(exists(f:scope/f:coding[f:system/@value='something' and f:code/@value='adr'])))">ppc-4 should be
    • <sch:assert test="exists(f:patient) or not(exists(f:scope/f:coding[f:system/@value='something' and f:code/@value='adr']))">ppc-4
  • trd-3 says
    • <sch:assert test="((not(f:type/@value = 'named-event')) or name.exists()) and (not(f:type/@value = 'periodic') or timing.exists()) and (not(starts-with(f:type/@value, 'data-')) or data.exists())"> but should be
    • <sch:assert test="(not(f:type/@value = 'named-event') or exists(f:data)) and (not(f:type/@value = 'periodic') or exists(f:timing)) and (not(f:type[starts-with(@value, 'data-')]) or exists(f:data))">
  • eld-19 says
    • <sch:assert test="matches(path/@value, '[^\s\.,:;\'&amp;quot;\/|?!@#$%&amp;amp;*()\[\]{}]{1,64}(\.[^\s\.,:;\'&amp;quot;\/|?!@#$%&amp;amp;*()\[\]{}]{1,64}(\[x\])?(\:[^\s\.]+)?)*')"> but should be
    • <sch:assert test="matches(path/@value, '[^\s\.,:;''&quot;\/|?!@#$%&amp;*()\[\]{}]{1,64}(\.[^\s\.,:;''&quot;\/|?!@#$%&amp;*()\[\]{}]{1,64}(\[x\])?(\:[^\s\.]+)?)*')">
  • inv-1 says
    • <sch:assert test="(exists(f:resource) or exists(f:part) or exists(f:[starts-with(local-name(.), 'value')])) and not(exists(f:[starts-with(local-name(.), 'value')])) and exists(f:resource))) and not(exists(f:*[starts-with(local-name(.), 'value')])) and exists(f:part))) and not(exists(f:part) and exists(f:resource))"> but should be
    • <sch:assert test="count(f:part | f:*[starts-with(local-name(), 'value')] | f:resource) = 1">

view this post on Zulip Grahame Grieve (Dec 02 2019 at 19:32):

This raises several issues for me:

  • Why only now are issues like this being raised? What is the minimum testing approach we should have?

hmm. I was going to say that they are tested during the build, but that bit is currently turned off

  • I really really don't want to do another technical correction. The last one took about 8 weeks of work to do - another one would be smaller, but I don't know how much smaller. We're still dealing with the last one. is there an alternative way to deal with this than another technical correction?

view this post on Zulip Alexander Henket (Dec 02 2019 at 19:36):

The schematrons seem to be present in just the zips for download? If so, could you just update that? Fixing the downloads for R4 does not fix any inherent fhirPath to xpath conversions yet though.

It seems most people are on the JSON train so maybe (combined with validation being switched off apparently) that's why it went unnoticed?

view this post on Zulip Alexander Henket (Dec 02 2019 at 19:38):

The schematron errors could have been caught by any tool that can either process them directly or after conversion to xslt. I noticed by running the validate option in oXygen on the folder.

view this post on Zulip Grahame Grieve (Dec 02 2019 at 19:39):

I don't think we're allowed to just fix stuff like that. I'd have to update all the structure definitions, and the package. I guess we just make the download available beside the spec,until we have other reasons for a technical correction? Subject for FMG...

view this post on Zulip Alexander Henket (Dec 02 2019 at 19:41):

Do the SDs have the schematron too? In any case it looks like all but the ppc things actually have approved issues that promise to fix them. I understand that fixing this comes with a cost. I'm sorry to be the messenger. I hope that FMG can find a low impact solution.

view this post on Zulip Lloyd McKenzie (Dec 02 2019 at 23:13):

We could take the approach that HL7 often does for other specs, which is to publish an Erratum. We could link to that from the home page of the spec and the erratum would list known errors and the corrections. (In this case, a link to a corrected zip of schematrons.)

view this post on Zulip Grahame Grieve (Dec 02 2019 at 23:31):

that wouldn't be a technical correction?

view this post on Zulip Lloyd McKenzie (Dec 02 2019 at 23:48):

Adding a pointer to an erratum? I don't think so. Can check with Austin or @Wayne Kubick

view this post on Zulip Wayne Kubick (Dec 03 2019 at 16:14):

I don't believe there's any real difference between a technical correction and an erratum, the former follow the same GOM process as for errata. If I understand Lloyd's suggestion, we could just post an announcement of discovered errors with the schematrons with a link to the corrected zip file without changing the actual core spec. That seems like a reasonable approach to ensure that implementers are getting the correct information without modifying the spec directly.

view this post on Zulip Lloyd McKenzie (Dec 03 2019 at 17:48):

Could we make a change to the home page that points to the erratum location?

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -