Stream: IG creation
Topic: sparse capabilitystatement
Jens Villadsen (Feb 24 2019 at 21:00):
The capabiltystatement template/"generated narrative" seems really sparse when using the IG Publisher. For instance, no OperationDefinitions are listed pr. default in the resulting HTML
Eric Haas (Feb 25 2019 at 01:37):
yes the generated narrative is pretty primitive. I have very recently made a Jinja2 template for STU3 Igs that looks like US Core (which is done by hand) and and works with the Python FHIR client. Here is an example. Lloyd has an xlst stylesheet that give a more complete narrative too.
Jens Villadsen (Feb 25 2019 at 07:57):
where's @Lloyd McKenzie's stylesheet?
Jens Villadsen (Feb 25 2019 at 14:17):
Where's the template/code located for the current generation?
Eric Haas (Feb 25 2019 at 15:38):
I Yes curre you need to make your own narrative currently. I have a ninja template I’ve worked on for my most recent iG. Which looks like US Core. And Lloyd has a xlst too
Lloyd McKenzie (Feb 25 2019 at 16:22):
The XSLT is checked into the source folder for CapabilityStatement. You can find it here: https://github.com/HL7/fhir/blob/master/source/capabilitystatement/capabilitystatementNarrative.xslt
Grahame Grieve (Mar 03 2019 at 19:58):
the intention is to use Liquid templates for narrative generation in cases like this
Jens Villadsen (Mar 03 2019 at 20:41):
And while we are at it -why are PATCH updates listed as "Updates", whereas PUT is listed as "Update". Why not just call PATCH updates "Patch" or something?
Grahame Grieve (Mar 03 2019 at 20:50):
And while we are at it -why are PATCH updates listed as "Updates", whereas PUT is listed as "Update". Why not just call PATCH updates "Patch" or something?
umm? where?
Jens Villadsen (Mar 03 2019 at 20:53):
@Grahame Grieve thats the default rendering of capability statements when run through the IGpub
Jens Villadsen (Mar 03 2019 at 20:54):
Grahame Grieve (Mar 03 2019 at 21:04):
ok so the bit that confused me is the idea that patches are listed as updates. the code ignore patch altogether
Jens Villadsen (Mar 03 2019 at 21:05):
Jens Villadsen (Mar 03 2019 at 21:05):
I dont think it does ...
Grahame Grieve (Mar 03 2019 at 21:05):
me, I'm just looking at the code....
Grahame Grieve (Mar 03 2019 at 21:05):
maybe it does something different than the actual code...
Jens Villadsen (Mar 03 2019 at 21:06):
wt*?
Grahame Grieve (Mar 03 2019 at 21:06):
the code ignores patch altogether
Jens Villadsen (Mar 03 2019 at 21:07):
so where does the "Updates" come from? Because its produced for the exposed resources that only supports patch
Grahame Grieve (Mar 03 2019 at 21:08):
if the resource supports History at the instance level
Jens Villadsen (Mar 03 2019 at 21:09):
then what?
Grahame Grieve (Mar 03 2019 at 21:10):
that's where "Updates" comes from
Jens Villadsen (Mar 03 2019 at 21:13):
that explains
Grahame Grieve (Mar 03 2019 at 21:13):
I haven't thought of a better word for it
Jens Villadsen (Mar 03 2019 at 21:14):
but does that mean that history is the same as updates?
Grahame Grieve (Mar 03 2019 at 21:15):
"Updates" is what the narrative generator creates for the history-instance operation
Jens Villadsen (Mar 03 2019 at 21:16):
and "History" is created for ... ?
Grahame Grieve (Mar 03 2019 at 21:17):
history-type
Jens Villadsen (Mar 03 2019 at 21:20):
got it ...
Grahame Grieve (Mar 03 2019 at 21:21):
that's not a great arrangement, but nothing better leaps out at me
Jens Villadsen (Mar 03 2019 at 21:21):
whats history-type used for?
Grahame Grieve (Mar 03 2019 at 21:22):
that's the most common - get a list of changes for this type of resource
Grahame Grieve (Mar 03 2019 at 21:22):
where as history-instance is getting a list of changes for a single resource instance
Jens Villadsen (Mar 03 2019 at 21:24):
history -instance use I get ... that seems legit
Jens Villadsen (Mar 03 2019 at 21:25):
history-type however ...
Jens Villadsen (Mar 03 2019 at 21:25):
I don't get? you got an example?
Grahame Grieve (Mar 03 2019 at 21:28):
history-instance: GET [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]}
history-type: GET [base]/[type]/_history{?[parameters]&_format=[mime-type]}
history-system: GET [base]/_history{?[parameters]&_format=[mime-type]}
Jens Villadsen (Mar 03 2019 at 21:28):
thats what the doc says
Grahame Grieve (Mar 03 2019 at 21:29):
so I'm not clear on the question.
Jens Villadsen (Mar 03 2019 at 21:29):
wow .... history on type level
Jens Villadsen (Mar 03 2019 at 21:29):
as in across all instances of that type?
Grahame Grieve (Mar 03 2019 at 21:29):
yes. that's what we mostly use
Jens Villadsen (Mar 03 2019 at 21:31):
hmm ... okay I get it now ... - I guess that almost mandates some filtering for a clinical use case
Grahame Grieve (Mar 03 2019 at 21:31):
there's no filtering except by date. And implicitly by access right
Jens Villadsen (Mar 03 2019 at 21:33):
ok ... makes sense
Jens Villadsen (Mar 03 2019 at 21:35):
back to the wording "Updates" and "History" ...
Jens Villadsen (Mar 03 2019 at 21:35):
"History" makes sense
Jens Villadsen (Mar 03 2019 at 21:35):
"Updates" ... not so much ...
Jens Villadsen (Mar 03 2019 at 21:36):
and the code might wanna treat PATCH as update ... thats my suggestion
Grahame Grieve (Mar 03 2019 at 21:37):
well, I've already added a "Patch" column in my code here.
Jens Villadsen (Mar 03 2019 at 21:38):
what's ETA for that hitting the latest downloadable build?
Grahame Grieve (Mar 03 2019 at 21:38):
sometime today
Jens Villadsen (Mar 03 2019 at 21:40):
what about calling "History" for "History Type" and "Updates " for "History Instance"
Jens Villadsen (Mar 03 2019 at 21:40):
'cause thats what it is, right?
Grahame Grieve (Mar 03 2019 at 21:40):
That's what it now, yes
Jens Villadsen (Mar 03 2019 at 21:41):
Then I'll suggest that renaming ...
Jens Villadsen (Mar 03 2019 at 21:41):
instead of introducing "new terminology"
Grahame Grieve (Mar 03 2019 at 21:41):
which renaming?
Jens Villadsen (Mar 03 2019 at 21:42):
what about calling "History" for "History Type" and "Updates " for "History Instance"
Jens Villadsen (Mar 03 2019 at 21:44):
or I-History and T-History
Grahame Grieve (Mar 03 2019 at 21:44):
I think you are proposing to change the headers to History Type and History Instances. I didn't do that because of width concerns
Jens Villadsen (Mar 03 2019 at 21:45):
If you can call it "V-Read", then "T-History" would fit the bill as I see it
Grahame Grieve (Mar 03 2019 at 21:46):
I'm interested in opinions from other people before making this change
Jens Villadsen (Mar 03 2019 at 21:48):
sure - has anyone questioned the wording before?
Grahame Grieve (Mar 03 2019 at 21:48):
no you're the first. It's been in my server for 5 years. (I checked)
Jens Villadsen (Mar 03 2019 at 21:50):
so its crystal clear to everyone that "updates" is on instance level and "history" is type level? and no one has ever asked for PATCH before?
Grahame Grieve (Mar 03 2019 at 21:51):
I don't know about crystal clear but no one has ever asked before, no
Jens Villadsen (Mar 03 2019 at 21:51):
#feelinglikeafirstmover
Jens Villadsen (Mar 03 2019 at 21:54):
well - lets hope other opinionated people sees this ;)
Grahame Grieve (Mar 03 2019 at 21:57):
most of the people on this stream are opinionated. ;-)
Jens Villadsen (Mar 03 2019 at 21:57):
Let the opinions unfold
Lloyd McKenzie (Mar 03 2019 at 22:47):
I'm not a fan of V-Read or T-History. I'd like the names to make sense to someone who doesn't know FHIR. So that if they see a capability statement you have *some *idea what the server does.
Eric Haas (Mar 03 2019 at 23:44):
the intention is to use Liquid templates for narrative generation in cases like this
I don't know how to use liquid + ig.pub to do this. Which I why I am currently using Jinja2 with Python , between Jinja and liquid the template syntax themselves are very similar but how do I grab a resource element's value in the Ig pub? .. for example where r is is the resource
how I extract the title for {{r.title}}?
Eric Haas (Mar 03 2019 at 23:49):
I was never a fan of this table and abandoned it. I always have to go back read the spec for these interactions every time btw . I would like to add definitions as hovers or links in future renderings.
Grahame Grieve (Mar 03 2019 at 23:59):
liquid spec: http://wiki.hl7.org/index.php?title=FHIR_Liquid_Profile
Grahame Grieve (Mar 04 2019 at 00:04):
add fly overs. I'll commit so we can see my changes
Eric Haas (Mar 04 2019 at 00:08):
where do the liquid templates for narratives live?
Grahame Grieve (Mar 04 2019 at 00:16):
apparently I have not implemented this yet
Jens Villadsen (Mar 04 2019 at 08:02):
I'm not a fan of V-Read or T-History. I'd like the names to make sense to someone who doesn't know FHIR. So that if they see a capability statement you have *some *idea what the server does.
Well, how about adding the table from the top section from https://www.hl7.org/fhir/http.html to the generated site or add parts of it? IMHO, the current wording is confusing
Grahame Grieve (Mar 04 2019 at 08:58):
I should make them hyperlinks, I suppose. But what do you make of the changes I already made?
Jens Villadsen (Mar 04 2019 at 09:03):
The rearranging and patch? works for me
Grahame Grieve (Mar 04 2019 at 10:03):
great
Last updated: Apr 12 2022 at 19:14 UTC
