Stream: IG creation
Topic: Sushi option to gen IG Context Json Schema
Al Pivonka (Apr 11 2022 at 20:45):
I'm going out on a limb here and this will show my ignorance so please try to be nice.
While looking into sushi command line I did not see an option that would generate a context specific FHIR schema for the context of the IG.
Could see the generation of the FHIR schema as part of the handoff to the delivery team which would enable them to use it for constraints at the service level.
I could be missing something. Please correct me if I am.
Lloyd McKenzie (Apr 11 2022 at 21:00):
We don't have tooling that creates profile-specific schemas. XML schema is very poor at expressing the types of things we do in profiles. You can't enforce most vocabulary bindings, you can't handle slicing (which means you can't deal with any extensions). Given the limited value they'd have, we just don't bother. (This isn't Sushi-specific it's true for all profiles.)
Al Pivonka (Apr 11 2022 at 21:24):
@Lloyd McKenzie (Thank you for your reply) .
Then, I'm going to make a base assumption that it is up the the delivery team to make changes to their service level validation(schemas) to conform to the context specific IG.
then the next question begs to be asked, how to validate the IG agains the implementation ? Manual?
Grahame Grieve (Apr 11 2022 at 21:41):
what kind of validation do you want?
Lloyd McKenzie (Apr 11 2022 at 22:11):
Have you looked through this page? https://build.fhir.org/validation
Al Pivonka (Apr 12 2022 at 13:25):
@Lloyd McKenzie (Thanks) Reading.....
Al Pivonka (Apr 12 2022 at 14:12):
@Grahame Grieve (thank you for your question)
I've added (FHIR JSON schema) to my original question (Hoping this may help clarify my statements)
My base assumption: the IG is used to guide the delivery team on how to implement the specific context changes of the IG (Extensions, Profile changes, etc. ) .
Use of the FHIR JSON Schema to validate service call message payloads for schema correctness. (Like: OPEN API/Swagger schemas)
If the IG outlines context specific changes to profiles and extensions (etc), the delivery team would have to make corresponding changes the FHIR JSON schema to enable validation of the new structure(s) caused by the specific context of the IG changes.
I realize I have a great deal to learn . I appreciate your time.
Lloyd McKenzie (Apr 12 2022 at 16:08):
Right. Short answer is that FHIR interfaces tend to be more complex than what can reasonably be represented by JSON schema. If you were defining a stand-alone interface, you wouldn't have a repeating 'extension' element with different constraints on different repetitions, and similar behavior for identifiers, codings, etc. Instead, you'd have separate named properties for each extension, relevant identifier type and you could have a nice tight JSON schema that fully documented your custom REST API. FHIR doesn't work like that. FHIR has a common schema that's the same across all systems' APIs. As a result, the JSON doesn't always lend itself to defining a schema for the interface for a single system (or set of expectations defined by a single IG).
Gino Canessa (Apr 12 2022 at 16:26):
On a related note, some of us have been working on code generation from IGs to handle parts of this. We found that generally, people like to use an SDK to do most of the heavy-lifting, and having tooling that integrates with that is desired.
Outputs are like C# example. Notes:
- The tooling to generate this is WIP, but getting closer.
- The goal is to be able to output code that integrates with the different SDKs in different languages (e.g., Firely/C#, HAPI/Java, Apple/Swift, etc.)
- Validation is limited to 'things that do not require a terminology service'
- looking at what integration with a tx server is on the list, but explicitly not part of MVP
Al Pivonka (Apr 12 2022 at 18:13):
I think I'm getting it.
Unless the IG specifies a custom profile; which isn't recommended and many have told me; one is working with extensions. Looking at the JSON schema for an extension: an extension is an extension.
Code Systems are enumerations and value sets are references to the enums within the Code System. I'm not a JSON schema guy yet I'm not sure how that would be enforced on an extension...
Are my assumptions correct?
BTW thanks for the explanations.
@Gino Canessa Where can I find code gen you speak of?
Gino Canessa (Apr 12 2022 at 18:45):
The repo is on GitHub: fhir-codegen; you will want to look at the dev branch for any of the work with IGs.
The FHIR-core related features are all there and stable, but for v1 of 'IG' support:
- Reading/parsing of IGs (mostly done - current pass works but I am not sure if everything required is there yet)
- UI (decent, but needs work for a full v1)
- A simplified export module for extensions (mostly just sketched out right now - previously I had just been using the same 'Language' export modules, but there is a lot of 'extra' that can be trimmed out to simplify)
Unfortunately I have a pretty full plate right now, so while work is regular it is not as fast as I would like. Once everything is good for a v1, we'll push through a release and maybe sort out a hosted story too.
Last updated: Apr 12 2022 at 19:14 UTC
