Stream: implementers
Topic: FHIR Profiling Tools?
Jakob Hartl (Dec 06 2018 at 14:55):
Hi,
we are going to start with Profiling for our Solution in the near future and looking for the best tool to do that.
If you search the internet the most found tool is Forge (by firly). But I'm interested, which other tools are out there? Or is Forge the tool to go with?
Can you give us a feedback of the tools, you are using? Pros and Cons? I'm sure this will also help future implementers to get an overview.
Thank you in advance for your feedback!
Regards,
Jakob
John Moehrke (Dec 06 2018 at 17:54):
forge
Chris Moesel (Dec 06 2018 at 18:36):
We use a toolset we built at MITRE that we call CIMPL (Clinical Information Modeling and Profiling Language). Instead of being a GUI tool (like Forge), it's a command-line tool to process files written in a text format (called CIMPL). These files describe clinical models and their mappings to FHIR. CIMPL tooling can generate profiles in DSTU2 and STU3 formats. See: https://github.com/standardhealth/shr-cli/wiki
Richard Townley-O'Neill (Dec 06 2018 at 23:20):
We design what we want using a table that looks like the difference tab that the IG publisher produces.
We create the StructureDefinition with Forge.
Sometimes we adjust StructureDefinition files with a text editor.
Grahame Grieve (Dec 07 2018 at 00:51):
there's also Trifolia - that offers a middle path:
- Forge : an editor for making profiles
- Trifolia: a design environment for writing profiles
- CIMPL - a DSL for designing clinical models and describing them as profiles
Each of these has pros and cons and the righgt choice depends on what you are doing.
Michel Rutten (Dec 10 2018 at 11:15):
In addition, there is the MDHT profiling tool based on UML:
https://projects.eclipse.org/proposals/model-driven-health-tools
Forge specifically targets HL7 FHIR and started out as a reference implementation that aims to support all the available FHIR profiling features (not fully there yet, but quite close). Trifolia and MDHT have been around for a while and also provide support for older HL7 standards, so they're a bit more generic.
BTW I am the lead developer of Forge, please don't hesitate to contact me if you have any questions.
Kapil (Apr 20 2019 at 14:43):
Hello,
We are new to FHIR and learning 'how to define the profiles'. during this exercise i came across a situation (mentioned below) and would like to know your views or recommended practices for such case,
"For field of a data type 'Code' (e.g. Condition.clinicalstatus) if target EHR system do not support all the values mentioned in standard spec then how do we define such constraint also how to take care of case where EHR do also supports the values which are very specific & its not part of standard."
Thanks in advance! Regards.
Lloyd McKenzie (Apr 20 2019 at 14:48):
You can use a valueset to limit allowed values. For the second case, you should map your values to the hl7 valueset if at all possible. If not possible, omit the element. If need be you can also send your custom value in an extension.
Kapil (Apr 20 2019 at 14:56):
Thanks Lloyd for the response!
in case we can't omit values ( not part of standard spec) then is it acceptable if instead of using field value (of code type) defined in base resource we populate additional extension that supports both standard + specific value sets ? Regards
Lloyd McKenzie (Apr 20 2019 at 15:35):
If an element has a required binding, you can only include that element if it has a code from the specified value set. If you can't map to one of the defined codes, you can't send that element at all. So long as you can send one of the specified values, you're free to also send an extension (ideally as a child of that element) that conveys an alternate code, set of codes, free text, etc.
Last updated: Apr 12 2022 at 19:14 UTC
