Stream: implementers
Topic: ig publisher
Grahame Grieve (Aug 17 2016 at 21:06):
Now that the ballot is out, I'm working on 2 enhancements to the implementation guide publisher:
- support for FHIR 1.4.0 (a few people doing IG's on this version)
- the ability to just point the IG publisher at a set of resources and get a vanilla presentation of them and their validation outcomes. (no IG publishing needed)
Grahame Grieve (Aug 17 2016 at 21:06):
Lloyd is working with me on the 1.4.0 part. I don't see any prospect that we can extend that to 1.0.2 (DSTU2) - there's too many big changes to the conformance resources to deal with
Vadim Peretokin (Nov 23 2016 at 23:58):
build.fhir.org keeps serving up corrupt IG publisher jars - it's ending the download way too early. I'm on about five attempts now trying to get the latest jar :\
Vadim Peretokin (Nov 24 2016 at 00:57):
There's a problem with the validate-only mode in the publisher - https://gist.github.com/vadi2/c9e4b7e2259a5ec78831138fe129fcba, I suspect the default control file used hasn't been updated to have the sct-edition element
Grahame Grieve (Nov 24 2016 at 07:43):
We're not sure what the problem with the host is. I'm going to move it next week once I'm home.
Grahame Grieve (Nov 24 2016 at 07:44):
fixed the other
Vadim Peretokin (Nov 24 2016 at 22:26):
Confirmed fixed, and I was able to download it today fine
Dave Holdgrafer (Feb 21 2018 at 15:45):
Anyone have any experience using this tool?
Lloyd McKenzie (Feb 21 2018 at 15:46):
Many of us here do...
Eric Haas (Feb 21 2018 at 15:46):
we even have a specific stream "IG creation" for IG question
Lloyd McKenzie (Feb 21 2018 at 15:46):
Detailed questions are encouraged to be posted on #IG creation
Lloyd McKenzie (Feb 21 2018 at 15:46):
:)
Michele Korell (May 20 2019 at 09:05):
Hello,
until now we was using the fhir.igpublisher.jar to build the implementation guide, but today after try, i get the following error:
curl http://build.fhir.org/org.hl7.fhir.igpublisher.jar -O org.hl7.fhir.igpublisher.jar
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 154 100 154 0 0 561 0 --:--:-- --:--:-- --:--:-- 560
curl: (6) Could not resolve host: org.hl7.fhir.igpublisher.jar
After downloading manually the lates version from build.fhir.org and generate my ig i see that no index page is generated? This is an update that changes some structure? It is a place where I can get the correct version?
Thanks a lot
Bye
Michele
Grahame Grieve (May 20 2019 at 09:12):
there is no latest at that location. it's been moved to Maven - current latest copy at
Grahame Grieve (May 20 2019 at 09:12):
Michele Korell (May 20 2019 at 09:19):
Ok, thanks, I've found this one, so I think my problem is another.
Michele Korell (May 20 2019 at 09:38):
I find some explaination for my problem in qa page: Screenshot-2019-05-20-at-11.37.17.png
Actually I'm looking why I have this problem...
Grahame Grieve (May 20 2019 at 10:36):
you are not getting any html?
Michele Korell (May 20 2019 at 10:58):
i get the qa and some extension and value sets but not the index and structure definitions. Actually i'm using the https://github.com/ahdis/test-template template from @Oliver Egger
Michele Korell (May 20 2019 at 11:01):
I was just specifying new example resource, and i remarks that the ig-pulisher that I have downloaded some weeks ago didn't work. Then i upgraded to new release and i get all those errors
Grahame Grieve (May 20 2019 at 11:02):
ah ok, so this is a template problem.
Grahame Grieve (May 20 2019 at 11:02):
in fact, I just fixed a problem like that here.
Grahame Grieve (May 20 2019 at 11:03):
templates are a work in progress...
Michele Korell (May 20 2019 at 11:03):
i think so
Grahame Grieve (May 20 2019 at 11:04):
I'm going to guess that you don't have a defaults property in your ig.json, and you do in the config.json in the template (just like the documentation says).
Grahame Grieve (May 20 2019 at 11:05):
which will result in no html produced. that's the bug I just fixed
Michele Korell (May 20 2019 at 11:06):
Ok, here is my qa: qa.html
Michele Korell (May 20 2019 at 11:06):
The one i putted befor is the one that worked last week
Grahame Grieve (May 20 2019 at 11:07):
that won't tell me anything - the bug is outside what appears in the qa.html. But you just have to tell me: do you have a "defaults" property in your ig.json file?
Michele Korell (May 20 2019 at 11:08):
sorry, i was writing before your answer, i'm just cheking now :sweat_smile:
Michele Korell (May 20 2019 at 11:08):
"defaults": {
"Any": {
"java": false
}
},
Grahame Grieve (May 20 2019 at 11:09):
yes. I'll release a fixed version soon.
Michele Korell (May 20 2019 at 11:11):
Actually i was comparing with ch-core version and @Oliver Egger made some changes from the time we started build the ig:
https://github.com/hl7ch/ch-core/commit/163990ec93458756be875db54239581327e4f6be#diff-fa7d071b576c819977fd9c91648449a4
Michele Korell (May 20 2019 at 11:16):
In put the same properties and i get all except index.html
Grahame Grieve (May 20 2019 at 11:17):
yes. I omitted to deal with that. next release you can back to splitting it. but you need an index.html in your pages to get an index.html produced - the template doesn't produce that
Michele Korell (May 20 2019 at 11:18):
i have it, but it is under ./pages/_includes
Michele Korell (May 20 2019 at 11:20):
I see that the ig of ch-core was generated on 9 may, I'm checking the differences. Thanks a lot for your's suggestions
Grahame Grieve (May 20 2019 at 12:40):
I release a new publisher
Oliver Egger (May 20 2019 at 19:18):
@Grahame Grieve I tried to build the igpublisher locally, but it gives me an error ' symbol: method merge(com.google.gson.JsonObject,com.google.gson.JsonObject)
[ERROR] location: class org.hl7.fhir.utilities.json.JSONUtil'. I cannot find the merge function on github: https://github.com/hapifhir/org.hl7.fhir.core/blob/master/org.hl7.fhir.utilities/src/main/java/org/hl7/fhir/utilities/json/JSONUtil.java, is this not yet committed or do I look in the wrong place?
Lloyd McKenzie (May 20 2019 at 19:26):
Same issue
Grahame Grieve (May 20 2019 at 21:39):
ok committed, but not released yet
Eric Mays (Jun 03 2019 at 18:41):
Having some modest success in running ig publisher on some profiles. Got the following error:
Bad Source Reference 'StructureDefinition/AMA_IHMI-device-heart-rate-1.StructureDefinition' - should have the format [Type]/[id] where id is a valid FHIR id type
Changed the "_" to "-" and past that now. But before I ask folks to rename the profiles, just want to be sure I'm reading that correctly and that underscores are not allowed.
Thanks.
Lloyd McKenzie (Jun 03 2019 at 18:42):
Underscores are not allowed in ids. The specific regex is: [A-Za-z0-9\-\.]{1,64}
Eric Mays (Jun 03 2019 at 18:45):
Thanks. And good to know about the length restriction.
Eric Mays (Jun 04 2019 at 14:00):
We're on V3 using the CH template https://github.com/ahdis/test-template
Guessing there's no V3 equivalent for <exampleCanonical value="http://fhir.ch/ig/ch-core/StructureDefinition/ch-core-practitioner"/> ??
Grahame Grieve (Jun 04 2019 at 14:01):
test template is independent of FHIR version
Eric Mays (Jun 04 2019 at 14:14):
When using that test-template element it throws an exception, since it's using the V3 parser.
Changed parseContent as follows, since it looks like this is getting converted eventually to latest version
private Resource parseContent(String name, String contentType, String parseVersion, byte[] source)
throws Exception {
if (name.endsWith("/ig") && contentType.contains("xml")) {
parseVersion = "4.0.0";
}
This seems to work but not yet able to generate the examples correctly
Grahame Grieve (Jun 04 2019 at 14:36):
where did you make this change?
Eric Mays (Jun 04 2019 at 14:46):
parseContent is a method in the Publisher class
Grahame Grieve (Jun 04 2019 at 14:47):
then there's no reason for you to making changes there, and you're solving the wrong problem
Eric Mays (Jun 04 2019 at 15:16):
OK, but when using the xml from the CH ig.xml e.g.
<definition>
<resource>
<reference>
<reference
value="Device/AMA-IHMI-device-heart-rate-1-example" />
</reference>
<exampleCanonical
value="http://www.ama-ihmi.org/fhir/StructureDefinition/AMA-IHMI-device-heart-rate-1" />
</resource>
it doesn't parse
Using the V3 structure in ig.xml produces a nice implementation guide except that the examples link is bad. The file
StructureDefinition-AMA-IHMI-observation-heart-rate-1-examples.html
doesn't get generated.
So that's why I made the change so that we could use the
exampleCanonical element
Eric Mays (Jun 04 2019 at 18:06):
OK. I now see "exampleFor" in V3. Reverted to the V3 ig.xml and got the examples to link up without that code change.
exampleFor == exampleCanonical
Grahame Grieve (Jun 05 2019 at 09:57):
so this is all sorted?
Eric Mays (Jun 05 2019 at 13:20):
Yes. Able to generate an IG including examples using the CH template with no code changes. Just got a bit mixed up between the CH V4 ig.xml and translating that back to our V3 ig.xml. We're making some changes to profiles and examples to align with the FHIR requirements and conventions, and hope to get that all worked out soon.
Ganesh Kusundal (Jun 25 2019 at 05:12):
Hello, I am currently working on on IG publisher guide, and since long time I am trying to figure out, how we can use structureDefinition files to publish guide instead of using spreadsheet xml?
Richard Townley-O'Neill (Jun 25 2019 at 06:18):
AU FHIR base uses structure definitions. Its files are in Github at https://github.com/hl7au/au-fhir-base
Eric Mays (Jun 26 2019 at 15:21):
Have an IG now that's coming together pretty well. Just one issue with the profiles differential table. The html seems to only show the first element in the differential. I looked at the profiles exported from Forge as xml, and the differential shows multiple elements. The Forge snapshot seems to display correctly. This is with V3. Any ideas? thanks.
Lloyd McKenzie (Jun 26 2019 at 15:58):
With the IGPublisher, you can't have a "sparse" differential. For every element in your differential, the parent element must also appear in your differential. For example, if you have a constraint on Patient.contact.name.given, the differential must include nodes for Patient, Patient.contact and Patient.contact.name.
Eric Mays (Jun 26 2019 at 16:09):
OK. Guess I'll see if we can get that out of Forge. Or is there some way I can produce that via writing something in HAPI. I guess I see how I can fix it, just looking for the shortest path. Thanks.
Lloyd McKenzie (Jun 26 2019 at 16:35):
Just do something to the higher-level entries. Assert mustSupport, add a comment, something.
Eric Mays (Jun 26 2019 at 16:55):
Did a quick experiment. Noticed that the top level e.g. Observation element wasn't in the forge diff. Added it into the diff with short, defn, comment. That did indeed cause a much better diff rendering. I think I see how to write some code in the DOM to make this fix.
There's also a desire to remove some of the constraints in the rendering, e.g. ele-, dom-, so guess I'll need to write something to take those out as well.
Thanks for the help.
Lloyd McKenzie (Jun 26 2019 at 16:57):
You can't remove constraints
Lloyd McKenzie (Jun 26 2019 at 16:57):
You might be able to not highlight inherited constraints in the publication, but all inherited constraints always apply.
Lloyd McKenzie (Jun 26 2019 at 16:58):
(Doing otherwise would be non-conformant)
Eric Mays (Jun 26 2019 at 17:01):
Got it, thanks. If anyone knows know how to "not highlight inherited constraints" please send info along.
Lloyd McKenzie (Jun 26 2019 at 17:43):
I don't think the IGPublisher supports it right now, but it's a reasonable thing to want. Can you submit a change request?
Eric Mays (Jun 26 2019 at 22:32):
OK. Is there a page somewhere to submit a change request?
Eric Mays (Jun 26 2019 at 22:36):
Was able to write some code to identify the missing ancestor elements and insert additional ones. Simply used the comment as you suggested. Looks much better now. Thanks for your help.
David McKillop (Jun 26 2019 at 22:38):
@Eric Mays FYI - at the bottom of each page there is a link "Propose a change" which take you to a GForge issues page. If you a registering a new account, it may take it little while to get approved, but @Lloyd McKenzie is pretty quick progressing this.
Grahame Grieve (Jun 27 2019 at 11:46):
this is a standing annoying bug that I need to fix, but it's defied several sustained efforts to figure it out
Eric Mays (Jun 28 2019 at 14:06):
is the bug you're referring to the "sparse differential" or the "not highlight inherited constraints"
Lloyd McKenzie (Jun 28 2019 at 15:17):
Sparse differential
Michel Rutten (Jul 16 2019 at 11:38):
Correct, Forge generates a sparse differential component that only includes element definitions that are actually constrained with respect to the base profile. All other element definitions are redundant and omitted from the differential. This follows the official definition of the differential component by the FHIR spec.
However apparently some tooling, such as the IG publisher, is not able to handle sparse differentials with orphaned elements (w/o parent). This indicates a tooling limitation, not an error in the profile.
We could add a configuration option to Forge to always include all parent element definitions, even if they are redundant, such that the differential always represents an actual tree structure, allowing such profiles to be processed by less capable/conformant tooling. However I'd rather stick to a "canonical" output format and work with the community to achieve tooling harmonization. FHIR profiling is already quite complex and having different representations seems to inhibit understanding and confuse discussions. Just my 2c.
Michel Rutten (Jul 16 2019 at 11:45):
BTW As Lloyd explains, in order to force-include an element definition into the generated differential, you can add some meaningless constraint, e.g. change the element comment to "forced".
Eric Mays (Jul 17 2019 at 13:50):
In case anyone else needs this, here's the hack:
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setNamespaceAware(true);
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(Files.newInputStream(file_in));
logger.info("XML encoding: " + doc.getXmlEncoding());
Element root = doc.getDocumentElement();
logger.info("Root: " + root.getNodeName());
NodeList diff_nodes = root.getElementsByTagName("differential");
if (diff_nodes.getLength() != 1)
throw new Exception("" + diff_nodes.getLength());
Element diff = (Element) diff_nodes.item(0);
NodeList elements = diff.getElementsByTagName("element");
logger.info("elements: " + elements.getLength());
HashSet<String> paths = new HashSet<>();
HashMap<String, Element> to_add = new HashMap<>();
for (int i = 0; i < elements.getLength(); i++) {
Element element = (Element) elements.item(i);
Element path = (Element) element.getElementsByTagName("path").item(0);
String value = path.getAttribute("value");
paths.add(value);
String[] ancs = value.split("\\.");
String anc_path = "";
for (String anc : ancs) {
anc_path += (anc_path.isEmpty() ? "" : ".") + anc;
if (!paths.contains(anc_path)) {
logger.warn("Add: " + anc_path);
to_add.put(anc_path, element);
}
paths.add(anc_path);
}
}
for (Entry<String, Element> e : to_add.entrySet()) {
logger.info("Axx: " + e.getKey());
Element elem = doc.createElement("element");
elem.setAttribute("id", e.getKey());
Element path = doc.createElement("path");
path.setAttribute("value", e.getKey());
elem.appendChild(path);
Element comment = doc.createElement("comment");
comment.setAttribute("value", e.getKey());
elem.appendChild(comment);
diff.insertBefore(elem, e.getValue());
}
TransformerFactory transformerFactory = TransformerFactory.newInstance();
Transformer transformer = transformerFactory.newTransformer();
DOMSource source = new DOMSource(doc);
FileWriter writer = new FileWriter(file_out.toFile());
StreamResult result = new StreamResult(writer);
transformer.transform(source, result);
Eric Mays (Jul 17 2019 at 13:59):
I've been informed that there is some additional implementation guide process that HL7 uses internally, and that what we're producing using the IG publisher isn't a complete implementation guide. In particular, that the IG publisher doesn't validate WRT schematron? Is there a pointer to this additional internal process? This is all very confusing to me. Appreciate any help. Thanks..
Grahame Grieve (Jul 17 2019 at 14:01):
I'm not sure what you're referring to here. What IG is this about?
Eric Mays (Jul 17 2019 at 14:05):
So we produced an IG for some profiles, extensions, and value sets that we developed. Actually two IGs. Used the IG publisher. Seems to produce a decent IG artifact to my perusal. But I'm being told that there's more that HL7 does to produce a "real" IG. And I'm trying to understand what that might be.
Grahame Grieve (Jul 17 2019 at 14:06):
is this for HL7 ballot?
Eric Mays (Jul 17 2019 at 14:08):
not sure, there was some mention of a connectathon?
Lloyd McKenzie (Jul 17 2019 at 16:24):
There's a maturity scale for implementation guides (and all resources). To hit a particular maturity level, the IG content needs to have been tested at a connectathon or equivalent. But that has nothing to do with the "completeness" of an IG.
Halina Labikova (Jul 17 2019 at 21:16):
I came across a small issue: the publisher is rendering the hyperlinks to valuesets in a <a href="{{[type]}}/{{[id]}}.html" format instead of <a href="{{[type]}}-{{[id]}}.html" - making the links broken. Any help on how to fix this? My templates seem to be alright, and editing the output files after each IG generation doesn't seem like a good approach either..
Eric Mays (Jul 17 2019 at 22:07):
I see. So we have a "real" IG. And need to figure out process for maturity level. Thanks.
Grahame Grieve (Jul 18 2019 at 02:36):
@Halina Labikova you haven’t specified the output path for the resource
Halina Labikova (Jul 18 2019 at 15:05):
Silly me. Thanks Grahame!
Bushra Khatoon (Sep 10 2019 at 12:44):
Got it, thanks. If anyone knows know how to "not highlight inherited constraints" please send info along.
@Eric Mays is this issue referrering to the 'ele-1' and 'ext-1' constraints appearing in the rendered profiles?
Eric Haas (Sep 10 2019 at 17:09):
javascript and digging into the templates. (not recommend unless you got a lot of time to kill)
Bushra Khatoon (Sep 10 2019 at 17:47):
I have resolved it locally by removing the snapshot from the structure definitions. But that resolves a cosmetic issue in a way. I'm not sure that removing the snapshot is technically acceptable when producing Implementation Guides using the publisher. The snapshot appears to be reinstated for the generated output so I'm guessing that it is?
Grahame Grieve (Sep 10 2019 at 19:27):
I’m not sure what you’re trying to do. Or why removing the snapshot even works, because the publisher will simply generate them anyway.
Bushra Khatoon (Sep 11 2019 at 10:26):
The issue was around the presentation of the FHIR profiles when using the IG Publisher, but as stated this has been resolved.
Grahame Grieve (Sep 11 2019 at 11:25):
ok great
Dr Murthy (Sep 12 2019 at 07:29):
Hi, all, I am currently working on fhir platform. we are currently using simplifier for creating and publishing IG. Since simplifier has limitation in terms of number of IGs (i.e. 5), We would like to explore other options like IG publisher and Trifolia. I went through the wiki pages of IG publisher, but could not quite follow it. Can you pls help me to set up IG publisher and share some documents on step by step use of IG publisher.
Lloyd McKenzie (Sep 12 2019 at 11:13):
Simplifier allows more, but you need to pay :)
We're currently putting on a course on IG development. We're recording the whole thing and will be sharing both the videos as well as the presentations, a "starter" IG and an IG whose sole purpose is to provide documentation on how to create IGs at the end. All of those materials should be available for sharing at the end of next week. If you can't wait that long, send me a private message and I can point you at the materials "in progress", but be aware that they'll be changing a lot over the course of the week. (In reality, the IG publication process will be evolving over the next 6 months, though hopefully the core of what you need to do to publish won't change super-radically.)
Thomas Tveit Rosenlund (Oct 10 2019 at 08:09):
A quick question. I am trying to run IG publisher to validate a directory of StructureDefinitions, in the "validation mode". I get some java errors and the qa file says it tries to validate against FHIR version 4.1.0. There are several issues with 4.1.0 and my profiles I know (the validator also complains, but not then validating against 4.0.0). How do I get the publisher to use the 4.0.0 package? I did try to make my own basic control-parameter.json and specify the version, but to no avail. The qa files still comes out claiming version 4.1.0. Is there any way to use the publisher to validate on FHIR version 4.0.0?
My commandline:
java -jar e:\FHIR-validator\org.hl7.fhir.publisher.jar -ig control-parameters.json -source StructureDefinition -destination .
The control-parameter.json:
{
"url": "http://hl7.org/fhir/ig",
"name": "Implementation Guide Template",
"package-id": "hl7.fhir.test.ig",
"date": "Thu, 10 Oct, 2019 09:43:36 +0200",
"exception": "Error doing replacements - no id defined in resource: Bundle/null",
"version": "4.0.0",
"tool": "4.0.0"
}
Grahame Grieve (Oct 10 2019 at 08:36):
-version 4.0
Thomas Tveit Rosenlund (Oct 10 2019 at 08:44):
Thanks, that did work, although i did not find any documentation for that parameter. "- version 4.0.0" makes the publisher validate using 4.0.0 spec. The tool is still 4.1.0 though. There may be some other gremlins here because I still get the java parser errors.
Grahame Grieve (Oct 10 2019 at 08:49):
if you send me you directory I can put it in my queue to have a look
Eric Haas (Oct 11 2019 at 21:45):
@halina
Ramandeep Dhanoa (Nov 13 2019 at 22:35):
Hi, I am getting this error while publishing in IG-publisher:
Capture.PNG
The version got updated? If yes, where do I update the version name?
Grahame Grieve (Nov 13 2019 at 22:58):
you need to be using the most recent IG publisher
Ramandeep Dhanoa (Nov 13 2019 at 23:23):
Thanks!
Shelby Switzer (Dec 03 2019 at 15:45):
Hey y'all! This morning I noticed our build is failing due to what appears to be an IG Publisher error. This is the error:
pasted image
And this is the link to the build: https://travis-ci.org/CMSgov/dpc-app/jobs/620164279?utm_medium=notification&utm_source=github_status
Any ideas what happened?
David Pyke (Dec 03 2019 at 15:46):
It's saying a file is missing, is it there?
Shelby Switzer (Dec 03 2019 at 15:48):
one sec, I'll try to check locally. are those files not supplied by the IG publisher tool?
Shelby Switzer (Dec 03 2019 at 15:57):
it's looking for "c:/temp/snapshot/data-absent-reason.xml" to generate the snapshot. we don't have this file in our codebase (and don't think ever had?). is this something that's supposed to be supplied in one of the fhir libraries that gets installed, or is this a new requirement that we have this in our codebase?
Shelby Switzer (Dec 03 2019 at 15:59):
nick just mentioned to me separately that it doesn't look like there are any IG commits, but maybe this path got hard coded in one of the resources?
Reece Adamson (Dec 03 2019 at 17:20):
Seeing the same issue with the 4.10 validator snapshot using java -jar org.hl7.fhir.validator.jar --version (or actually trying to validate something).
The culprit? -> https://github.com/hapifhir/org.hl7.fhir.core/commit/e08c1aad9664f4274ba3798b0aae3103fed5ab4b#diff-10a05d617c7de5aac76e0b047cae3eb8R473
Precise tool version: FHIR Validation tool Version 4.1.10-SNAPSHOT - Built 2019-12-03T21:56:24.387+11:00 - Git ec5a70ec3512
Lloyd McKenzie (Dec 03 2019 at 17:51):
Looks like some debug code may have slipped into an official release. @Grahame Grieve ?
Halina Labikova (Dec 03 2019 at 18:40):
Hey y'all! This morning I noticed our build is failing due to what appears to be an IG Publisher error. This is the error:
pasted image
And this is the link to the build: https://travis-ci.org/CMSgov/dpc-app/jobs/620164279?utm_medium=notification&utm_source=github_status
Any ideas what happened?
I'm having the same error, it looks like the publisher is trying to find the xmls in c:\temp\snapshot as opposed to the actual source directory?
May Terry (Dec 03 2019 at 18:41):
@Halina Labikova - there's another thread going on with similar issues: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/IG.20Publisher.20Broken.3F/near/182463074
btw...I get the same error. :-)
Halina Labikova (Dec 03 2019 at 18:52):
@May Terry I see, thanks May! (I guess I'll just go back to one of the older versions then:-) )
Grahame Grieve (Dec 03 2019 at 19:08):
yes it's some debugging code that slipped out by mistake. doing a new release now
Ramandeep Dhanoa (Feb 05 2020 at 21:55):
Hey @Lloyd McKenzie how can we document repeated elements in the spreadsheet (without using the slicing concept). Reason we want to document repeated elements is because we want to document the mapping information for each element. I am thinking it cannot be done through slicing because in our implementation it is not implemented as slicing concept?
Grahame Grieve (Feb 05 2020 at 21:57):
Multiple mappings for a single element?
Ramandeep Dhanoa (Feb 05 2020 at 22:00):
For example telecom.phone having different mappings as compared to telecom.email (we are documenting both front-end and back-end mappings).
Grahame Grieve (Feb 05 2020 at 22:03):
are you providing mappings for humans, or for computable use?
Lloyd McKenzie (Feb 05 2020 at 22:04):
You have two choices - slice the field and declare a separate mapping for each or just document all the mappings in one row in the spreadsheet - the mapping cells are just human-readable text, so you can cram as much explanation into them as you like
Ramandeep Dhanoa (Feb 05 2020 at 22:25):
@Grahame Grieve for humans
@Lloyd McKenzie is that okay to show it as slicing in the spreadsheet (just for more clarification) and have it not implemented that way?
Lloyd McKenzie (Feb 05 2020 at 22:39):
Not sure what you mean by "not implemented that way". If something is sliced, it's sliced. The slices would need to be mutually exclusive and instances that are validated against the profile would be validated against the slices - with the corresponding errors/warnings if none of the slices match (error if closed, warning if open). If the slices don't impose any additional constraints, that would be the only impact.
Ramandeep Dhanoa (Feb 05 2020 at 22:49):
Let's take this example from Practitioner:
"identifer": [{
"type": {
"text": "BC MSP Provider License Number"
},
"value": "11111",
"period": {
"start": "2020-01-01"
}
}, {
"type": {
"text": "Second Identifier"
},
"value": "11111",
"period": {
"start": "2020-01-01"
}
}, {
"type": {
"text": "Third Identifier"
},
"value": "22222",
"period": {
"start": "2020-01-15"
}
}
],
just trying to understand - to document this in spreadsheet - I will have just one row to document the mapping info for all 3 identifiers (since it's just repeated elements and not slicing)?
Shelby Switzer (Mar 12 2020 at 19:58):
Hey y'all! We're now encountering an error in our build when using the ig publisher:
org.hl7.fhir.exceptions.FHIRException: Unable to resolve package id hl7.fhir.pubpack
at org.hl7.fhir.utilities.cache.PackageCacheManager.fetchTheOldWay(PackageCacheManager.java:757)
at org.hl7.fhir.utilities.cache.PackageCacheManager.loadFromPackageServer(PackageCacheManager.java:335)
at org.hl7.fhir.utilities.cache.PackageCacheManager.loadPackage(PackageCacheManager.java:586)
at org.hl7.fhir.igtools.publisher.Publisher.loadPubPack(Publisher.java:1987)
at org.hl7.fhir.igtools.publisher.Publisher.initializeFromJson(Publisher.java:1830)
at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1209)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:660)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6933)
It looks like the code related to this package was added relatively recently on Feb 8 (https://github.com/hapifhir/org.hl7.fhir.core/commit/4708fcb49ea24b23e350c37ed856be94a247a380), but we've definitely had successful builds since then. We've attempted restarting the build but still see the failure.
Also, it appears the exception is thrown on this line (https://github.com/hapifhir/org.hl7.fhir.core/blob/65fd77ed76b778b9cf5d0c912f619fed42419911/org.hl7.fhir.utilities/src/main/java/org/hl7/fhir/utilities/cache/PackageCacheManager.java#L757) but I'm not exactly sure why the url would be null here.
Any ideas?
Grahame Grieve (Mar 12 2020 at 20:56):
you shouldn't get to this point. do you have network access restrictions?
Grahame Grieve (Mar 12 2020 at 21:49):
no, an infrastructure issue, should be fixed in 5 min or so
Shelby Switzer (Mar 13 2020 at 15:34):
awesome, thank you!
Emily Hart (Mar 24 2020 at 13:16):
We're seeing the same error that Shelby asked about on the 12th: Unable to resolve package id hl7.fhir.pubpack. Is there anything going on that would cause it to resurface?
Ramandeep Dhanoa (Mar 24 2020 at 15:20):
I am also getting the following error in ig publisher:
Error.PNG
Any idea what's going on @Lloyd McKenzie @Grahame Grieve ?
Jean Duteau (Mar 24 2020 at 15:25):
Yes, Grahame knows about it and it appears to be something with the HL7 website and they are working on it.
Ramandeep Dhanoa (Mar 24 2020 at 17:48):
Thanks Jean for letting me know!
Nicole Zonnenberg (Mar 25 2020 at 13:15):
@Jean Duteau thank you for getting back to us! Will you post here when they've resolved the conflict?
Jose Costa Teixeira (Mar 25 2020 at 13:31):
Seems to be working again now @Nicole Zonnenberg @Jean Duteau @Ramandeep Dhanoa @Emily Hart
Ramandeep Dhanoa (Mar 25 2020 at 15:20):
Yes it is working now. Thanks!
Nicole Zonnenberg (Apr 07 2020 at 13:18):
Hello! We are experiencing a travis build failure: Invalid or corrupt jarfile ./.bin/org.hl7.fhir.publisher.jar.
We restarted the build to confirm it didn't fail to downlad the whole JAR. Is there anything going on on your end of things?
Grahame Grieve (Apr 07 2020 at 13:21):
where are you getting this? your local build?
Nicole Zonnenberg (Apr 07 2020 at 13:23):
@Grahame Grieve We're experiencing this on github in our travis checks before we merge a branch.
Nicole Zonnenberg (Apr 07 2020 at 13:28):
Ah, we see that the github URL of the JAR is down.
Emily Hart (Apr 29 2020 at 15:57):
Hi all! We noticed here that the IG Publisher JAR has moved from its fhir.github.io location to storage.googleapis.com: https://fhir.github.io/latest-ig-publisher/ Is this a permanent change?
Lloyd McKenzie (Apr 29 2020 at 16:11):
Yes. It got too big to host on Github
Silvio Luthi (Jul 15 2020 at 20:45):
Hello, it looks like we are having a travis build error. Im running into the following:
org.hl7.fhir.exceptions.FHIRException: Unable to resolve package id hl7.fhir.pubpack#0.0.6
It looks like we cant pull the dependencies right now.
2020-07-15 20:04:19.319 [main] INFO o.h.f.u.c.BasePackageCacheManager [BasePackageCacheManager.java:75] Failed to resolve package hl7.fhir.pubpack#0.0.6 from server: http://packages.fhir.org
2020-07-15 20:05:35.081 [main] INFO o.h.f.u.c.BasePackageCacheManager [BasePackageCacheManager.java:75] Failed to resolve package hl7.fhir.pubpack#0.0.6 from server: http://packages2.fhir.org/packages
Jason Crowley (Jul 15 2020 at 21:06):
I think someone else is having your same issue: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/hl7.2Efhir.2Epubpack.20error
Silvio Luthi (Jul 15 2020 at 21:07):
Looks like it, thanks!
Grahame Grieve (Jul 16 2020 at 01:53):
should be fixed now
Shamil Nizamov (Aug 21 2020 at 01:01):
I'm getting the same with the latest publisher.jar - o.h.f.u.c.BasePackageCacheManager [BasePackageCacheManager.java:76] Failed to resolve package hl7.fhir.pubpack#0.0.7 from server: http://packages.fhir.org
Grahame Grieve (Aug 21 2020 at 01:28):
yes you'll see that but everything will still work
Shamil Nizamov (Aug 21 2020 at 15:05):
Grahame Grieve said:
yes you'll see that but everything will still work
I had to wait a bit longer. I see now.
Michael van der Zel (Oct 02 2020 at 10:14):
I am getting this exception and don't know where to start looking :-(
org.hl7.fhir.exceptions.FHIRException: Error doing replacements - no id defined in resource: event-statusReason
at org.hl7.fhir.igtools.publisher.IGKnowledgeProvider.doReplacements(IGKnowledgeProvider.java:153)
at org.hl7.fhir.igtools.publisher.Publisher.load(Publisher.java:3116)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:865)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:725)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:8335)
Grahame Grieve (Oct 02 2020 at 10:15):
do you hve a resource for event status reason?
Michael van der Zel (Oct 02 2020 at 10:21):
Sorry. Posted to quickly. Extension.id used to be automatically populated so I ommited it. Just adding the id fixed the problem.
Michael van der Zel (Oct 02 2020 at 15:35):
I might have asked this before, but is there a required/proposed format for the urls for Profiles, ValueSets, Conceptmaps, Extensions? And where can I find that in de fhir specs or ig-publisher documentation? Thanks.
Jay Lyle (Oct 02 2020 at 17:54):
The publisher seems to have some very specific requirements for urls, and there is no balloted artifact or policy basis for these requirements. If our domain is va.gov, it's not clear why we should have to put an additional directory in the path to reiterate that, or to imply that an extension is constrained to use in a single IG.
Grahame Grieve (Oct 02 2020 at 22:06):
The IG publisher expects that all canonical URLs will be [base]/[type]/[id] where
- base is the base URL for the IG
- type is the type of the resource
- id is whatever you assign.
This pattern works best by far for a number of reasons. Because of this, the IG publisher enforces that you follow this pattern unless you are explicit that you don't want to for some resource (you can't accidentally not follow it).
there is no such rule that you have to put an additional directory in the path, but you very much should - it would be hopelessly confusing for all users if there were multiple IGs claiming to be http://va.gov. Nor is there ever any implication that an extension is constrained to use in a single IG unless you claim that it is
Michael van der Zel (Oct 05 2020 at 08:12):
We added the country code and ig to the base. So for example http://va.gov/fhir/us/vha-ampl-ig/StructureDefinition/VAPatient
Jay Lyle (Oct 05 2020 at 13:26):
I don't see anything wrong with giving the IG a URI.
e.g., http://va.gov/fhir/StructureDefinition/ImplementationGuide/vha-ampl-ig
But why should the pharmacy extension be
http://va.gov/fhir/us/vha-ampl-ig/StructureDefinition/medicationRequest-patientSelfMedication
rather than
http://va.gov/fhir/StructureDefinition/medicationRequest-patientSelfMedication
?
If I want to use that extension in a different IG, do I have to re-create it with a different name?
Grahame Grieve (Oct 05 2020 at 18:55):
As a publishing matter, http://va.gov/fhir/StructureDefinition/ImplementationGuide/vha-ampl-ig implies that this is the VA fhir guide and there won't be another. I think that's a bad idea that will create trouble down stream.
But why should the pharmacy extension be
http://va.gov/fhir/us/vha-ampl-ig/StructureDefinition/medicationRequest-patientSelfMedication
rather than
http://va.gov/fhir/StructureDefinition/medicationRequest-patientSelfMedication
The implication of the question is that the IG publisher is demanding that, in which case something is set up wrongly somewhere
If I want to use that extension in a different IG, do I have to re-create it with a different name?
what do you mean by "use". I think you mean, publish again differently, in which case the answer is 'yes'
Jay Lyle (Oct 05 2020 at 20:46):
I seem to have some assumptions that are out of line with yours.
"all canonical URLs will be [base]/[type]/[id]" sounds perfectly reasonable. But asserting that the base has to include the html IG you happen to first publish an asset in seems counterintuitive.
Are you saying that the html publication URL constrains the asset (extension, profile, value set) URIs?
I think an extension (or profile, or value set) should be reusable, and you should be able to include it in as many guides as you'd like without having to re-name it.
(And it's not obvious to me that any of these implies it is the only VA guide:
http://va.gov/fhir/StructureDefinition/ImplementationGuide/vha-ampl-ig
http://va.gov/fhir/StructureDefinition/ImplementationGuide/vha-lab-ig
http://va.gov/fhir/StructureDefinition/ImplementationGuide/vha-rad-ig)
What am I missing?
Grahame Grieve (Oct 06 2020 at 04:47):
But asserting that the base has to include the html IG you happen to first publish an asset in seems counterintuitive.
it shouldn't be. The IG is published at a location that people can find. If you put the IGs in the same directory, you'll have problems with the definitions running into each other. For that reason, we always separate all the IGs by their namespace. It helps a lot when it comes to publishing and managing the content. But you don't have to do it that way - you can make it a lot more complicated for yourself and your users if you want. The IG publisher won't stop you. You just won't get a lot of support for other downstream things you'll want to do
Grahame Grieve (Oct 06 2020 at 04:47):
Are you saying that the html publication URL constrains the asset (extension, profile, value set) URIs?
yes, for publishing reasons. Though as I said, it doesn't have to
Grahame Grieve (Oct 06 2020 at 04:49):
I think an extension (or profile, or value set) should be reusable, and you should be able to include it in as many guides as you'd like without having to re-name it.
that depends on what you mean by "include". The way FHIR definitions and publishing are set up, you define things once, and then you reuse the definition everywhere. The publishing tools do not make it easy at all to re-publish the definition of an asset in more than one place, and I highly recommend that you shouldn't do that.
Grahame Grieve (Oct 06 2020 at 04:49):
You'll have many many problems if you do that
Grahame Grieve (Oct 06 2020 at 04:50):
http://va.gov/fhir/StructureDefinition/ImplementationGuide/vha-ampl-ig
(those, btw, are wrong): http://va.gov/fhir/ImplementationGuide/vha-ampl-ig
Grahame Grieve (Oct 06 2020 at 04:52):
of course they are different. But the things they also contain, you'll have to keep them separate somehow, and no one will be sure what declares what. That's why we always maintain the guide id in the root of the url - so http://va.gov/fhir/ampl/ImplementationGuide/vha-ampl-ig
Jay Lyle (Oct 06 2020 at 13:19):
OK, well that's clearer; thanks. Without having published a lot of these, I'm not feeling the pain you foresee. FHIR publishes extensions you can use in different guides: has that been a problem?
Michael van der Zel (Oct 06 2020 at 13:41):
But this is "only" the uri for the implementation guide. Was the uri for the extensions and profiles ok?
http://va.gov/fhir/us/vha-ampl-ig/StructureDefinition/VAPatient
and
http://va.gov/fhir/us/vha-ampl-ig/StructureDefinition/medicationRequest-patientSelfMedication
Grahame Grieve (Oct 06 2020 at 19:08):
FHIR publishes extensions you can use in different guides: has that been a problem?
no. We do that lots. And we use extensions defined in one IG in other IGs - we do that lots too
Grahame Grieve (Oct 06 2020 at 19:08):
@Michael van der Zel : yes
Lin Zhang (Oct 07 2020 at 04:12):
Reusability and modularity are good, especially for those who don't have national/local IGs yet.
Jay Lyle (Oct 08 2020 at 19:58):
I don't want to miss out on taking advantage of your experience, but I'm not grokking the downside to having IG-agnostic profiles & extensions.
Then this sounds like there isn't one:
Grahame Grieve said:
FHIR publishes extensions you can use in different guides: has that been a problem?
no. We do that lots. And we use extensions defined in one IG in other IGs - we do that lots too
Is the issue that the IG is the only path for organizations that are not HL7 to publish?
Grahame Grieve (Oct 13 2020 at 21:23):
@Jay Lyle I don't understand this question. If you want to use an IG, then you are going to publish?
Jay Lyle (Oct 14 2020 at 15:25):
The intent is to publish an IG for this domain. But if there are extensions or profiles we expect to be used in other IGs, we'd like a way to publish those in a common namespace for general re-use. Maybe that's another IG.
Grahame Grieve (Oct 14 2020 at 19:25):
yes. An IG is the publishing vehicle we have, and so it would make total sense to have a general library IG. It wouldn't be necessary for it to call itself an IG (e.g. "VA Common Extensions and Terminologies"), but that's how the publishing would see it.
It's possible to use them without publishing them in some manageable fashion, but that's certainly more work in the longer term.
Martin Morrey (Oct 19 2020 at 12:55):
Hi. I am suddently seeing the following error from the IG Publisher running on FSH/Sushi generated input, across several IGs that were previously building fine:
Publishing Content Failed: Unable to find preProcessInfo for basePath: <project-root>\input\includes
All suggestions very welcome!
Lloyd McKenzie (Oct 19 2020 at 14:43):
Are you using one of the standard templates?
Martin Morrey (Oct 19 2020 at 15:49):
I am using David Hay's templates, specifically https://github.com/HL7NZ/nzbase/tree/master/nzBaseTemplate/package, which is based on fhir.base.template
When use "template = fhir.base.template" I still get the same error
Lloyd McKenzie (Oct 19 2020 at 16:23):
Do you have an input/includes folder?
Martin Morrey (Oct 19 2020 at 16:33):
Yes, sushi writes "menu.xml" into that folder. There's nothing else in there.
Martin Morrey (Oct 19 2020 at 16:36):
I've been cutting the menu down, guessing that might be part of the problem, so now its just
<ul xmlns="http://www.w3.org/1999/xhtml" class="nav navbar-nav">
<li>
<a href="index.html">IG Home</a>
</li>
<li>
<a href="profiles.html">Profiles</a>
</li>
</ul>
Chris Moesel (Oct 19 2020 at 16:37):
Is this using the SUSHI 1.0.0 Beta, which writes to fsh-generated/input/includes? If so, are you using a #current version of the templates? The support for finding fsh-generated/input/includes is only in #current version templates.
Martin Morrey (Oct 19 2020 at 16:40):
">sushi -version" gives:
"SUSHI v0.16.0 (implements FHIR Shorthand specification v0.13.x)"
The above is after doing "> npm update fsh-sushi" with the hope of fixiing problem. I'm not sure which version it was before, but I only installed it quite recently
Chris Moesel (Oct 19 2020 at 16:42):
OK, then... that's not it! That version of SUSHI writes directly to input/includes.
Martin Morrey (Oct 19 2020 at 16:44):
I am running publisher.jar in the following version of Java, is that likely to be an issue?
- openjdk version "15" 2020-09-15
Lloyd McKenzie (Oct 19 2020 at 16:47):
Not likely
Martin Morrey (Oct 19 2020 at 16:48):
I have tried 1.1.34 and 1.1.35 releases of publisher.jar. 1.1.34 was working fine last week, but both now fail with the same error
Chris Moesel (Oct 19 2020 at 16:54):
Is it possible that one of your templates is corrupt? All the templates are in the cache's packages folder.
For example: C:\Users\{user}\.fhir\packages\fhir.base.template#current (windows) or /Users/{user}/.fhir/packages/fhir.base.template#current (mac). If you find the relevant templates (and versions) in your cache, you could delete them or rename them so the publisher won't find them. Then it will force the publisher to download new versions.
Martin Morrey (Oct 19 2020 at 17:09):
That sounded promising, but I deleted .fhir/packages and .fhir/package-client in turn, and still getting the same error.
Chris Moesel (Oct 19 2020 at 17:23):
Ugh. :frown: I got nothing. Is this IG available publicly for someone to try to reproduce? It sounds outside my wheelhouse, but I could at least confirm if I get the same error -- and then that would help Lloyd or Grahame narrow down the issue.
Martin Morrey (Oct 19 2020 at 17:37):
No problem. Many thanks for all the help so far. As noted above, I am getting the same error running David Hay's New Zealand IGs, for example https://github.com/HL7NZ/northernRegion
They were working fine last week, which makes me think a corrupted cache / temp file sitting somewhere might well be the answer
Martin Morrey (Oct 19 2020 at 17:40):
This is the full stack dump I am getting, in case that helps diagnose
Stack Dump (for debugging): (00:18.0928)
java.lang.Exception: Unable to find preProcessInfo for basePath: C:\projects\my-IG\input\includes
at org.hl7.fhir.igtools.publisher.Publisher.loadPrePages(Publisher.java:3406)
at org.hl7.fhir.igtools.publisher.Publisher.loadPrePages(Publisher.java:3394)
at org.hl7.fhir.igtools.publisher.Publisher.load(Publisher.java:3108)
at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:865)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:725)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:8335)
Chris Moesel (Oct 19 2020 at 18:12):
OK. I was able to successfully run the northernRegion IG you linked above using FHIR IG Publisher Version 1.1.35 (Git# a4a66bd10efb). Built 2020-10-14T21:26:37.503Z (4 days old) on my Mac.
I did get one error in the log:
Error on line 2 column 1
SXXP0003: Error reported by XML parser: Content is not allowed in prolog.
Exception generating page /Users/cmoesel/dev/HL7/northernRegion/temp/pages/_includes/api.mdDEP: org.xml.sax.SAXParseException; lineNumber: 2; columnNumber: 1; Content is not allowed in prolog. (00:36.0277)
And several in the qa.html. But the IG Publisher did do a full run without crashing and I did not see the stack trace you reported above.
Jose Costa Teixeira (Oct 19 2020 at 18:33):
that seems because there is an extra file called api.mdDEP - should only have md and XML files there
Martin Morrey (Oct 19 2020 at 18:36):
Thanks. Running publisher.jar 1.1.35 on the same IG in Windows 10 PowerShell, all seems to be going well, and then this happens....
Initialization complete (00:16.0498)
Fetch http://hl7.org.nz/fhir/package-list.json for version check (00:16.0500)
Load Content (00:17.0102)
PreProcessInfo hash:{c:\projects\northernregion\.\input\pagecontent=org.hl7.fhir.igtools.publisher.Publisher$PreProcessInfo@691541bc, c:\projects\northernregion\.\input\includes=org.hl7.fhir.igtools.publisher.Publisher$PreProcessInfo@5b733ef7}
Publishing Content Failed: Unable to find preProcessInfo for basePath: C:\projects\northernRegion\input\includes (00:17.0404)
Chris Moesel (Oct 19 2020 at 19:03):
On my successful build, using the same version of the IG Publisher, I have Processing Conformance Resources directly after the Load Content log:
Load Content (00:19.0101)
Processing Conformance Resources (00:19.0440)
Grahame Grieve (Oct 20 2020 at 03:44):
this is a problem related to how you are invoking the ig. It's something I haven't got to the bottom of yet, but note that the '.' disappears from your path. You need to invoke it with out that
Martin Morrey (Oct 20 2020 at 09:25):
Grahame, you are bang-on. Thank-you!
I was invoking as follows:
java -jar C:\tools\IG-Publisher\publisher.jar .\ig.ini
When I do it without the dot, it works fine:
java -jar C:\tools\IG-Publisher\publisher.jar ig.ini
Windows Powershell seems to default to putting the dot in there for some reason :rage:
Grahame Grieve (Oct 20 2020 at 11:44):
I have to figure this one out
Chris Moesel (Oct 20 2020 at 13:39):
Mystery solved (sort of). Thanks, @Grahame Grieve!
Shahim Essaid (Nov 04 2020 at 20:58):
I'm trying to figure out if a static site for the "output" folder can behave as if there is a FHIR server serving those resources. Is there a way for accomplishing this with some Publisher configuration parameters? I'm assuming it might work if the IG Publisher can also output a copy of the various resources at the same location that it would be retrievable from a FHIR server assuming the "output" folder stands for the canonical part, let's say in the JSON format. i.e., create the "../output/StructureDefinition/some-id" in addition to the "../output/StructureDefinition-some-id.json"
Michele Mottini (Nov 04 2020 at 21:53):
Search would not really work
Shahim Essaid (Nov 04 2020 at 22:03):
Sure, I understand all the limitations, but I'd be happy with just a GET working for now. Just curious if there is already a setting for this. I can write a script to generate this if that's the only option.
Lloyd McKenzie (Nov 04 2020 at 22:03):
Not really - a server needs to look at the 'Accept' header and return the appropriate file. And how you configure varies by web server.
Lloyd McKenzie (Nov 04 2020 at 22:04):
@Grahame Grieve does some magic to get the output of the publication process to have what we need in our hosting environment
Shahim Essaid (Nov 04 2020 at 22:30):
I tried this with GitHub and it seems to return a file without any Accept headers in the request, and also with application/json, as text/plain. However, based on the spec, a generic spec compliant client would not accept this return type according to http://hl7.org/fhir/http.html#summary
This might still be a useful feature if a client can figure out the returned content type and act accordingly.
Grahame Grieve (Nov 04 2020 at 22:56):
So the way we look at this is that organising this is a hosting question, not an IG question. HL7 has a downstream process that takes an IG and publishes it, and during the publication step, one of the many things that happens is that we generate server specific (e.g. apache, nginx, IIS etc) redirects and scripts that make the accept header work.
Grahame Grieve (Nov 04 2020 at 22:56):
since what we need is server specific, it's not generated as part of the IG itself
Shahim Essaid (Nov 04 2020 at 23:03):
Are those tools reusable by the community? If yes, any pointers to them and any related documentation? Thanks!
Grahame Grieve (Nov 05 2020 at 06:35):
yes, they are built into the IG publisher. As for documentation... I'm afraid not. It's sorely lacking and a common request and it's on my todo list
Ramandeep Dhanoa (Nov 27 2020 at 21:27):
I am getting the following error when running the ig.ini file through publisher:
image.png
Any idea what I am missing @Lloyd McKenzie
David Hay (Nov 27 2020 at 21:41):
You could try adding the version explicitly - ie template = fhir.base.template#current - though it looks that it's trying and failing that...
Ramandeep Dhanoa (Nov 27 2020 at 22:06):
Yes tried that as well, same error message. I was thinking if there is a need to get the latest publisher, but link seems to be broken:
https://fhir.github.io/latest-ig-publisher/org.hl7.fhir.publisher.jar
Grahame Grieve (Nov 27 2020 at 22:06):
it looks like you're offline
Grahame Grieve (Nov 27 2020 at 22:07):
but where did you find that link to the last publisher? it's not valid anymore
Ramandeep Dhanoa (Nov 27 2020 at 22:09):
https://wiki.hl7.org/IG_Publisher_Documentation#Installing
Can you point me to new links?
Grahame Grieve (Nov 27 2020 at 22:10):
that page has been moved (as it says): https://confluence.hl7.org/display/FHIR/IG+Publisher+Documentation
Ramandeep Dhanoa (Nov 27 2020 at 22:50):
Thanks! I am running the latest publisher now, getting the following error -
Error loading template fhir.base.template: The package 'fhir.base.template' has no entry on the current build server.
Michael van der Zel (May 10 2021 at 18:36):
How does the counting of errors work in the IG-Publisher QA page? I am using IG Publisher Version: v1.1.68 and the total build error count is 13 and summing the error in the rows gives 31??
Grahame Grieve (May 10 2021 at 19:06):
hmm I would expect them to match
Jose Costa Teixeira (May 11 2021 at 07:42):
It seems the QA lists the errors by resource and then by type, so some errors are duplicate
Jose Costa Teixeira (May 11 2021 at 07:43):
there may be some errors in the QA (perhaps things like unresolved urls?) that only show up there, but I'm just guessing.
Warren Oliver (May 11 2021 at 23:14):
I'm trying to define a ValueSet where one of the entries is a specific code from SNOMED.
<include>
<system value="http://snomed.info/sct"/>
<concept>
<code value="252129004"/><!--Test duration-->
</concept>
</include>
When I do this the IG publisher is giving me the following error:
Error : Attempt to use Terminology server when no Terminology server is available.
Do I have an issue with my local setup? I do get this warning in my logs as well:
WARNING: Running without terminology server - terminology content will likely not publish correctly
Grahame Grieve (May 13 2021 at 00:34):
that's weird... are you running on a local PC?
Warren Oliver (May 13 2021 at 03:46):
I'm running it on a MacBookPro. I'm also getting this weird behaviour where if I run the publisher in UI mode it doesn't work but then if I run it in headless mode using -ig ./ig.ini it works!
Hamilton Lima (May 14 2021 at 19:54):
Hello everyone trying to use $next-question operation with no success, any tricks and tips?
Lloyd McKenzie (May 14 2021 at 19:55):
On what server? Does the server declare support for the operation and does it support the questionnaire you're using?
Hamilton Lima (May 14 2021 at 19:56):
ha that is the million dollar question that I dont know how to find the answer on HAPI FIHR server
Hamilton Lima (May 14 2021 at 19:56):
would that be in the conformance somewhere?
Hamilton Lima (May 14 2021 at 19:58):
that's the conformance data https://gist.github.com/hamilton-lima/8407c50dd137667aae0e2fe60b8be9c4
Lloyd McKenzie (May 14 2021 at 20:00):
It should show up as rest.resource.operation or rest.operation
Lloyd McKenzie (May 14 2021 at 20:00):
And it doesn't look like it's declared in their statement.
Hamilton Lima (May 14 2021 at 20:03):
oh well, it seems that I would need to find an implementation of this operation
Hamilton Lima (May 14 2021 at 20:03):
or do by it myself
Lloyd McKenzie (May 14 2021 at 20:06):
One of the things to consider is that $next-question isn't necessarily a 'generic' operation. The server actually needs to understand the questionnaire being used.
Hamilton Lima (May 14 2021 at 20:17):
thanks @Lloyd McKenzie very helpful
Michael van der Zel (May 17 2021 at 19:08):
Jose Costa Teixeira said:
It seems the QA lists the errors by resource and then by type, so some errors are duplicate
Looks to fixed in latest version of IG-Publisher 1.1.72.
Pranouti Patil (Jun 01 2021 at 05:34):
Hi,
I am facing the following issue in building the IG using igpublisher.
Installing hl7.terminology.r4#2.1.0 to the package cache
Fetching:Publishing Content Failed: Error reading http://packages.fhir.org/hl7.terminology.r4/2.1.0: Input is not in the .gz format (00:30.0364)
(00:30.0366)
Use -? to get command line help (00:30.0368)
(00:30.0369)
Stack Dump (for debugging): (00:30.0370)
java.io.IOException: Error reading http://packages.fhir.org/hl7.terminology.r4/2.1.0: Input is not in the .gz format
at org.hl7.fhir.utilities.cache.NpmPackage.readStream(NpmPackage.java:378)
at org.hl7.fhir.utilities.cache.NpmPackage.fromPackage(NpmPackage.java:369)
at org.hl7.fhir.utilities.cache.FilesystemPackageCacheManager.addPackageToCache(FilesystemPackageCacheManager.java:332)
at org.hl7.fhir.utilities.cache.FilesystemPackageCacheManager.loadPackage(FilesystemPackageCacheManager.java:483)
at org.hl7.fhir.igtools.publisher.Publisher.loadUTG(Publisher.java:2322)
at org.hl7.fhir.igtools.publisher.Publisher.initializeFromJson(Publisher.java:2151)
at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1386)
at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:670)
at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:7915)
Caused by: java.io.IOException: Input is not in the .gz format
at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.init(GzipCompressorInputStream.java:193)
at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.<init>(GzipCompressorInputStream.java:167)
at org.apache.commons.compress.compressors.gzip.GzipCompressorInputStream.<init>(GzipCompressorInputStream.java:131)
at org.hl7.fhir.utilities.cache.NpmPackage.readStream(NpmPackage.java:376)
... 8 more
Jose Costa Teixeira (Jun 01 2021 at 07:16):
can you try to delete your input-cache folder and try again?
Pranouti Patil (Jun 01 2021 at 07:42):
Jose Costa Teixeira said:
can you try to delete your input-cache folder and try again?
deleted the cache, but still getting the same error
Grahame Grieve (Jun 01 2021 at 07:44):
it/s your .fhir packages folder that you need to clear out
Pranouti Patil (Jun 01 2021 at 08:22):
Grahame Grieve said:
it/s your .fhir packages folder that you need to clear out
Thanks for the quick reply, It helped a lot, the error got resolved
Ioana Singureanu (Aug 04 2021 at 18:29):
I'm experiencing a strange problem: the QA report indicates that I have broken link in my IG page by the link is valid. Not sure what to do next. How do I fix a valid link?
index.html#/html/body/div/div/div/div/div/ul/li/a at Line 201, column 8
error The link 'http://hl7.org/fhir/us/odh/' for "HL7 FHIR Profiles and patterns from Occupational Data for Health (ODH),Release 1.0" cannot be resolved
Jean Duteau (Aug 04 2021 at 18:40):
Change the link to be http://hl7.org/fhir/us/odh/index.html.
Ioana Singureanu (Aug 04 2021 at 19:10):
Has anyone encountered problems referencing ISO 3166-1-3 from their sample resources. I confirmed that AFG and IRQ are valid concepts yet the IG builder can't find them in the value set "http://hl7.org/fhir/ValueSet/iso3166-1-3"
Observation.component[0].value.ofType(CodeableConcept) (l30/c20) error None of the codings provided are in the value set http://hl7.org/fhir/ValueSet/iso3166-1-3 (http://hl7.org/fhir/ValueSet/iso3166-1-3), and a coding from this value set is required) (codes = urn:iso:std:iso:3166#IRQ)
-- this is happening in a local build not the CI build
Lloyd McKenzie (Aug 04 2021 at 22:08):
The system for ISO country codes is "urn:iso:std:iso:3166" as per the terminology page (http://build.fhir.org/terminologies-systems.html). All 3 syntaxes (2-char, 3-char and numeric) are considered to be part of a single code system.
Lloyd McKenzie (Aug 04 2021 at 22:08):
Sorry, mis-read your issue.
Lloyd McKenzie (Aug 04 2021 at 22:09):
Looking here: http://hl7.org/fhir/R4/valueset-iso3166-1-3.html, I see AFG and IRQ. Is your local build hitting the terminology server? Have you tried wiping your cache?
Jose Costa Teixeira (Aug 05 2021 at 06:04):
i think it' s an issue with the tx server
Jose Costa Teixeira (Aug 05 2021 at 06:04):
https://tx.fhir.org/r4/ValueSet/iso3166-1-3/$validate-code?system=urn:iso:std:iso:3166&code=USA
Lloyd McKenzie (Aug 05 2021 at 15:09):
@Rob Hausam
Rob Hausam (Aug 05 2021 at 15:22):
There's also a terminology stream topic on this. I'll try to look into this further today and report back on both streams.
Last updated: Apr 12 2022 at 19:14 UTC
