Stream: implementers
Topic: parameter modifiers, commonly used
René Spronk (Aug 30 2018 at 07:00):
Whilst working on a FHIR Search module for our FHIR training course (theory + hands on exercise): there are way too many parameter modifiers to cover all of them in the training course; intent is for attendees to understand how they work (and where to get the documentation in case they need other modifiers than the once covered).
Question: which are the 'most important' / 'most commonly used' modifiers which should be included in a search-exercise ? @Alexander Zautke will be digging through the logs of the popular test servers at some point in the future to see what's being used, right now I'm asking for your opinion. :missing, :contains, :text are already on my list, what else ?
Grahame Grieve (Aug 30 2018 at 22:36):
every modifier has a real use case. But some are specialist. I'd consider addng :exact to your list
Grahame Grieve (Aug 30 2018 at 22:37):
and most definitely :in
Grahame Grieve (Aug 30 2018 at 22:37):
and :[type] is necessary syntactically in chained searches
Grahame Grieve (Aug 30 2018 at 22:37):
:below for codes, as well. and maybe URIs
René Spronk (Aug 31 2018 at 07:17):
I'll briefly cover :in and :below in a terminology-oriented module, too tricky for a generic search module. Search exercises currently use :exact :missing and :[type]
Grahame Grieve (Aug 31 2018 at 07:22):
if :in is too tricky, then we've done something wrong; searching for all observations in a set of codes is just fundamental
René Spronk (Sep 01 2018 at 14:14):
:in in and of itself isn't too tricky, but in general (true for any standard we provide training courses for) terminologies and concepts like value sets, bindings, let alone expansions and ontological relationships are a hard sell to an audience interested in the overview of a standard.
There are two areas where (as a trainer) we feel we're covering a required subject, without the there being a lot of enthusiasm about the subject with the attendees, and those are terminologies and security. In my book all attendees need to be aware of value sets, expansions, and ontological relationships. Not all of my fellow tutors/trainers actually agree with me on this, they think it's too complex for an overview training course. We've also removed any coverage related to the 'creation of profiles' (we do cover 'use of profiles') - the % of implementers who have an interest in this is just too small. We do however have a separate training course related to profiling and the creation of IGs, however there's not a lot of uptake.
David Hay (Sep 01 2018 at 18:43):
Interested to know the 'type' of attendee you get in your courses - in particular technical vs clinical...
Grahame Grieve (Sep 01 2018 at 20:30):
terminologies is an interesting subject. FHIR has quite deliberately normalised terminology use, and not all the community has come along for the ride. All along, we've seen infrastructure, tooling, profiles, implementation guides, training courses, implementations that are well advanced in their 'conformance' handing (elements on / off) but rudimentary in their terminology management, as if this somehow actually works. And by the same token, we've also seen (and still see) terminology participants who are caught unawares by the breadth of the way that we use terminology
Grahame Grieve (Sep 01 2018 at 20:30):
there's an inherent weirdness in people not being interested in security
René Spronk (Sep 02 2018 at 12:11):
@David Hay mainly non-clinical. Hospital IT departments, vendors, project managers, systems managers, help desk employees, interface specialists - a fairly wide range of backgrounds, but mostly not primarily clinically focused.
Peter Jordan (Sep 02 2018 at 23:21):
Hi @René Spronk, I'm interested in your thoughts on why only a small % of implementers who attend your FHIR courses are interested in profiling and the creation of IGs. Is that because these artefacts are being created at a national level in The Netherlands and/or because of the perceived level of complexity involved?
Robert McClure (Sep 02 2018 at 23:26):
@René Spronk Yes, understanding terminology is still to damn hard and thank goodness you still force folks to learn about value sets and expansions. We, those that read zulip, need to get serious about using terminology for real in our connectahons and test environments. @Carol Macumber and I stand ready to buy beers for any track that actively exercises terminology service functions, particularly confirming access to version-specific expansion.
Peter Jordan (Sep 03 2018 at 02:03):
@Robert McClure - does that offer extend to the Terminology Services track? If so, please bring a barrel!
Grahame Grieve (Sep 03 2018 at 02:18):
the terminology services track can buy itself as much beer as you like ;-0
Peter Jordan (Sep 03 2018 at 03:48):
Need something to wash down all those fragments and supplements! :simple_smile:
David Hay (Sep 03 2018 at 04:16):
did I mention that clinFHIR uses terminology services? Perhaps a glass of beer for each call? I'll put the logging in place right away...
René Spronk (Sep 03 2018 at 07:46):
wrt Terminology: most people don't understand why this is a problem - so raising awareness of the underlying issue is the first thing we need to do (also as part of training courses). Talking about the 'solution space' (FHIR resources, terminology servers) doesn't make sense if we can't convince the audience of why we'd need them. We do cover terminology servers, but no hands-on stuff as that would require too much of a deep dive in the solution space. I really need a TED -talk for a generic audience about the problem space!
As for profiling: I was kind of hopeful (as were others) that with FHIR we'd see a wide use of profiling by a large degree of implementers. Whilst it's probably better than in the case of v2 we're effectively seeing the same thing as with CDA/v3/v2: almost all implementers won't ever create a profile in their lifetime, they'll either wing it without any profiles at all, or they'll commit to build something according to an IG created by a profiler-enforcer (to use a v3 term). As such the average implementer has no need to know about the process of creating profiles. They do need to know how to work with profiles created by others, and with validation.
But I'd love to be corrected on this assessment.
Profiling is necessary, as are terminology, and security, and the mapping from logical [requirement/clinical] models to FHIR profiles. But many of these aspects are a 'hard sell' - although some aspects (clinical models, terminology) may be easier to deal with if one has a clinical audience.
Grahame Grieve (Sep 03 2018 at 09:14):
I think you're right about profiling, for now. Most implementers won't do that. though not all - some find it natural to want reflection...
Grahame Grieve (Sep 03 2018 at 09:15):
terminology is where we should focus. I still see profilers not delivering on terminology due to combination of not appreciating the value, not understanding the process, or not mastering the tools.
Grahame Grieve (Sep 03 2018 at 09:16):
same applies to implementers - properly using terminology is critical, and they haven't really solved problems if they'd ducked that
Grahame Grieve (Sep 03 2018 at 09:16):
giving them the tools should make a big difference with this
Lloyd McKenzie (Sep 03 2018 at 15:57):
Profiling will become more important if there's an expectation for implementers to formally document their capabilities and to demonstrate compliance against those statements using testing tools. That will only happen with customer demand though.
John Moehrke (Sep 03 2018 at 17:32):
I have been aggravated by developers in the past month.. I tried to point them to the Profiles (Argonaut), they refused to look. I then walked them through the profile, they refused to use it. They didn't even get motivated when I showed them an example. What? Not even an open-source app that did the same thing. It is only after I wrote a spreadsheet mapping table that they acted. I somehow expected them to get excited somewhere in there. When I ask, the problem is signal to noise overload. The human readable table with only high-level mapping (like the mapping in the FHIR spec) was more signal than noise. Even the nice html view of the profile (argonaut) was too noisy (likely all good data, but perceived as noise). They are now interested in turning a FHIR server into verbose profile validation so they can code to the test-tool... -- just one set of developers as a data-point.
Patrik Sundberg (Sep 03 2018 at 21:29):
I think a core part of the issue is that the FHIR spec is enormous, and for developers with little healthcare experience, the mental burden of absorbing it is substantial. It's much easier to just say "eh, that looks overengineered, I can build something simpler myself that covers my use case", and in all fairness, for many other domains that would be quite a reasonable statement.
We're not doing a good job as a community pointing people to use cases they're likely to encounter, explaining why things are done the way they are, and showing code examples of how to do various simple tasks. It needs to be easier to do the right thing than the wrong thing; until then, a substantial number of developers will gravitate towards various shortcuts that suit their needs.
Grahame Grieve (Sep 04 2018 at 01:24):
can you iterate the use cases people are likely to encounter?
Patrik Sundberg (Sep 04 2018 at 01:58):
I can outline a sequence of use cases typical from my point of view; but this list would in no way be exhaustive or comprehensive
- I'm a developer who wants to use language X for my app / product / platform. Given that, now i want to:
- create a basic simple fhir resource from some data i have. explain the most basic ~5 fields for each of the most basic ~5 resources
- link a few resources together to create a consistent mini-record
- add some data i have that doesn't seem to fit anywhere: i need extensions (and help from chat.fhir.org)
- get help keeping track of all the extensions i'm using: i need profiles
- store this data somewhere (or read it from other servers)
- interact with real data. i have patients who want my app. where do i even start?
- I'm an analyst who needs to properly map data into fhir or do analysis of data already in fhir
- explain code systems and value sets to me
- walk me through observations of various kinds: how do i encode vitals? panels? examples please
- walk me through encounters. how do the value sets map to inpatient/outpatient/short stay, etc. examples please
- walk me through medications. what's this about contained resources? how do i query over them? examples please
- how do i query for basic patient safety indicators / average length of stay / etc. examples please
- what's all this stuff about terminology servers? do i even need it and if so why?
- I'm an executive looking for complete cloud fhir solutions
- how do i test and evaluate performance of a solution without investing an arm and a leg on running tests and benchmarks?
many of these pieces exist but it's hard to find storylines where each part builds off another without introducing an overwhelming amount of new material.
Grahame Grieve (Sep 04 2018 at 03:03):
I'm interested in opinions on this
René Spronk (Sep 04 2018 at 06:40):
Our European FHIR training course follows a use case [throughout the course] like the ones sketched by @Patrik Sundberg - it helps to tie all the fragments together, it provides a "reason" as to why certain bits are covered and others are not; if people understand "why" certain bits are being covered they have more of an interest in the subject and they're less likely to cast it aside as something that won't bee needed in a shortcut implementation.
Eric Haas (Sep 04 2018 at 15:20):
I've always wondered if we need a FHIR lite which focused on all the stuff you need to get started and removes all the Noise. Then when you get stuck or need more functionality you can dig into the full spec. One consequence is it would uneven the playing field making getting wider adoption and maturity for artifacts left out of the "core-lite" view harder ( which IMO is not bad thing) and probably overusing the 'core-lite' artifacts.
John Moehrke (Sep 04 2018 at 16:25):
so there is the current front-door that does not have everything on it... is this a question of how to trim that even more? The problem we will have is to ask domain experts to pick more resources to NOT highlight on this front-door... (e.g. Terminology need only list ValueSet and CodeSystem). Other perspectives are on exchange types or interaction types (e.g. I would like to see DocumentReference on the lite page). I suspect we will get passionate arguments about what is lite and what is not-lite. I have no idea where discussion that has concluded on this set has happened.
Grahame Grieve (Sep 04 2018 at 21:56):
from where I sit... everyone has a different use case and wants a different view. I do not see any coherence around which use cases we'd prioritise. Must of them will be taken up in IGs - which haven't really solved this problem at all anyway. @Patrik Sundberg's list was interesting because it was a structural take, mostly seperated from specific use case
Grahame Grieve (Sep 04 2018 at 21:56):
as such, I think it relates to the Implementer Support module
Eric Haas (Sep 04 2018 at 23:10):
I never looked at the Implementer Support module until now. But looking at it I don't think that what I was thinking about. I was thinking about the first time user experience and not overwhelming them with content. (there's no shortage of that)
Last updated: Apr 12 2022 at 19:14 UTC
