Stream: implementers
Topic: Implementation guides, profiles, and extensions
Matthew Koch (Jun 21 2018 at 19:09):
I just attended FHIR Dev Days in Boston, what a great event! As I sit on the train back to NY today, a lot of information is swimming in my head and I'm trying to make sense of a few things. I wonder if someone could shed some light on the following. There are some questions in here, but also a few statements that summarize my understanding of key concepts. Comments on whether or not I'm on/off base would be appreciated :grinning:
-
Implementation guides - I've heard a lot of talk about these. The Argonaut guide comes to mind, along with US Core. http://hl7.org/fhir/us/core/index.html Since a lot of work has gone into these guides, it doesn't feel right to start over. What would be the recommended approach to using, for example, the US Core implementation guide as a base, but customizing it to fit our use case in clinical research?
-
Profiles - these appear to be super important when coming up with agreed upon contracts with respect to data exchange. They also seem to go hand in hand with an implementation guide, which from what I have seen just summarizes profiles, extensions, search parameters, capability statement. Is this accurate?
-
Extensions - Used to define valid requirements not part of the core FHIR specification.
All of the above seems like where we need to start if we want to have meaningful dialogue around an exchange mechanism for clinical research use cases. Hopefully some FHIR experts can weigh in!
Lloyd McKenzie (Jun 21 2018 at 20:35):
Hi @Matthew Koch. Glad you had a good time at DevDays.
1. There are two approaches to "using" U.S. Core or any other IG. One is to derive your IG and profiles from those defined in the parent IG. In that case, you inherit/have available what the other IG has defined and are bound by whatever constraints they've made. If the parent IG says 1..1 or fixed value or fixed binding or "must support", you can't loosen that. But you can add additional guidance, add further constraints, introduce additional extensions, etc. The other possibility is to be "aligned with" or "informed by". In that case, you create your own parallel IG/profiles and you do your best to follow the patterns and constraints in the base IG, but you might diverge from time to time because your context is different. For example, if I was creating a Canadian equivalent of US Core, I'd try to stay pretty close - because we want solutions that work in the US to work in Canada with minimal modification, but we'd have to change a few things, such as the notion of race & ethnicity (which are very US-centric), change bindings from RxNorm to the appropriate Canadian code system, etc. That wouldn't be a derived IG, but it would (hopefully) be an 'aligned' IG. Note that 'alignment' isn't a formal assertable/testable thing. It's just an intention you can have and maybe document in text.
2. Implementation guides collect a set of profiles, extensions, search parameters, capability statements, examples and other conformance resources together into a package that gives guidance to implementers on how to use FHIR to solve a particular problem/set of problems in a particular context.
3. Extensions - yes. Essentially extensions are used to keep all implementers from having to worry about edge cases that are important to only a limited subset of implementers.
Matthew Koch (Jun 22 2018 at 11:59):
@Lloyd McKenzie Thanks! This is very helpful. What would you recommend for authoring an implementation guide and profiles? Simplifier.net looks nice but there is a cost involved.
Matthew Koch (Jun 22 2018 at 12:50):
Actually it looks like you replied to a similar thread here https://chat.fhir.org/#narrow/stream/4-implementers/subject/How.20to.20create.20.22implementation.20profiles.22.3F/near/119643. I'll have to check out those options.
Lloyd McKenzie (Jun 22 2018 at 15:44):
Simplifier has a cost and has some limitations around what you can do and on look and feel, but gives you a nice user interface and holds your hand along the way (plus you can get paid support). For profile authoring Forge and Trifolia are free, but won't necessarily support everything the methodology allows, nor will they always support the current version of FHIR. The HL7 IGPublisher is free, but it can be pretty involved to set up. You're best off to start from an existing IG and tweak than to start from scratch with just the documentation.
Eric Haas (Jun 22 2018 at 18:05):
If you want to take the plunge into using the HL7 IG-pub. Here is my starter template to get you started. Its based on US-Core
Eric Haas (Jun 22 2018 at 18:06):
assumes knowledge of Jekyll, and liquid and kramdown markdown.
Martijn Harthoorn (Jul 02 2018 at 13:43):
@Matthew Koch , we have recently changed our plans for Simplifier. Your first project + IG is now free.
The way to go on Simplifier is to
1. Create a project.
2. Upload your profiles
3. Create an Implementation Guide
4. You can write in Markdown. You can reference + render your profiles by using place holders like {{render:my-first-patient-profile}}.
Simplifier works with DSTU2 and STU3. We will have support for R4 before the the next WGM.
Matthew Koch (Jul 05 2018 at 14:20):
Thanks all. We have some options. I'll definitely get my hands dirty with the IG-pub from HL7 at some point...but while I know markdown fairly well, I am a complete novice with Jekyll.
Brian Reinhold (Aug 03 2018 at 15:18):
@Lloyd McKenzie Are there some examples of IGs that have been created with the IGPublisher that I could start with?In DoF we need to use the upcoming R4 and understand that Forge/Simplifier will be unable to support that. So we need to move over to something else. Looks like IGPublisher is the option.
However, it is really hard to know how to start. Would be a lot easier to modify an existing working example.
Also, is this best run locally or using the web app?
THanks
Stefan Karl (Aug 03 2018 at 17:46):
@Brian Reinhold You can find here what I ported from Simplifier for the PoCD IG so far.
Lloyd McKenzie (Aug 03 2018 at 20:32):
The most recent work I've done integrating Eric's approach and mine can be found in the genomcs-reporting and davinci-crd IGs. Eric hasn't had a chance to look at and sign off that he likes what I've done, but that's the closest to a 'most current' template that we have right now. I'm still working on making it support multiple versions in a single publication and I also noticed a bug while demoing today that I need to fix.
Lloyd McKenzie (Aug 03 2018 at 20:33):
Both use the spreadsheet authoring approach for the profiles, but if you'd rather use Trifolia or author by hand, that should work just fine.
Lloyd McKenzie (Aug 03 2018 at 20:34):
I always run locally and rely on the CI Build when checking content in. I've never used the web app - does it auto-update as the IGPublisher code changes?
Last updated: Apr 12 2022 at 19:14 UTC
