Stream: implementers
Topic: Common profiles across multiple IGs
Sarah Gaunt (Jun 12 2020 at 21:16):
@Craig Newman and I are working on two different IGs. One is for Birth Defects Reporting and the other is for Birth and Fetal Death Reporting.
The IGs are on pretty much the same timeline - Connectathon in Sept, ballot in January.
Obviously there are some overlaps in content (newborn, fetus, mother, father, various observations, etc.).
We have been discussing ways to align and are not sure how to proceed. e.g. if the newborn patient profile is going to be exactly the same in both IGs, how should we deal with this? It would seem odd to have this common newborn patient in one of the IGs and referenced/used in the other IG. Would it make sense to create some kind of more generic "Vital Records" IG that contains the common profiles? Is that even possible seeing as it would span the two projects and not really be owned by either one. Balloting also seems like it would be problematic. Plus, is it even possible to reference profiles/add a dependency to stuff in an IG that isn't yet published (assuming the same problem would occur if we referenced between the two IGs)?
We really want to align these IGs and not create duplicate profiles, but are finding it hard to figure out a way forward.
Lloyd McKenzie (Jun 12 2020 at 21:44):
Your options are: one IG depends on the other or both depend on a shared IG. Are both projects sponsored by the same WG?
Lloyd McKenzie (Jun 12 2020 at 21:45):
Because in the end, ownership is by the work group, not the project. (The projects just provide worker-bees to get the work done.) If you go with a single parent IG, you'll have to coordinate between the projects in terms of who's responsible for handling the reconciliation.
Sarah Gaunt (Jun 12 2020 at 22:30):
Yes they are both Public Health IGs. I think it would have to be @Craig Newman who is responsible for all reconciliation... Hahahahaha... :grinning_face_with_smiling_eyes:
Is it possible for one to have dependency on an IG that hasn't yet been published?
Lloyd McKenzie (Jun 13 2020 at 01:52):
There's some challenges with a profile being STU that is derived from a profile that is draft. However, there's no issue with a profile that is STU referencing a profile that is draft. We can create a frozen snapshot of an IG that can be referenced as a dependency of other IGs. Once the referenced IG is officially published as STU, you could do an STU update on the derived IGs to point to the 'official' release. The biggest question is whether that solution will be "good enough" for your implementation community.
Sarah Gaunt (Jun 15 2020 at 07:42):
I think that some of them would be derivations and not just simple references. The STU update thing could be an issue, will have to look into that. It's definitely something to consider though, because creating multiples of the exact same profile (like "Father's Education Level") in different IGs sure isn't ideal!
Jose Costa Teixeira (Jun 15 2020 at 07:58):
Not sure if related, but I am also looking at how to share profiles across IGs. Example:
we define Patient and CarePlan profiles on Federal level.
Then in regional or project IGs we want to
- have examples of those careplans and patients.
- make sure the profiles are there in a single package
Grahame Grieve (Jun 15 2020 at 07:59):
the most important question that is often overlooked is: what's the lifecycle? how do changes get managed? Who manages the content?
Frank Oemig (Jun 15 2020 at 07:59):
The idea of profiles is their reuse. But I see an issue with their lifecycle and maturity. Perhaps we have to separate that.m, ie.vote on those individually...
Grahame Grieve (Jun 15 2020 at 08:03):
you can do all sorts of things. The publishing structure you choose should be one that supports your life cycle. I think that the easiest to describe is that there's a common IG that the other 2 IGs depend on. This naturally defines a publishing cycle.
But it's not the only approach - there's many others
Jose Costa Teixeira (Jun 15 2020 at 08:30):
I am looking at displaying them even if they are only references. - e.g. once the federal government approves a profile (e.g. Patient), regional lGs use Patient as it is - they can add examples, and even sub-profile. But if they just use the "federal" patient it's the same as inherited, and I'd like it displayed.
Jose Costa Teixeira (Jun 15 2020 at 08:31):
for profiling, I don't see an issue with dependsOn. and for displaying them?
Sarah Gaunt (Jun 23 2020 at 04:23):
So I'm thinking maybe I didn't explain myself properly here. @Rick Geimer was saying that there shouldn't be an issue referencing (or deriving) profiles from other IGs that are not published. To be clear, all the IGs in question would be CI builds (none yet published). Apparently this is what was done with daVinci and the hrex (framework/library) IG. From what I understood the IGs would just need to have an entry in the FHIR IG registry to be able to reference each other. (Or some other magic that @Grahame Grieve would have to perform?). Rick didn't think there was a need for snapshots or anything like that.
And then when we are ready to publish, (all STU) we would just have to be sure to publish in sequence...
Grahame Grieve (Jun 23 2020 at 21:47):
I think this all works - just use "current" as the version in the dependencies
Sarah Gaunt (Jun 23 2020 at 22:23):
Great - thanks @Grahame Grieve
Last updated: Apr 12 2022 at 19:14 UTC
