Stream: IG creation
Topic: CapabilityStatement.profile vs .supportedProfile
Vassil Peytchev (Nov 12 2021 at 20:06):
I am trying to include the following in an IG:
- an IG-defined, quite general profile on Observation
- the core spec vital signs profile on Observation (which satisfies all the requirements of the IG-defined profile)
It looks like within a capability statement, there can be only one entry for each type of resource, so I can't simply add two independent entries of type Observation. I have added one entry of type observation that contains:
"type" : "Observation",
"profile" : "http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-observation",
"supportedProfile" : [
"http://hl7.org/fhir/StructureDefinition/vitalsigns"
],
"_supportedProfile": [
{
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/capabilitystatement-expectation",
"valueCode": "SHALL"
}
]
}
],
The IG publisher has no issues with it, but there is no indication in the (locally) generated content that the "supported profile" is part of the implementation guide. Is there something I need to add for the publisher to add a note and a link to the core profile of vital signs?
Possibly related: In US Core, I see an extensive XHTML block in CapabilityStatement.text, but with the designation "derived". Is there a tool to generate such a block, or is it strictly a manual process?
Grahame Grieve (Nov 12 2021 at 20:13):
the CapabilityStatement is ignoring the supportedProfile, yes. I can - and should - update so it shows the supported profiles.
@Eric Haas does have a tool to generate narrative, and I presume that's what you're talking about. You can use that, though in general it's better if we can work to make the default presentation the right one
Vassil Peytchev (Nov 12 2021 at 20:18):
If I created a narrative, is that what will show for the capability statement? I could take the default presentation, and place it in .text with the addition of the external profile (until the default presentation is enhanced).
Eric Haas (Nov 12 2021 at 21:01):
@Eric Haas does have a tool to generate narrative, and I presume that's what you're talking about. You can use that, though in general it's better if we can work to make the default presentation the right one
I looked at doing this in liquid it is too hard. I would be very loathe to give it up my generation tool.
Jean Duteau (Nov 12 2021 at 21:17):
I too created a narrative for my CapabilityStatement and put it in the text. It was quite long and the narrative shows up in two places in the guide so I'm not sure I'm going to keep it.
Gino Canessa (Nov 12 2021 at 21:30):
Not far along enough to post yet, but it was frustrating enough for me that I'm building some tooling to help with this =).
Grahame Grieve (Nov 12 2021 at 22:06):
you know, all of you, you can propose improvements in the default rendering instead of just doing your own thing
Grahame Grieve (Nov 12 2021 at 22:06):
If I created a narrative, is that what will show for the capability statement? I could take the default presentation, and place it in .text with the addition of the external profile
Grahame Grieve (Nov 12 2021 at 22:06):
yes you can do that
Grahame Grieve (Nov 12 2021 at 22:07):
maybe I should take it away so that people actually contribute to the default rendering instead of doing their own thing and not helping everyone else
Gino Canessa (Nov 12 2021 at 22:26):
Grahame Grieve said:
you know, all of you, you can propose improvements in the default rendering instead of just doing your own thing
Yes, but I'm not trying to just fix the rendering. I found the process of hand-writing Capability Statements (and tagging every element with a conformance level) too tedious to actually do.
I'm building an light app to load an IG (already run through publisher) that lets you select what goes into the CapStatment. I was going to build the narrative in it too, since the goal is to output JSON or FSH that you can re-insert into the IG.
I'd be happy to push back the format for narrative once I've settled on something - but I have no idea where that lives today (Java code?).
Grahame Grieve (Nov 12 2021 at 22:31):
Gino Canessa (Nov 12 2021 at 22:33):
Cool. I'll have to burn that bridge when I get to it, since I don't have a Java dev env set up. But saved the link and added to my list (need to finish the UI to build the cap statement first, since I'm still not doing that by hand).
Jean Duteau (Nov 13 2021 at 00:11):
I understand your concern. In my case, I added a ton of text that no renderer could possibly know about. I'm not sure where that text would go since it is purely about providing a non-technical person an understanding of the capabilities that the statement is asserting via its data elements.
Grahame Grieve (Nov 13 2021 at 00:14):
than you're in manual space for sure. And I don't mind people doing whatever in their tooling, it's just frustrating if that means we don't continue to iterate to improve the default
Vassil Peytchev (Nov 15 2021 at 18:22):
you can propose improvements in the default rendering instead of just doing your own thing
I tried to add supportedProfile (see diff), but that broke validation somehow. Should I just create an issue, or is there a simple extra step I need to address?
--- a/org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/renderers/CapabilityStatementRenderer.java
+++ b/org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/renderers/CapabilityStatementRenderer.java
@@ -14,6 +14,7 @@ import org.hl7.fhir.r5.model.CapabilityStatement.ResourceInteractionComponent;
import org.hl7.fhir.r5.model.CapabilityStatement.SystemInteractionComponent;
import org.hl7.fhir.r5.model.CapabilityStatement.SystemRestfulInteraction;
import org.hl7.fhir.r5.model.CapabilityStatement.TypeRestfulInteraction;
+import org.hl7.fhir.r5.model.CanonicalType;
import org.hl7.fhir.r5.renderers.utils.RenderingContext;
import org.hl7.fhir.r5.renderers.utils.BaseWrappers.ResourceWrapper;
import org.hl7.fhir.r5.renderers.utils.Resolver.ResourceContext;
@@ -82,8 +83,27 @@ public class CapabilityStatementRenderer extends ResourceRenderer {
for (CapabilityStatementRestResourceComponent r : rest.getResource()) {
tr = t.tr();
tr.td().addText(r.getType());
- if (r.hasProfile()) {
- tr.td().ah(r.getProfile()).addText(r.getProfile());
+ if (r.hasProfile() && r.hasSupportedProfile()) {
+ XhtmlNode profileNode = tr.td().ah(r.getProfile()).addText(r.getProfile());
+ for (CanonicalType sp: r.getSupportedProfile()) {
+ profileNode.br();
+ profileNode.nbsp().nbsp();
+ profileNode.ah(sp.getValue()).addText(sp.getValue());
+ }
+
+ if (r.hasSupportedProfile()) {
+
+ }
+ }
+ if (!r.hasProfile() && r.hasSupportedProfile()) {
+ boolean first = true;
+ XhtmlNode profileNode = tr.td();
+ for (CanonicalType sp: r.getSupportedProfile()) {
+ if (!first) {
+ profileNode.br();
+ }
+ profileNode.ah(sp.getValue()).addText(sp.getValue());
+ }
}
tr.td().addText(showOp(r, TypeRestfulInteraction.READ));
if (hasVRead)
Grahame Grieve (Nov 15 2021 at 19:35):
this doesn't show any difference between the two kids of profile? And how many supported profiles before this starts to be a problem?
Grahame Grieve (Nov 15 2021 at 19:35):
And how did it break validation somehow?
Vassil Peytchev (Nov 15 2021 at 19:59):
I got "Test Failed" for validation, but when I ran maven clean install there were no failed tests. Created an issue and PR is running checks right now.
this doesn't show any difference between the two kinds of profile? And how many supported profiles before this starts to be a problem?
If there are both .profile and .supportedProfile, it would look something like this:
+-------------+-----------------------------
| Observation | <.profile URL>
| | <.supportedProfile URL 1>
| | <.supportedProfile URL 2>
| | ...
In the cases when there are only .supportedProfile entries, and no .profile (like US Core), it will just list them, with no indentation.
Grahame Grieve (Nov 15 2021 at 20:13):
I think that's too subtle. I think that there should be separate table cells for profile and supported profile, so that people are clear. They're very different things. And I note that there's a bug around the profile cell - heading and cell don't line up on being shown
Vassil Peytchev (Nov 15 2021 at 20:32):
Are you suggesting something like this:
+-------------+------------------------------+------------------------------
| Resource | Profile | Supported Profile
+-------------+------------------------------+------------------------------
I think that will make the table too wide. Maybe still one cell, but more obvious, like this:
+-------------+-----------------------------
| Observation | <.profile URL>
| | Additional supported profiles:
| | <.supportedProfile URL 1>
| | <.supportedProfile URL 2>
| | ...
and for the cases where there are only .supportedProfile entries:
+-------------+-----------------------------
| Observation | Supported profiles:
| | <.supportedProfile URL 1>
| | <.supportedProfile URL 2>
| | ...
Grahame Grieve (Nov 15 2021 at 20:33):
ok that makes sense
Vassil Peytchev (Nov 15 2021 at 20:38):
The PR checks tell me I need to add tests for the code changes, any hint what types of tests I need to add?
Grahame Grieve (Nov 15 2021 at 20:40):
because code coverage failed? That's advisory, something we're chipping away at over time. And there's no tests covering this part of the code yet, and so it's too big a lift. I mean, you can if you want - that would be in https://github.com/FHIR/fhir-test-cases/tree/master/r5/narrative but I wouldn't (and I'll approve the PR without it)
Josh Mandel (Nov 15 2021 at 21:30):
Grahame Grieve: you know, all of you, you can propose improvements in the default rendering instead of just doing your own thing
I'd maybe "hear" the various efforts here as proposals for improvements (indeed, the best kind: specific proposals where the details have been worked through)
Grahame Grieve (Nov 15 2021 at 21:32):
well, I tried, but in practice, what happens is people make their own thing, and never bring any discussion forward, and so it doesn't turn into actual proposals. This one has turned into a very concrete proposal..
Vassil Peytchev (Nov 15 2021 at 21:55):
PR #661 is running checks...
Last updated: Apr 12 2022 at 19:14 UTC
