FHIR Chat · org.hl7.fhir.core build error

Stream: implementers

Topic: org.hl7.fhir.core build error

Yunwei Wang (Apr 15 2021 at 18:22):

I tried to customize FHIR validator jar file with additional rules. I cloned https://github.com/hapifhir/org.hl7.fhir.core. Without any code change, I run the build on master branch and got build error. Is this normal?
image.png

Michael O'Keefe (Apr 15 2021 at 18:37):

@Yunwei Wang I'm seeing the same test failures when I run mvn install on master

Yunwei Wang (Apr 15 2021 at 19:01):

@Mark Iantorno

Mark Iantorno (Apr 15 2021 at 19:01):

master is failing?

Mark Iantorno (Apr 15 2021 at 19:01):

that's not good

Mark Iantorno (Apr 15 2021 at 19:01):

in a call now

Mark Iantorno (Apr 15 2021 at 19:01):

will check afterwards

Yunwei Wang (Apr 15 2021 at 19:04):

I believe is one of the testing artifact: here is the failed test

Test set: org.hl7.fhir.validation.tests.ValidationTests

Tests run: 361, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 124.823 s <<< FAILURE! - in org.hl7.fhir.validation.tests.ValidationTests
ValidationTests.test Time elapsed: 1.16 s <<< FAILURE!
java.lang.AssertionError: Test cda/example-no-styles profile: logical: Expected 24 errors, but found 25. expected:<24> but was:<25>

Mark Iantorno (Apr 15 2021 at 19:07):

so, master is currently passing all tests right now

Mark Iantorno (Apr 15 2021 at 19:07):

https://dev.azure.com/fhir-pipelines/fhir-core-library/_build?definitionId=29

Mark Iantorno (Apr 15 2021 at 19:07):

let me clone and run locally

Mark Iantorno (Apr 15 2021 at 19:18):

I'm getting a fail as well.. something is not right, as the CI should have caught this.

Mark Iantorno (Apr 15 2021 at 19:19):

I'm going to investigate after 5

Mark Iantorno (Apr 15 2021 at 19:19):

I'm in a meeting right now

Rob Hausam (Apr 15 2021 at 19:25):

This may not be related, but If you see errors with ConceptMap it could have to do with the changes that were made recently in the StructureDefinition without corresponding changes to support that also being made in org.hl7.fhir.core. I did some work on that but it's not yet complete. Grahame said that intends to clean that up next week.

Mark Iantorno (Apr 15 2021 at 19:28):

that's good to know, but it _shouldn't_ change the test outcomes in the core... let me double check

Mark Iantorno (Apr 15 2021 at 19:28):

my meeting ended early

Mark Iantorno (Apr 15 2021 at 19:31):

The whole point of having the pipelines for CI/CD for the core libraries is to prevent things like this from happening. We have a stable version of the core, pointing to a stable version of the test cases

Mark Iantorno (Apr 15 2021 at 19:31):

and in theory anyone should be able to clone and run those tests without issues

Mark Iantorno (Apr 15 2021 at 19:31):

What is concerning for me is that the tests passed on master, after the last release

Mark Iantorno (Apr 15 2021 at 19:32):

so this points to a dependency _not_ being locked down that caused this to happen

Mark Iantorno (Apr 15 2021 at 19:32):

the test in question is cda.example-no-styles

Rob Hausam (Apr 15 2021 at 19:34):

Yeah. That sounds likely unrelated to what I mentioned.

Mark Iantorno (Apr 15 2021 at 19:37):

test case has not been updated since november so we can rule that out

Mark Iantorno (Apr 15 2021 at 19:46):

Alright, so here is the issue

Mark Iantorno (Apr 15 2021 at 19:47):

when the library last ran this test and passed on Monday, the following was output

Mark Iantorno (Apr 15 2021 at 19:47):

** Logical:   Load hl7.fhir.cda#current - 109 resources (00:51.0261)

Mark Iantorno (Apr 15 2021 at 19:47):

and now when we run, we get the following:

Mark Iantorno (Apr 15 2021 at 19:47):

  Load hl7.fhir.cda#current - 107 resources (02:37.0171)

Mark Iantorno (Apr 15 2021 at 19:48):

sorry reverse that

Mark Iantorno (Apr 15 2021 at 19:48):

we got 107 when we ran before, and now we get 109

Mark Iantorno (Apr 15 2021 at 19:49):

and now, it says we get 25 errors, not the expected 24

Mark Iantorno (Apr 15 2021 at 19:49):

the error that is occurring now, that was not occurring before is:

Mark Iantorno (Apr 15 2021 at 19:49):

http://terminology.hl7.org/ValueSet/v3-ParticipationType), and a code is required from this value set) (error message = Unknown Code http://terminology.hl7.org/CodeSystem/v3-ParticipationType#RPLC in http://terminology.hl7.org/CodeSystem/v3-ParticipationType)
ERROR: ClinicalDocument.componentOf.encompassingEncounter.encounterParticipant[0].typeCode: Value is 'CON' but must be 'DOC'

Mark Iantorno (Apr 15 2021 at 19:51):

The behavior of the validator has not changed, this appears to be an update in the external dependency hl7.fhir.cda#current

Mark Iantorno (Apr 15 2021 at 19:52):

my first reaction would be to update the test case to expect the 25 errors, as opposed to the currently expected 24

Mark Iantorno (Apr 15 2021 at 19:52):

HOWEVER, I don't really know what I'm doing 99% of the time, and I haven't worked with CDA before

Mark Iantorno (Apr 15 2021 at 19:52):

@Lloyd McKenzie Grahame is off for his birthday, can you please take a look at what I've posted above and let me know what you think?

Mark Iantorno (Apr 15 2021 at 19:53):

or @Rob Hausam @Yunwei Wang @Michael O'Keefe who can I talk to about CDA

Vassil Peytchev (Apr 15 2021 at 20:04):

All I can tell is that the error points that something is wrong with resolving a membership in a value set - CON is a valid value for ClinicalDocument.componentOf.encompassingEncounter.encounterParticipant[0].typeCode, while DOC is not. The value set in question confirms that: https://terminology.hl7.org/2.1.0/ValueSet-v3-ParticipationType.html

Michael O'Keefe (Apr 15 2021 at 20:04):

@Sean McIlvenna seems to be the main contributor to https://github.com/HL7/cda-core-2.0, which is the source for the hl7.fhir.cda IG

Chris Moesel (Apr 15 2021 at 20:04):

I'm just casually observing this thread, but it seems to me a bad idea to have test cases that rely on #current of an external IG that is actively being developed. So... realizing I have no skin in this game, I'm still going to suggest that if these tests must rely on an external IG, at least evaluate if they can depend on a fixed version of that IG.

Mark Iantorno (Apr 15 2021 at 20:07):

I agree

Mark Iantorno (Apr 15 2021 at 20:07):

That's a larger conversation though

Mark Iantorno (Apr 15 2021 at 20:08):

hopefully @Sean McIlvenna can shed some light on the recent changes

Sean McIlvenna (Apr 15 2021 at 20:28):

reviewing

Sean McIlvenna (Apr 15 2021 at 20:31):

there's definitely an issue in the cda-core-2.0 IG

Sean McIlvenna (Apr 15 2021 at 20:31):

trying to figure out what the right solution si

Mark Iantorno (Apr 15 2021 at 20:31):

thanks Sean

Sean McIlvenna (Apr 15 2021 at 20:31):

the cda-core-2.0 repo is missing the EncounterParticipant class

Sean McIlvenna (Apr 15 2021 at 20:32):

I will get it added now, stay tuned

Sean McIlvenna (Apr 15 2021 at 20:32):

having said that... ...encounterParticipant[0].typeCode is just a type code, with no specific binding

Sean McIlvenna (Apr 15 2021 at 20:32):

so, I'm not sure why you're getting that validation error

Sean McIlvenna (Apr 15 2021 at 20:33):

    <element id="EncompassingEncounter.encounterParticipant.typeCode">
      <path value="EncompassingEncounter.encounterParticipant.typeCode"/>
      <representation value="xmlAttr"/>
      <min value="1"/>
      <max value="1"/>
      <type>
        <code value="code"/>
      </type>
    </element>