Stream: conformance
Topic: Enhancements to Profile viewing
Grahame Grieve (Sep 18 2019 at 10:28):
A group of us discussed profile rendering last night. We're going to trial several improvements to the way profiles are rendered in IGs:
- add a must-support only view
- display extensions like other slices
- Use a special representation for patterns for CodeableConcept and Identifier
- Represent the Profile has a form (SDC Questionnaire)
- hide Element.id, Element.extension, Element.modifier extension in snapshots unless they have been profiled
- generate a modifier element summary
- generate a navigational summary for profiles on some high value resource types(Observation, at least)
- Add a mindmap view based on must-Support elements
- work to improve the text summary
Also: enhance the examples to provide links to the profile definitions on the element names (and fix this for Json in the build)
- on a related topic: we propose that FHIR-I create a project for a DSL for conformance resources (StructureDefinition, ValueSet, ConceptMap at least)
Michel Rutten (Sep 18 2019 at 12:12):
How about re-ordering extensions to appear _after_ inherited elements, like Forge?
Grahame Grieve (Sep 18 2019 at 12:13):
I did that initially but got strong pushback against it because things were out of order.
Grahame Grieve (Sep 18 2019 at 12:13):
... tells you who cares about XML or not
Michel Rutten (Sep 18 2019 at 12:36):
I understand such push back in the initial FHIR design phase, when we were all inspecting handcrafted XML and JSON resources. However do we really need to maintain this "convention" forever? Seems to me that we are bothering modelers with idiosyncrasies of the internal serialization formats, for historic reasons only.
Lloyd McKenzie (Sep 18 2019 at 12:44):
It's not historic. It's current. You must maintain the order in XML. Listing things in the display view in the wrong order causes implementation grief. (And for those who do JSON but are still thinking about the models from a class inheritance perspective, it's also confusing.)
Michel Rutten (Sep 18 2019 at 13:08):
I see your point and respectfully disagree. Modelers should not concern about serialization formats. That is a responsibility of a developer. Some community members combine both roles, however I would still consider them separate audiences with separate needs. Just my 2c.
Grahame Grieve (Sep 18 2019 at 13:12):
presenting profiles in published IGs is not for modelers. Forge is
Lloyd McKenzie (Sep 18 2019 at 13:12):
These views are targeted at developers. In fact, IGs as a whole are targeted at developers
Michel Rutten (Sep 18 2019 at 13:14):
I guess I am more on Mark Kramer's side.
Grahame Grieve (Sep 18 2019 at 13:17):
What's Mark's side?
Michel Rutten (Sep 18 2019 at 13:25):
The alternative approaches that Mark is proposing (CIMPL, FSH) seem to hide/abstract the details of the underlying serialization formats.
Mark Kramer (Sep 18 2019 at 13:47):
On the DSL topic, here is the latest draft of the FHIR Shorthand proposal: FHIR-Shorthand-v3.docx
Lloyd McKenzie (Sep 18 2019 at 13:51):
As I understand it, @Mark Kramer is arguing for increased understandability. He hasn't argued that IGs aren't primarily for implementers
Mark Kramer (Sep 18 2019 at 14:01):
With @Brian Postlethwaite and others, I am advocating FOR aligning our representations of profiles with different types of audiences: clinical readers, informaticisits, implementers without much FHIR experience, implementers with FHIR experience, and IG developers. (Not to be confused or conflated with the push for FHIR Shorthand, to make IG implementers more productive.)
Brian Postlethwaite (Sep 18 2019 at 14:57):
@Mark Kramer I wouldn't say arguing, I'd say promoting better displays for the target audiences of our various IG consumers.
Mark Kramer (Sep 18 2019 at 15:55):
I clarified my remark. We are advocating FOR understanding and tailoring our views to audienceS.
Eric Haas (Sep 18 2019 at 23:27):
What is a navigational summary
Eric Haas (Sep 18 2019 at 23:38):
Also I have a template that produced a formal summary very rigid conformance type language but I think it’s a good place to start. If I can translate it to liquid or whatever template format the ig pub needs. Currently It does not do everything Like multiple types or choice.
Grahame Grieve (Sep 22 2019 at 01:24):
On the subject of improving the representation of resources - here's an attempt to summarise the observations in an IG (mCode, in this case).
Grahame Grieve (Sep 22 2019 at 01:24):
Grahame Grieve (Sep 22 2019 at 01:26):
I'm not at all happy with that, but I wonder whether mCode would do some work given that presentation - it seems.... sub-optimal because of input. I'm still working on improving it and I think I have some problems with the types columns
Grahame Grieve (Sep 22 2019 at 01:27):
in particular, the generated profile names are horrible.
Eric Haas (Sep 22 2019 at 23:52):
in particular, the generated profile names are horrible.
They should be the SD.title so is the responsibility of the IG editor and not a generated artifact
Grahame Grieve (Sep 23 2019 at 01:17):
Right
Mark Kramer (Sep 23 2019 at 19:57):
@Chris Moesel Want to address the name generation issues?
Grahame Grieve (Sep 23 2019 at 19:58):
spending time with mCode is.... illustrative. I'm going to try and find the time to make a bunch of comments; there seems to be a lot of extensions that shouldn't exist
Mark Kramer (Sep 23 2019 at 20:02):
Very interested in your suggestions on reducing the number of extensions in mCODE.
Chris Moesel (Sep 23 2019 at 20:11):
@Chris Moesel Want to address the name generation issues?
Yeah, I'm not sure why title is getting the fully qualified name of the elements. Because of the way our namespaces work, we do use the FQN in the id -- but certainly should not need it in the title.
Grahame Grieve (Sep 23 2019 at 20:12):
in terms of extensions, I see 2 lists of extensions - the short list on extensions.html, and then the actual list I generate, which is 3 x longer - what's the difference between 'primary extensions' and all the other ones?
Chris Moesel (Sep 23 2019 at 20:22):
So... in short, primary extensions should generally be those extensions that are directly used by one or more of the primary profiles or were specifically identified as primary by the IG author. The other extensions are likely reachable through more indirect paths through profiles and extensions.
I suspect a lot are due to a design decision we made early on that complex extensions would use fully defined sub-extensions (w/ their own standalone URLs) as opposed to "inline" sub-extensions (w/ a relative URL). I think we thought that was more in the spirit of re-usability (e.g., a sub-extension of A could be also be a sub-extension of B) -- but we recently revisited and determined that might not be the best approach. What we gain in theoretical reusability we lose in actual explosion of extensions.
Grahame Grieve (Sep 23 2019 at 20:41):
you are not using StructureDefinition.context ?
Grahame Grieve (Sep 23 2019 at 20:41):
and your IG rendering doesn't show where an extension is used. So it's impossible to get a sense of what is going on here
Chris Moesel (Sep 23 2019 at 21:41):
No, not using context. There are a few historical and technical reasons for that. We can discuss if you'd like, but short answer is we're not setting it.
In our template, we are outputting usage on the extension page. For example: mCODE AnatomicalLocation extension has the following at the bottom: pasted image
Chris Moesel (Sep 23 2019 at 21:41):
That's just using the snippet the IG producer builds for us.
Grahame Grieve (Sep 23 2019 at 21:42):
duh. didn't see it when I looked at the page :-(
Grahame Grieve (Sep 23 2019 at 21:43):
what's ActionRequest? A profile on... an abstract resource?
Grahame Grieve (Sep 23 2019 at 21:45):
what about this extension: https://build.fhir.org/ig/HL7/fhir-mCODE-ig/StructureDefinition-obf-ReferenceRange-extension.html
Grahame Grieve (Sep 23 2019 at 21:45):
where is it used?
Chris Moesel (Sep 24 2019 at 13:26):
what's ActionRequest? A profile on... an abstract resource?
Yes, in CIMPL, it's an Abstract class that contains some commonly inherited properties for entries that represent a request for an action to be performed. It shouldn't have a profile; there must be a mistake in a config or in the filtering logic.
Chris Moesel (Sep 24 2019 at 13:28):
what about this extension: https://build.fhir.org/ig/HL7/fhir-mCODE-ig/StructureDefinition-obf-ReferenceRange-extension.html
where is it used?
It doesn't appear to be used anywhere. This also seems to be an issue w/ the filtering. The mCODE IG was actually built out of a large set of CIMPL definitions w/ filtering applied to narrow the content to only mCODE-related items. It looks like some stragglers made it through the filter. We'll take a look and try to determine what's going on.
Grahame Grieve (Sep 24 2019 at 13:28):
Ok I’ll have another look when you’ve cleaned it up
Last updated: Apr 12 2022 at 19:14 UTC
