Stream: IG creation
Topic: Publishing document type codes
David deRoode (Sep 18 2020 at 19:36):
We're planning on building support for required FHIR IG publisher files (ie Jira Spec, ig.ini, package-list.json, ignore-warning, etc.) into Trifolia on FHIR and storing them as DocumentReferences. We are not aware of any CodeSystem or ValueSet that uniquely define the document types related to the HL7 publishing process for these document types. So, first want to ask if anyone knows if codes do exist. If codes don't exist, thoughts on if these codes would be used/useful to others? Mainly, who should own the provisioning and maintenance of these codes (HL7 or Lantana)? @Grahame Grieve @Lloyd McKenzie
Lloyd McKenzie (Sep 18 2020 at 19:38):
DocumentReference rather than Binary because you need filename/path information?
Lloyd McKenzie (Sep 18 2020 at 19:39):
I don't know of anyone else who would use them right now, but it's not inconceivable that others might want to store all the source as resources, so I guess we could look at defining an internal code system...
David deRoode (Sep 18 2020 at 19:45):
Makes sense, and agreed. Recommend an agenda for this topic as a next step?
Lloyd McKenzie (Sep 18 2020 at 20:04):
Sounds good - and perhaps a tracker item.
Elliot Silver (Sep 18 2020 at 21:50):
@John Moehrke might have a suggestion.
Grahame Grieve (Sep 18 2020 at 21:50):
btw, to harp on a common issue... Trifolia should not try to manage package-list.json
John Moehrke (Sep 19 2020 at 15:15):
The DocumentReference.content.format would be an indication of the profile used to constrain the content. There is a vocabulary managed by IHE for the content types defined by IHE. There is a vocabulary managed by HL7 for the content defined by HL7, although this has not yet published.
This said, when the document is a FHIR Document; I recommend that the profile of that FHIR Document be used in the DocumentReference.content.format. This is perfectly aligned with the original concept of the IHE FormatCode. So, your IG self defines the code you are looking for, it is the canonical URI of the higest StructureDefinition profile.
John Moehrke (Sep 19 2020 at 15:16):
It is true that this value might also be quickly discovered by looking inside the binary, by exposing it in the metadata (i.e. DocumentReference) it is more readily available for filtering and prioritizing prior to pulling the bits that are the document (Binary) or the bundle.
David deRoode (Sep 28 2020 at 15:40):
Thanks all. @John Moehrke. Agree with your rationale for use of these codes on DocumentReference.content.format. Sounds like a vocabulary might already have been defined (though never published); could you share it so we can check if it covers our ToF scope?
John Moehrke (Sep 28 2020 at 16:31):
The managed vocabulary is the one that is pointed to in the FHIR Core DocumentReference for .content.format. This is a joint work of IHE and HL7
Etienne Cantineau (Sep 29 2020 at 11:19):
Wrong thread
Last updated: Apr 12 2022 at 19:14 UTC
