Stream: implementers
Topic: multiple services and IG's
Jens Villadsen (Nov 15 2019 at 22:41):
Whats the preferred way of sharding / dividing an IG and its profiles / extensions using some form of markup? The case is the following: I have an IG with some 20 profiles and some 50 extensions in a setup with 10 services. Each service is responsible for its own set of profiles and has distinct ownership on the resources in the setup - eg. a patient service "owning" the Patient profile and eg. Communication profile and a organization service "owning" the Practitioner and Organization profile (the real deal can be found at https://docs.ehealth.sundhed.dk/latest/ig/index.html in "Capability Statements). As a matter of optimization (especially during startup of the services during our CD/CI pipeline and also as a step in the development where changes to profiles belonging to other services than one self should not pose any impact) I'm about to look for something in the StructureDef that can be used to "flag" that a certain profile / extension "belongs"/"has a primary usage" at a specified service. Has anyone else done something like this and would they be willing to share some info to how they did it?
Grahame Grieve (Nov 15 2019 at 22:52):
we use list for this. see the terminology.hl7.org for examples f how to use list to build subset pages
btw, Suggest you ask questions like this on #IG creation.
Jens Villadsen (Nov 16 2019 at 21:08):
I think you are misunderstanding the question here. This is not really an IG thing. It's about filtering a certain set of profiles for a certain service. I guess however this could be contained in a list. So ... If I created a list pr. service, and added the intended profiles, code systems, valuesets and extensions to that list, I guess that could fit the bill.
Jens Villadsen (Nov 16 2019 at 21:11):
@Grahame Grieve could you narrow down a link to an example on https://terminology.hl7.org/
Grahame Grieve (Nov 17 2019 at 06:06):
well, in the source for the IG, there are multiple lists that drive rendering like this: https://build.fhir.org/ig/HL7/UTG/codesystems.html
Oliver Egger (Nov 17 2019 at 06:33):
why is the fhir icon doubled (?) in the UTG implementation guide?
Grahame Grieve (Nov 17 2019 at 06:58):
where?
Oliver Egger (Nov 17 2019 at 07:33):
https://build.fhir.org/ig/HL7/UTG/assets/images/fhir-logo-www.png from https://build.fhir.org/ig/HL7/UTG/codesystems.html
Grahame Grieve (Nov 17 2019 at 08:15):
oh that is the Australian FHIR icon - looks like a map of Australia
Grahame Grieve (Nov 17 2019 at 08:16):
don't know why that one's there - I must have used the wrong template
Jens Villadsen (Nov 21 2019 at 20:58):
well, in the source for the IG, there are multiple lists that drive rendering like this: https://build.fhir.org/ig/HL7/UTG/codesystems.html
I'll catch you tomorrow regarding this
Jens Villadsen (Nov 22 2019 at 09:25):
using 'profile' does the job in the capabilitystatement (stu3) now I'm just left with the hen and the egg problem ;) - which is not something FHIR can solve
Jens Villadsen (Nov 22 2019 at 09:27):
but wait ... is a 'profile' technically only the 'top level' profiles or does that also include extensions? :thinking:
Jens Villadsen (Nov 22 2019 at 09:28):
https://www.hl7.org/fhir/stu3/capabilitystatement-definitions.html#CapabilityStatement.profile
Jens Villadsen (Nov 22 2019 at 09:29):
could you clarify this @Grahame Grieve ?
Grahame Grieve (Nov 22 2019 at 09:32):
top level profiles, if I understand what you are asking
Jens Villadsen (Nov 22 2019 at 09:37):
what is top level profiles?
Grahame Grieve (Nov 22 2019 at 09:40):
resource level profiles
Jens Villadsen (Nov 22 2019 at 09:54):
thx
Jens Villadsen (Nov 22 2019 at 18:33):
@Grahame Grieve - FYI - I now also created a parser that runs through all the white listed profiles and extension (based on the .profile in the capabilitystatement) and found all the valuesets that are used ... I now know more than I would like around the internals of binding on Coding/code and ValueSetReference / Reference on snapshots and differentials ... sigh ...
Jens Villadsen (Nov 22 2019 at 18:38):
theoretically it works on all IG's
Grahame Grieve (Nov 23 2019 at 09:17):
is it a useful thing to build into the IG publisher>?
Jens Villadsen (Nov 23 2019 at 21:44):
good question. My case for doing it was optimization because our IG contains multiple services and therefore multiple capability statements. In order not to have other (unused, maybe broken) extensions have an impact on your particular service, we needed the filter, If you wan't the snippets I'll happily share them
Jens Villadsen (Nov 23 2019 at 21:45):
I guess its a great clue to have a sum of all the used valuesets and codesystems
Jens Villadsen (Nov 23 2019 at 21:48):
for instance, I just realized we had a bug because we had made an extension for using a codeable concept, but in my (now produced by my dark magic) autogenerated list of all referenced valuesets, my particular valueset was not present. So I wen't back to my extension - and yes, it was unbounded
Last updated: Apr 12 2022 at 19:14 UTC
