Stream: IG creation
Topic: link errors for ServiceRequest
Monique van Berkum (Nov 02 2021 at 20:53):
@Grahame Grieve @Mark Iantorno
We are getting the following IG publisher errors related to the ServiceRequest Profile in the Gravity SDOH CC IG:
1) The link 'event.html' for "Event Pattern" cannot be resolved - This is error seems to be originating from the Comment for ServiceRequest.status in the base resource. 2) The link 'servicerequest-example-di.html' for "CT Scan example" cannot be resolved. - This error seems to be originating from the comment for ServiceRequest.reasonCode in the base resource.
John Moehrke (Nov 02 2021 at 20:54):
which IG?
John Moehrke (Nov 02 2021 at 21:09):
I find https://github.com/HL7/fhir-sdoh-clinicalcare/
but that has not been updated since August... so is this your latest source?
John Moehrke (Nov 02 2021 at 21:19):
so do you want the event.html to be linked to the FHIR R4 event.html file? If so, then give it the full link. http://hl7.org/fhir/event.html
John Moehrke (Nov 02 2021 at 21:23):
hmm, interesting that the task.html does not complain, but event.html does.. I wonder if there is some markdown processing failures because the narrative including the event.html is in parentheses?
John Moehrke (Nov 02 2021 at 21:29):
this seems like situation contra to the fix I just got put into the IG builder. Where I wanted it to presume html pages without a path were to pages of my IG. It seems it is presuming event.html means a page inside your IG called event.html; but it still somehow knows that your task.html really means FHIR R4 task.
John Moehrke (Nov 02 2021 at 21:29):
you can put in full urls to FHIR R4 and it will build good.
Grahame Grieve (Nov 02 2021 at 21:30):
If so, then give it the full link. http://hl7.org/fhir/event.html
this is generally the wrong advice
Monique van Berkum (Nov 02 2021 at 21:30):
Yes. We noted that the task.html does not cause an error. While we can remove the evet issue in our IG, @Lloyd McKenzie felt this link should be fixed upstream from our IG.
You have the right IG, but this has not been pushed to the CI build server. We are working in Trifolia.
John Moehrke (Nov 02 2021 at 21:30):
I was wondering about that
Grahame Grieve (Nov 02 2021 at 21:30):
in fact, it's not allowed, since it's not a version stable reference
Grahame Grieve (Nov 02 2021 at 21:30):
still, how to reproduce?
John Moehrke (Nov 02 2021 at 21:31):
when I build that github repo, I do get the issue
John Moehrke (Nov 02 2021 at 21:31):
it is this definition
John Moehrke (Nov 02 2021 at 21:31):
<element id="ServiceRequest.status">
<path value="ServiceRequest.status"/>
<comment value="The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, competed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding event (see [Event Pattern](event.html) for general discussion) or using the [Task](task.html) resource. 
While all values are currently allowed, there may be a constraint on the values in future releases based on implementation feedback."/>
<mustSupport value="true"/>
</element>
John Moehrke (Nov 02 2021 at 21:31):
in that comment is a markdown to event.html and another to task.html
Grahame Grieve (Nov 02 2021 at 21:32):
and so task links to the correct place, and event to the wrong place?
John Moehrke (Nov 02 2021 at 21:32):
yes
John Moehrke (Nov 02 2021 at 21:33):
event presumes an IG local html file, task goes to R4
Sarah Gaunt (Nov 02 2021 at 22:31):
Is it similar/same as this issue: https://github.com/HL7/fhir-ig-publisher/issues/305?
Grahame Grieve (Nov 02 2021 at 22:38):
yes
Lloyd McKenzie (Nov 03 2021 at 03:53):
The issue is that the reference is in a comment in the core spec - so it's a local reference. It's not going to be version-stable.
Lloyd McKenzie (Nov 03 2021 at 03:54):
Link works fine in the core spec, but chokes when you build the profile. The weird thing is that there are two links in that comment. One to event and one to a resource. The resource one doesn't spit out an error, but the event one does.
Grahame Grieve (Nov 03 2021 at 03:57):
that's not weird. It'll be fixed in the next version
Last updated: Apr 12 2022 at 19:14 UTC