FHIR Chat · Adding Description for Examples to ImplementationGuide - how · IG creation

Stream: IG creation

Topic: Adding Description for Examples to ImplementationGuide - how

Saul Kravitz (Oct 21 2020 at 18:51):

How can I resolve this short of editing the IMplementationGuide JSON?

image.png

David Pyke (Oct 21 2020 at 18:57):

Many tools take the description from the profile/instance itself Make sure that your CoverageEx1 has a description/title/etc. element

Eric Haas (Oct 21 2020 at 19:25):

I think you are stuck editing the IG resource.

Eric Haas (Oct 21 2020 at 19:26):

(It would be nice to have a universal extension so the tooling could suck it up from the instance)

Eric Haas (Oct 21 2020 at 19:28):

...or you could add to your ignorewarnings.txt list

Lloyd McKenzie (Oct 21 2020 at 19:51):

Don't add it to "ignorewarnings" - this isn't one that's ignoreable - at least not for HL7-published IGs. You need to have a description or the artifact summary doesn't populate properly. If we put an extension in the source for an example, we'd have to strip it out before we published. That's theoretically doable, but I don't really understand why we'd rather put extensions in the examples than just reference the examples in the IG. (You need to declare what they're examples of in the IG anyhow if you don't want to declare profiles in the examples themselves - and it's generally poor practice to assert profiles in the instances.)

Saul Kravitz (Oct 21 2020 at 20:12):

I need a more specific recipe. Looking at http://build.fhir.org/ig/HL7/carin-bb/branches/v0.1.8/artifacts.html#example-example-instances
I have examples generated from FSH, that look fine: A hyperlink from the id in the first column, and the Title from the FSH input in the 2nd column.

The examples that I provided in JSON via the fsh/ig-data/input/examples folder only have a hyperlink from the first column, and a blank 2nd column.
image.png

What do I need to do (please don't tell me to edit the ImplementationGuide.json file) to make the JSON-provided examples behave like the FSH provided examples?

Lloyd McKenzie (Oct 21 2020 at 21:08):

You need to edit the implementation guide - or you need FSH to populate the implementation guide with a description for each example.

Chris Moesel (Oct 21 2020 at 21:26):

@Saul Kravitz -- the IG Publisher / Templating / SUSHI can't extract a name and description from bare JSON examples because there is no reliable way to do that across all resource types (and some types don't have any field that would provide that info). It only works in FSH because we provide a way to include the name and description metadata via Name: and Description: keywords -- but those don't get surfaced in the example JSON at all (again, because there's not an obvious place to put them).

It might be neat, though, if we defined custom extensions for meta that would allow authors to embed this information in example JSON -- and ideally, the publisher (or SUSHI?) would use them and then strip them out when publishing the guide.

There is a way to add the name and description in SUSHI though -- but it requires that you're using sushi-config.yaml. If you are, you can put this info into the resources property and it will merge it into the generated Implementation Guide JSON. For example:

resources:
  Coverage/CoverageEx1:
    name: Coverage Example
    description: An example of coverage
    exampleCanonical: http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-Coverage
  Coverage/CoverageEx2:
    name: Coverage Example 2
    description: Another example of coverage
    exampleCanonical: http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-Coverage

Saul Kravitz (Oct 21 2020 at 21:30):

That was the right answer! thx

Eric Haas (Oct 22 2020 at 01:12):

One of the great things about using sushi is to let it get all the resources and pages and not have to manually edit the ig resource ( aka a config file) this mindless timewasting on the IG resource sucks so much - @Lloyd McKenzie why do we need this again?

Eric Haas (Oct 22 2020 at 01:14):

Its this manually editing the ig resource either in JSON XML or YAML is what I am against ... all to feed the artifacts table. Why can those cells be empty?

Eric Haas (Oct 22 2020 at 01:17):

@Chris Moesel can sushi just put in something like "[Type]/{Profile] Example [id}" as a default?

Eric Haas (Oct 22 2020 at 01:24):

Otherwise the description should live with the example instance like I stated above. And I don't care if it persists or not in the published version.

Lloyd McKenzie (Oct 22 2020 at 02:28):

Human-readable names and descriptions are important for examples - readers need to know what they are if they're going to click on the link to go to one, especially when there are multiples of the same type, which there generally should be. I don't understand why editing the information in the example (where the data doesn't really belong) is fine, but editing it in the IG is a problem...

Lloyd McKenzie (Oct 22 2020 at 02:30):

And you should definitely care if it persists in the published version. The published version needs to reflect what implementers should be producing - they can't contain stuff that shouldn't appear in production. Remember, our overall objective is to make things easy for implementers. We can't let making these easy for authors trump that. (Though making things easy for both is fine where we can.)

Jean Duteau (Oct 22 2020 at 05:53):

But if we had a meta.extension that provided the name and description of the example, that seems to me like it would add value to the example itself. When I'm looking at the example by itself, I can now see what this example is supposed to represent via the meta.extension(description).

Chris Moesel (Oct 22 2020 at 12:52):

Eric Haas said:

Chris Moesel can sushi just put in something like "[Type]/{Profile] Example [id}" as a default?

We could, but based on this discussion it sounds like it might be controversial... So I'd like to see where this thread goes first, before committing to anything.

@Lloyd McKenzie - I prefer embedding name/description in the example rather than in the IG for a few reasons:

• The example is self-documenting. You don't need to go to two separate places to see the metadata vs the actual example.
• It keeps the information about the example close to the example. If I need to update or remove the example, it's easy-peasy if name/description are embedded in it. But if name/description are in the IG, I need to remember to go there and update/delete that too.
• I can't flub it up by mis-typing the example reference (e.g., ${type}/${id}) in the IG file.
• It's consistent w/ how it works for other resources in the IG (e.g., the conformance resources all have name/description embedded).
• It allows the IG to remain as slim as possible. We recommend that IGs include lots of examples. This makes the IG much larger and more unwieldy. IMO, a more concise IG file (or sushi-config.yaml file, in SUSHI's case) is easier to manage.

Lloyd McKenzie (Oct 22 2020 at 14:56):

Adding extensions to Resource.meta (presumably because we can't put extensions directly on Resource if it's a Bundle or Parameters or Binary) is viable, but we must ensure that they get stripped out by the publication process because we don't want implementers creating instances that contain those extensions. Steps to make that happen:

• we need to define what the extensions are
• we need to ensure that the publisher propagates those extensions into the name and description when the publisher sucks resource information into the IG
• the publisher will need to strip those extensions out before propagating them into the output, generating narrative, etc.
• SUSHI may want to define shortcuts to populate those extensions from the FSH instances

Lloyd McKenzie (Oct 22 2020 at 14:57):

Does someone want to create a pull request against the publisher - or take on the work?

Jean Duteau (Oct 22 2020 at 15:36):

It appears that you are worried that implementers will just take the example instances and use them as their template for building real-world instances. To me, the whole point of including the name and description in the example instance was to leave them there when published so that implementers could tell what the example was regardless of what link they clicked on or how they opened the example. A side-benefit is that this could also be used to derive the IG. Stripping the name/description would ruin the whole point IMHO. If this concern of implementers reusing examples is real, then I think we should actually go the other way and add yet another extension to Resource.meta to indicate that they shouldn't be doing this. Resource.meta.extension(don't be a bonehead).valueString = "This is an example from an implementation guide. It should not be used as-is nor as a template in your implementation but rather as an informative document to allow implementers to understand how the implementation guide profiles are intended to be used. Receivers and senders who see this extension in real-life production systems SHOULD complain to the offending system implementer."

Eric Haas (Oct 22 2020 at 18:06):

I don't see the harm in having implementers reusing instances as templates. Its going to happen and they may find the description extension handy or not, but if they use it blindly it is on them. Just add a note to the extension definition for the intended purpose of the extension.

Jean Duteau (Oct 22 2020 at 18:08):

sure, change my 'don't be a bonehead' text to be "This is an example from an implementation guide. It is included as an informative instance to allow implementers to understand how the implementation guide profiles are intended to be used. Receivers and senders who see this extension in real-life production systems SHOULD complain to the offending system implementer."

Eric Haas (Oct 22 2020 at 18:10):

(deleted)

David Pyke (Oct 22 2020 at 18:27):

So, "Don't be a bonehead" can't be the language? It's much more presecriptive.

Jean Duteau (Oct 22 2020 at 18:31):

David Pyke said:

So, "Don't be a bonehead" can't be the language? It's much more presecriptive.

It will still be the name of the extension. http://hl7.org/fhir/StructureDefinition/extension-dont-be-a-bonehead

Eric Haas (Oct 22 2020 at 18:47):

is the context for these extensions Resource.meta?

Jean Duteau (Oct 22 2020 at 18:47):

yes

Eric Haas (Oct 22 2020 at 18:52):

OK cranking up the sushi extension generator now...

resourceType: StructureDefinition
id: resourcedescription
url: >-
  http://www.fhir.org/guides/sushi-sandbox/StructureDefinition/resourcedescription
version: 0.1.0
name: ResourceDescription
title: Resource Description
status: active
description: >
  A markdown text natural language description of the resource instance and its
  use


  *Note: The Primary intent of this extension is to illustrate to readers how
  the implementation guide examples are intended to be used. Production systems
  SHOULD NOT use this extension.*
fhirVersion: 4.0.1
mapping:
  - identity: rim
    uri: 'http://hl7.org/v3'
    name: RIM Mapping
kind: complex-type
abstract: false
context:
  - type: element
    expression: Resource.meta
type: Extension
baseDefinition: 'http://hl7.org/fhir/StructureDefinition/Extension'
derivation: constraint
differential:
  element:
    - id: Extension.extension
      path: Extension.extension
      max: '0'
    - id: Extension.url
      path: Extension.url
      fixedUri: >-
        http://www.fhir.org/guides/sushi-sandbox/StructureDefinition/resourcedescription
    - id: 'Extension.value[x]'
      path: 'Extension.value[x]'
      type:
        - code: markdown

Eric Haas (Oct 22 2020 at 18:54):

and...

resourceType: StructureDefinition
id: resourcename
url: 'http://www.fhir.org/guides/sushi-sandbox/StructureDefinition/resourcename'
version: 0.1.0
name: ResourceName
title: Resource Name
status: active
description: >
  A natural language description of the resource instance


  *Note: The Primary intent of this extension is to provide natural language
  names for implementation guide examples. Production systems SHOULD NOT use
  this extension.*
fhirVersion: 4.0.1
mapping:
  - identity: rim
    uri: 'http://hl7.org/v3'
    name: RIM Mapping
kind: complex-type
abstract: false
context:
  - type: element
    expression: Resource.meta
type: Extension
baseDefinition: 'http://hl7.org/fhir/StructureDefinition/Extension'
derivation: constraint
differential:
  element:
    - id: Extension.extension
      path: Extension.extension
      max: '0'
    - id: Extension.url
      path: Extension.url
      fixedUri: >-
        http://www.fhir.org/guides/sushi-sandbox/StructureDefinition/resourcename
    - id: 'Extension.value[x]'
      path: 'Extension.value[x]'
      type:
        - code: markdown

Eric Haas (Oct 22 2020 at 18:54):

would that work?

Jean Duteau (Oct 22 2020 at 18:56):

a) I'd have the resourcename extension be a string instead of markdown. I don't see a need for markdown in the example name.
b) I'd probably combine both extensions into one with nested extensions.

But otherwise that is exactly what I was thinking we should do.

Eric Haas (Oct 22 2020 at 19:01):

OK with a)
but with b ) I prefer 2 simple extension - for simple minds like mine simpler to manage

Eric Haas (Oct 22 2020 at 19:09):

https://healthedata1.github.io/Sushi-Sandbox/StructureDefinition-resourcedescription.html

https://healthedata1.github.io/Sushi-Sandbox/StructureDefinition-resourcename.html

Eric Haas (Oct 22 2020 at 19:11):

I will make it complex

Chris Moesel (Oct 22 2020 at 19:13):

My one concern with having the description extension be markdown is that its target (ImplementationGuide.definition.resource.description) is actually string, not markdown. Now... I always thought it should be markdown, but it's not. That said... by default, SUSHI populates it w/ conformance resources' description values (which are markdown), so SUSHI is kind of already shoving markdown in there anyway.

Eric Haas (Oct 22 2020 at 19:16):

I noted that the conformance resources' description values (which are markdown), which I kept for consistency. I will make a Jira to make the IG element. markdown and a Jira to ? for this extension.

Lloyd McKenzie (Oct 22 2020 at 20:17):

I'd go with 2 separate extensions, not a complex extension - you won't necessarily always maintain both together

Lloyd McKenzie (Oct 22 2020 at 20:18):

Also, the extensions need to be defined in the HL7 namespace, not healthedata - the IG publisher is going to have to be aware of them, as is the validator if we're not stripping them out

Eric Haas (Oct 22 2020 at 20:33):

here is the updated version: https://healthedata1.github.io/Sushi-Sandbox/StructureDefinition-resourcenameanddescription.html

@Lloyd McKenzie can I add to the http://build.fhir.org/ig/FHIR/ig-guidance/best-practice.html then and use that url as base for now?

Eric Haas (Oct 22 2020 at 20:36):

and will go back to 2 separate extensions...

Lloyd McKenzie (Oct 22 2020 at 20:56):

No. There's a specific root that we use for HL7 tooling driven stuff. Anything that doesn't have a dependency on the ig-guidance ig would throw an error for extensions defined there.

Lloyd McKenzie (Oct 22 2020 at 20:56):

@Grahame Grieve

Eric Haas (Oct 22 2020 at 20:58):

https://healthedata1.github.io/Sushi-Sandbox/StructureDefinition-resourcename.html
https://healthedata1.github.io/Sushi-Sandbox/StructureDefinition-resourcedescription.html

see J#29405 and J#29406

Eric Haas (Oct 27 2020 at 22:28):

@Grahame Grieve what should the root be for these extensions to keep the validator happy? I'd like to have this in place for publishing US Core Jan 21 Ballot

Grahame Grieve (Oct 27 2020 at 22:29):

what do they do?

Eric Haas (Oct 27 2020 at 22:31):

embeds the name and definition for the IG resource for non-conformance instances (examples) in the examples so that the tooling like sushi can generate an IG resource without errors or warnings.

Grahame Grieve (Oct 27 2020 at 22:31):

so what do you want to the IG publisher to do with them?

Eric Haas (Oct 27 2020 at 22:32):

ignore them and not complain that it doesn't recognize them

Eric Haas (Oct 27 2020 at 22:34):

Lloyd would like it to pop them off so they don't show up in published output, I don't care if they do.

Grahame Grieve (Oct 27 2020 at 22:44):

well, ask FHIR-I to decide about them, and then I will see what I need to do support them

Lloyd McKenzie (Oct 27 2020 at 23:08):

Use them to populate the name and description in the IG in the artifact list - same as you do with the title and description of the conformance resources

Lloyd McKenzie (Oct 27 2020 at 23:09):

(And then don't yell about the fact that they're present in the instances and, maybe, strip them out as part of publication if an IG property tells you to do so - some people argue for wanting them kept there, but I see others who would want them removed.)

Eric Haas (Nov 03 2020 at 06:02):

@Chris Moesel we voted to approve the extensions for name and description on resources. Can you implement in Sushi now?

use context: Resource.meta

the extension urls are likely going to be :

1. http://hl7.org/fhir/StructureDefinition/resourcename type string
2. http://hl7.org/fhir/StructureDefinition/resourcedescription type markdown

Eric Haas (Nov 03 2020 at 06:02):

I would like to use ASAP for this ballot for US Core and CDEX

Chris Moesel (Nov 04 2020 at 14:41):

Eric Haas said:

Chris Moesel we voted to approve the extensions for name and description on resources. Can you implement in Sushi now?

By "implement in SUSHI" -- do you mean that if we process an example that has those extensions, use them to populate the generated IG JSON? I just want to be clear on what is being asked here before I say we can do it. ;-)

Chris Moesel (Nov 04 2020 at 14:43):

OR do you mean we should populate those extensions in our generated example JSON based on the Title: and Description: in FSH example Instances? If the former (use extensions to populate IG JSON), I'm pretty comfortable w/ that. If the latter (start generating these extensions on all FSH examples), I'd want to think more on that -- especially if the publisher doesn't yet support using those extensions anyway.

Lloyd McKenzie (Nov 04 2020 at 20:45):

I think the desire is to populate the structure definitions. The IG Publisher will propagate them into the IG file

Eric Haas (Nov 04 2020 at 20:51):

@Chris Moesel

By "implement in SUSHI" -- Process an example that has those extensions, use them to populate the generated IG JSON?

Grahame Grieve (Nov 04 2020 at 20:54):

to populate the structure definitions

Then I don't understand this at all. I thought structure definitions were nowhere in sight...

Eric Haas (Nov 04 2020 at 20:54):

I think Lloyd mispoke, we are talking about examples

Eric Haas (Nov 04 2020 at 20:56):

@Grahame Grieve are these going to be the urls?:

1. http://hl7.org/fhir/StructureDefinition/resourcename
2. http://hl7.org/fhir/StructureDefinition/resourcedescription

Grahame Grieve (Nov 04 2020 at 20:58):

I wouldn't have thought so

Lloyd McKenzie (Nov 04 2020 at 22:04):

I did misspeak. Meant 'resource' not 'structuredefinition'.

Brian Postlethwaite (Nov 04 2020 at 22:23):

Could we also have another extension to inform the publisher to remove a property, then you could also enable it to remove this new extension for the output generated too, and I'd love to use it to remove things like meta and id in explicit examples for performing a POST (where you don't want the ID, but it's required in the example to include in the IG).
e.g.

<Patient>
  <id value="pat1">
    <extension url="http://removeme"><valueBoolean value="true"/></extension>
  </id>
  <meta>
    <extension url="http://hl7.org/fhir/StructureDefinition/resourcedescription">
      <extension url="http://removeme"><valueBoolean value="true"/></extension>
    <valueMarkdown value="An example patient to submit to a server with the national Identifier"/></extension>
  </meta>
  <identifier>
  ...

Grahame Grieve (Nov 04 2020 at 22:46):

that's a pretty hard problem to solve. I think it needs a comment in the resource

Brian Postlethwaite (Nov 04 2020 at 23:30):

That's what I'd propose the removeme extension is.

Grahame Grieve (Nov 04 2020 at 23:37):

I can't remove it - I need it in all sorts of places

Lloyd McKenzie (Nov 05 2020 at 02:48):

Can you remove it on serialization and rendering?

Lloyd McKenzie (Nov 05 2020 at 02:49):

I guess it'd still be needed in the packages for downstream reference validation

Grahame Grieve (Nov 05 2020 at 04:17):

I can't remove it on serialization. I could only for rendering, but that seems deceptive given that it has to exist elsewhere

Nick Freiter (Nov 06 2020 at 13:25):

Eric Haas said:

Grahame Grieve are these going to be the urls?:

1. http://hl7.org/fhir/StructureDefinition/resourcename
2. http://hl7.org/fhir/StructureDefinition/resourcedescription

Is this confirmed? Looking to implement this in SUSHI. I'll use these URLs for now, but we would like confirmation before adding this to a release.

Grahame Grieve (Nov 06 2020 at 17:29):

if I was defining them , it would http://hl7.org/fhir/StructureDefinition/example-name and http://hl7.org/fhir/StructureDefinition/example-description

Grahame Grieve (Nov 06 2020 at 17:30):

The task is unclear on this, but I'll be returning it to FHIR-I for further consideration because I don't like the constraints either

Nick Freiter (Nov 06 2020 at 21:49):

So is there a possibility these two extensions may not be added at all? If the urls change, that is easy enough to change in SUSHI, but I want to make sure some sort of extension for name and description will be created before I start adding things to SUSHI.

Grahame Grieve (Nov 06 2020 at 21:50):

I think they'll be added. I just think that the details that FHIR-I approved don't make sense

Eric Haas (Nov 07 2020 at 01:15):

I assume you mean the details as in the constraints that these extensions can only be used on non-conformance resources. The core functionality of using them to populate the implementation guide resource with the example files is still valid right?

Eric Haas (Nov 12 2020 at 17:12):

@Nick Freiter have you implemented in sushi yet, I have a couple of IGs lined up and waiting for it ...

Nick Freiter (Nov 12 2020 at 18:31):

I've been holding off because it wasn't clear to me from this conversation if these extensions would be created and what the URLs of these extensions will be.

Nick Freiter (Nov 12 2020 at 18:32):

Grahame Grieve said:

if I was defining them , it would http://hl7.org/fhir/StructureDefinition/example-name and http://hl7.org/fhir/StructureDefinition/example-description

Are these the extension names I should use?

Nick Freiter (Nov 12 2020 at 19:01):

I'm also unclear on if there are certain situations where SUSHI should ignore these extensions. From what I understand, SUSHI would want to ignore these extensions if they were used on a conformance resource. Once we have certainty on:

1. The urls of these extensions
2. When these extensions can be used and which elements in the ImplementationGuide they map to

We can add this to SUSHI.

Grahame Grieve (Nov 12 2020 at 19:56):

see J#29406:

• http://hl7.org/fhir/StructureDefinition/instance-name
• http://hl7.org/fhir/StructureDefinition/instance-description

Grahame Grieve (Nov 12 2020 at 19:57):

And yes, they won't be allowed on resources that have title and description elements

Chris Moesel (Nov 13 2020 at 14:25):

I noticed in the Jira issue that the resolution says:

Will also define appearance constraints to ensure that these extensions aren't used in resources where there is a "proper" (non-extension-based) slot for name/description (i.e., conformance resources cannot use these extensions).

and a comment says:

Will also define appearance constraint on the extensions like this:

%resource.title.exists().not() for the name one and %resource.description.exists().not() for the description one

I think that constraint is too aggressive. For example, it would disallow the description extension on Goal because Goal has a field called description -- but Goal is not a conformance or terminology resource and its description is obviously quite different since it is a CodeableConcept. I believe we would want to allow the instance-description extension on an instance of Goal despite the presence of a field named description.

Lloyd McKenzie (Nov 13 2020 at 14:39):

Fair point. Can you put a comment on the tracker? (It is going to make enforcing the invariant a lot harder. Perhaps we can check if there's a URL - on the presumption that if it's a conformance resource, it'll have one)

Chris Moesel (Nov 13 2020 at 15:34):

No, it seems I can't put a comment on the tracker, which is why I said this here. I'm logged into Jira, but the issue is totally READ ONLY to me.

Chris Moesel (Nov 13 2020 at 15:36):

No buttons to add a comment, edit, etc. Only export.
image.png

Chris Moesel (Nov 13 2020 at 15:41):

Lloyd McKenzie said:

It is going to make enforcing the invariant a lot harder. Perhaps we can check if there's a URL - on the presumption that if it's a conformance resource, it'll have one.

Is there an issue w/ just checking the resource type against the list of known conformance/terminology resources? That seems the clearest approach to me, although the constraint would need to be updated if new conformance/terminology resources are added in the future.

Chris Moesel (Nov 13 2020 at 23:19):

@Eric Haas -- SUSHI 1.0.0 was just released and will use http://hl7.org/fhir/StructureDefinition/instance-name and http://hl7.org/fhir/StructureDefinition/instance-description extensions if they're found on non-conformance/non-terminology JSON/XML resources.

Eric Haas (Nov 14 2020 at 00:13):

great so testing it out:

example:

status: final
category:
  - text: Social History
    coding:
      - code: social-history
        system: 'http://terminology.hl7.org/CodeSystem/observation-category'
        display: Social History
code:
  text: Tobacco smoking status
  coding:
    - code: 72166-2
      system: 'http://loinc.org'
      display: Tobacco smoking status
resourceType: Observation
effectiveDateTime: '2016-03-18T05:27:04Z'
meta:
  extension:
    - url: 'http://hl7.org/fhir/StructureDefinition/instance-name'
      valueString: FOO
    - url: 'http://hl7.org/fhir/StructureDefinition/instance-description'
      valueMarkdown: >-
        ###FOO

        - bar
  profile:
    - 'http://www.fhir.org/guides/sushi-sandbox/StructureDefinition/test-obs'
valueCodeableConcept:
  text: Current some day smoker
  coding:
    - code: '428041000124106'
      system: 'http://snomed.info/sct'
id: test
subject:
  display: Amy Shaw
  reference: Patient/example

Eric Haas (Nov 14 2020 at 00:13):

turn the crank in sushi and get...

Eric Haas (Nov 14 2020 at 00:18):

resourceType: ImplementationGuide
id: healthedatainc.sushi-sandbox
url: >-
  http://www.fhir.org/guides/sushi-sandbox/ImplementationGuide/healthedatainc.sushi-sandbox
version: 0.1.0
name: SushiSandbox
title: Sushi Sandbox
status: active
publisher: Health eData Inc
contact:
  - telecom:
      - system: email
        value: 'mailto:ehaas@healthedatainc.com'
description: This is a sushi sandbox for creation of resources and examples
packageId: healthedatainc.sushi-sandbox
license: CC0-1.0
fhirVersion:
  - 4.0.1
dependsOn:
  - packageId: hl7.fhir.us.core
    version: 3.1.0
    uri: 'http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core'
    id: hl7_fhir_us_core
definition:
  resource:
...
    - reference:
        reference: Observation/test
      description: |-
        ###FOO
        - bar
      name: FOO
      exampleCanonical: 'http://www.fhir.org/guides/sushi-sandbox/StructureDefinition/test-obs'
....

Eric Haas (Nov 14 2020 at 00:18):

Sweet!!

Eric Haas (Nov 20 2020 at 19:01):

@Grahame Grieve

Implemented this here: https://build.fhir.org/ig/HL7/US-Core/

and getting these errors...

 error The extension http://hl7.org/fhir/StructureDefinition/instance-name is unknown, and not allowed here
 error  URL value 'http://hl7.org/fhir/StructureDefinition/instance-name' does not resolve
 error  The extension http://hl7.org/fhir/StructureDefinition/instance-description is unknown, and not allowed here
 error  URL value 'http://hl7.org/fhir/StructureDefinition/instance-description' does not resolve

can you add to your list to fix?

Grahame Grieve (Nov 23 2020 at 22:39):

fixed next release

Last updated: Apr 12 2022 at 19:14 UTC