Stream: FAIR
Topic: library-relatedArtefact extension
Giorgio Cangioli (Mar 09 2022 at 17:43):
I was looking to the Library profile (https://build.fhir.org/ig/HL7/fhir-for-fair/StructureDefinition-Library-uv-f4f.html) and I was wondering if the
library-relatedArtefact extension is not a duplication of the already existing relatedArtifact element.
Anything I'm missing ?
@Brian Alper ; @Philip van Damme @Matthias Löbe @Yunwei Wang @Steve Tsang : thoughts ?
Giorgio Cangioli (Mar 09 2022 at 17:44):
maybe should be used for the list resource instead ?
Matthias Löbe (Mar 09 2022 at 17:52):
Sorry, can't say for sure.
Giorgio Cangioli (Mar 09 2022 at 18:13):
... maybe I 've been able to re-build the meaning it is not about the relatedArtefact, but it is about the content element
content is an Attachment and we would like to be able to provide content as relatedArtefact
Giorgio Cangioli (Mar 09 2022 at 18:14):
I need to be more explicit in the description of the extension ;-)
Brian Alper (Mar 10 2022 at 19:38):
@Giorgio Cangioli There may be a duplication of concepts if using a "relatedContent" element instead of "content" to enable use of RelatedArtifactF4F datatype instead of Attachment datatype. The "relatedContent" or "content" elements conveys the relationship of "composed-of" (i.e. this content is part of the library), and then the RelatedArtifactF4F has a type element which requires a code which would be "composed-of". Another solution, when desiring to represent Library.content data by reference instead of attachment, would be to just use Library.relatedArtifact and set type="composed-of" -- when the relatedArtifact.type="composed-of" for a Library resource it conveys you are using it for content without using the content element. This is cleaner for resource expression (no additional extension for relatedContent) but it would require implementers to know to search this alternative method for finding Library.content
Last updated: Apr 12 2022 at 19:14 UTC
