Stream: committers
Topic: IHE Documents
Grahame Grieve (Dec 02 2016 at 04:27):
@John Moehrke I am reviewing a couple of ITI FHIR profiles.... can we try a project where we take something IHE and publish it via the FHIR IG publisher?
Grahame Grieve (Dec 02 2016 at 04:28):
I reckon the existing IHE documents are not very good, where as a hybrid IG following the overall IHE structure but as a FHIR IG would be pretty cool
John Moehrke (Dec 02 2016 at 14:54):
I would like to try. It is not clear to me what it looks like because of the dual publication situation. This is the work I intended to do under the Document Sharing PSS. I would be happy to get advanced work done investigating various methods
John Moehrke (Dec 02 2016 at 14:58):
The existing IHE layout should not be seen as an impediment. The FHIR IG layout seems highly inspired by IHE, with slightly different format given html publication system available to FHIR. This is especially true of what IHE publishes in Volume 1. The Volume 2 might not be used at all, from an IHE perspective we might need a volume 6. Or no second volume as the technical details are the part I expect to exist on fhir.org
John Moehrke (Dec 02 2016 at 15:03):
There are a few NEW work items in IHE that will be profiling FHIR - starting now. If we can get cooperation going, then we could pick one of them to be written from the ground up as a joint work.
John Moehrke (Dec 02 2016 at 15:08):
One of those new work items is a joint work with Argonaut on provider directory... a situation of taking mostly what argonaut has done and officially taking it on for long-term maintenance in IHE.
Grahame Grieve (Dec 02 2016 at 18:57):
dual publication? I had in mind that IHE would publish
John Moehrke (Dec 02 2016 at 19:04):
IHE already publishes... then, what did you mean by " take something IHE and publish it via the FHIR IG publisher?"
John Moehrke (Dec 02 2016 at 19:06):
IHE does not use any of the fhir.org tools, including Forge, Simplifier, etc. I was hoping to get the technical bits published on fhir.org; while the human readable prose was still published in the normal IHE profile way.
Grahame Grieve (Dec 02 2016 at 19:06):
so right now, IHE author's documents, and publishes PDF. In my alternate universe, IHE would edit value sets and profiles, and html, and then publish to a web format produced by the IG Publisher
Grahame Grieve (Dec 02 2016 at 19:07):
so I'm thinking of going a step further than you
Grahame Grieve (Dec 02 2016 at 19:07):
still write the same human readable prose, but in HTML or markdown
John Moehrke (Dec 02 2016 at 19:08):
okay, that i what I was suggesting a few hours ago. So I got confused by your latest questnio.
John Moehrke (Dec 02 2016 at 19:08):
This would need to be dual published... right? dual (fhir.org and ihe.net). right?
John Moehrke (Dec 02 2016 at 19:12):
I expect an IG is needed to hold together the constraints, and value-sets... so some thin IG is needed. I would start with a very thin IG to keep dual publication to a minimum, while expressing visibility.
John Moehrke (Dec 02 2016 at 19:16):
Making the FHIR editing tool the primary editing tool might happen quickly, but right now IHE is rather stuck in their Technical Framework -- PDF -- publication mechanism. There are efforts to change this, I hope it happens.
Grahame Grieve (Dec 02 2016 at 20:07):
no need for dual publishing. can be published at ihe.net. or can be published on fhir.org or even hl7.org but ihe.net would be the logical place
Grahame Grieve (Dec 02 2016 at 20:08):
it would be much better for implementers if IHE published via the IG publisher framework - there's downstream tooling/conformance advantages
John Moehrke (Dec 03 2016 at 15:53):
can you explain those downstream tooling/conformance advantages? I ask as you have a better view over the horizon. I am pushing for this cooperation exactly for the use of the profile registry and conformance bits (as seen in Conformance Module in fhir). Sounds like additional benefits you call 'tooling'?
Grahame Grieve (Dec 03 2016 at 20:05):
well, publishing via that IG publisher route produces an IGPack.zip which can be used directly by the validator, and by other derived implmentation guides (say, vendor guides about their conformance with the IG). Also, the IGPack.zip contains, in addition to the conformance resources, links into the spec itself so that validators can take hte user directly to the page that is the source of the validation error. The IGs produced this way are also deeply linked to the correct FHIR version
Eric Haas (Dec 04 2016 at 06:44):
For an example check out: http://hl7.org/fhir/us/core/index.html
the stuff grahame is talking about is:
http://hl7.org/fhir/us/core/definitions.json.zip
http://hl7.org/fhir/us/core/definitions.ttl.zip
http://hl7.org/fhir/us/core/definitions.xml.zip
Last updated: Apr 12 2022 at 19:14 UTC
