Stream: IG creation
Topic: IG creation when many concepts not yet in published FHIR
Scott Gordon (Aug 04 2021 at 10:15):
Hello,
I'm a newbie, so apologies for naïve questions. Also, not sure if this question is better in #methodology but since it impacts the ability to make an IG I put it here. Finally, apologies for the long message.
My question is about potentially using the Basic resource (and potentially a previous build snapshot) to allow IT development and testing while FHIR R4B and R5 discussions continue to evolve.
By the way, I welcome any corrections of any incorrect assumptions here. I am not an expert in any way :)
Scenario:
Currently there is a project in which large amount of the data concepts we want to use are not yet officially in FHIR. Most are in the build (R4B at ballot) though the final form of that and R5 may be many months or years in settling and publishing. As a result, we are unable to create a draft IG that can be used for any internal purpose in the interim period.
After many years of standards work on this project, we really need to be able to at least build something to design, develop, and test IT needs. So I'm exploring any and all options that might fill the interim period until the standard is settled. Hence my post here.
For additional consideration: I believe our project as it stands is something like a FHIR façade: we necessarily have to take apart the FHIR messages for parsing right when they come in, so for ingestion purposes I believe there are no FHIR server requirements. In a sense, we are an endpoint for dataflow at this time. Further, this data is not coming from healthcare data concepts. I think interoperability concerns may be low at least for now.
Assets
I think we have two things going for us:
-
A lot of our concepts that support transfer of needed information DO exist in the build - even though their final form may change radically after reconciliation. My limited understanding is that may be sufficient to build an IG for internal development use - for the interim until R4B/R5 etc are settled.
-
The Basic resource. My basic read of this is that Basic could be used as a very FHIR-appropriate way of conveying in an IG the non-canonical FHIR concepts and allowing it to look somewhat close in design to what might come in the future.
Options to move forward in the interim
We need something (an IG) to build and test. There may be many options that may work in the interim period. I'm curious if folks here have thoughts that might help. I have thought about 2 options but don't know how realistic they are so I thought I'd see what folks here think. Both options would require a re-jiggering of the IT aspects once the FHIR standard settles and if we choose to upgrade to the published standard with all our concepts.
Option 1: IG made with existing build snapshot plus Basic/extensions. I'm told that it is possible to base an IG (with traditional or SUSHI powered tools) on a snapshot of a build (R4B ballot, perhaps?). One option is to create an IG based on that plus filling in gaps with Basic resources/extensions.
Option 2: Ignore all old build design, do all gaps with Basic. This seems more extreme, but since we know that the R4B balloted FHIR structure may change a lot - and then the build will take a long time to reflect that, and publish. Another option is to wait until the design is at least settled and then mock up the design using Basic.
One again, I welcome any thoughts/considerations about these or other potential approaches to move us forward.
Thank you for any information!
Regards
Scott
Jose Costa Teixeira (Aug 04 2021 at 11:31):
Just for my understanding, what is the scope / area that you want to build the IG in?
Scott Gordon (Aug 04 2021 at 12:18):
You're probably arware of this one https://confluence.hl7.org/plugins/servlet/mobile?contentId=51225362#content/view/51225362
Jose Costa Teixeira (Aug 04 2021 at 13:30):
Oh that.
Jose Costa Teixeira (Aug 04 2021 at 13:32):
I think your option 2 is sensible. I expect indeed lots of new concepts, so Basic for data structures, Task for actions, Measure/MeasureReport or Observation for the reporting itself..?
Jose Costa Teixeira (Aug 04 2021 at 13:34):
my recommendation would be: start with logical models, keep them up to date. Then you know what your information means, and even if you change from R4 to R4B, or R5, or anything in between, at least one of your feet is on stable ground
Lloyd McKenzie (Aug 04 2021 at 14:12):
It's perfectly possible to write an IG against any frozen build of the base spec - e.g. the ballot release of R4B or the "for comment" ballot version of R5. The only downside is that you probably won't find implementer support for that (i.e. no public test servers, no support from the Simplifier tools, etc.) Moving to use Basic in a stable release will be more widely supported, but it will be pretty darn ugly, as everything will be extensions.
Scott Gordon (Aug 04 2021 at 18:48):
Both these perspectives are helpful, thank you!
Gino Canessa (Aug 05 2021 at 18:52):
As a note: I just documented the process the other day for building an IG (locally) that references a local build of R4B. I've been taking the output from the local build and pushing it to a github pages location so that it's publicly available until CI supports everything I need. Doesn't help on the 'official' front, but it lets us move forward and do things like 'try this model and see if it works'.
For software coding/testing, I ended up writing a toolchain when I needed it. fhir-codegen exports things like TypeScript and C# models that can be used to build projects for testing (e.g., the Subscriptions Proxy Server and the Subscription Test UI). I'm hopeful that eventually we'll be able to do things like nightly builds of the typical SDKs (e.g., Firely's FHIR Net SDK), but having models that serialize and parse correctly been enough so far. I kind of like the 'less good' story of usability on them, so that it's clear these aren't things you'd want to move into production.
Last updated: Apr 12 2022 at 19:14 UTC
