I want to specify a Bundle with several entries - all of type Observation - and don't want to have a profile for each type of observation. I can add examples for each of the types of observation, just to show how it look. But that is just informative Is there anything in between that I can do - to show e.g. "for the same profile , eye movement has this code and these values" and "hearing tests has this code and these values"?

You could profile Bundle itself and slice and drill down into the entries, or you could define invariants on Bundle.

I've started using simple tables in the IG. Have considered using ObservationDefinition and/or Questionnaire In this example I went for table and Questionnaire https://virtually-healthcare.github.io/Questionnaire-DailyPhysicalActivity.html

this is an idea that's never quite landed. mostly, it's about co-occurance constraints between elements, but it's very often the case that you only get 90% coverage before things deteriorate into a set of complex rules

you could define invariants on Bundle. Invariants on a Bundle to mitigate FHIR profiliferation... I have several IGs in progress that might need to do this. Are there any downsides/trade-offs that I should know about other than extra documentation for clearer implementer guidance?

You could also use additional bindings to reduce the # of profiles. If all of your observations share the same value[x] type, or they all use valuesets in valueCodeableConcept, then in a single observation you can say - for this particular .code, use this valueset, for another .code, use another valueset. Here's a practical example -

That only fits a narrow shape of profiles though. In other cases I'm thinking of doing the same thing as @Kevin Mayfield , just show the constraints in markdown, because by some napkin math - I'll have to create 3k profiles for the use case I'm working with. R4 alone has only 6k profiles worldwide!

Even conditional bindings are not sufficient here, i think. I guess i would prefer something more structured and catalogable than markdown, but less normative than a full profile.

Would there be a way to create a differentiated profile type? And if so, could such a profile be an "example" of the main profile?

@Jose Costa Teixeira see #IG creation > Dynamic profiles .

I don't know what i should see there. I think conditional bindings are insufficient

@Jose Costa Teixeira agree with not using markdown. Personally, I don't like IGs with many observation profiles, especially when all they are doing is defining a code and unit. I'm watching others on my project to see what they do, quite a few are sticking with excel spreadsheets.

ok spreadsheets is evel less preferred than markdown for me :)

ditto. I've been meaning to look again at https://hl7.org/fhir/R4/observationdefinition.html and see if I can make it simple for the people who want to use spreadsheets (probably sushi)

Ideally use something like that to automatically create markdown tables.

Ultimately if it doesn't fit as additional bindings (for a template-like pattern), invariants, or the non-computable representation, we need to be wary not to invent something else that just complicates the concept of profiling further, and punts off the proliferation to this new thing. "we don't have hundreds of profiles, no... we just have hundreds of X instead" won't really solve the problem either. Some hard thinking is needed here to find a good middle-ground without significant tradeoffs.

Yes, agree with middle ground.

I am actually looking for inventing that new thing.

Process or content.

conditional bindings are kind of normative material - each new option would require publication

really, this is at the intersection of terminologies and profiles. The table has to be a code system, sub-setted by a vaue set, and then bound to a profile. The co-occurence strategy above is the correct one, but doesn't get us all the way yet

I'm interested, but would like to understand more. What is the problem with creating more profiles that this new "profile shorthand" thing would solve? In the total space of specifications based on FHIR (of the different types mentioned), we will add an additional type of specification and... what is the difference? I'm curious. Are regular profiles too complex to create? Too complex to use? Where is the friction?

it mostly happens in observation profiling. There's two reasons why it's good: a single code system with 6000 codes is easier to wrangle with (and publish) than 6000 profiles. It's a lot easier to implement 6000 profiles when you know that they are all the same shape, with variations in a table, rather than having to read 6000 profiles and figure out whether you have any surprises in there

also, if we have 6000 profiles, and 60 groups working on 100 profiles each, i expect overlaps and conflicts

the reason for my original question is not only on terminologies but on saying "if you use this code, then you should use .component and valueQuantity"

there are several other reasons why we don't want to necessarily create another profile (at least not an "official" profile) for each possible case.

essentially, dynamic profile constraints, on the information model level and not just on the terminology model level

the information model may be even more static than the profiles

while I started with a problem description that could be covered by conditional bindings, my scope is more generic than bindings.

Hence some ideas: Could we have a collection of "soft" profiles? (maybe this is not a technical thing, but a management problem). What would that look like? Could we have profiles that are just "examples"? would we simply mark them as informative? would that work?

Should we take a different view on this? I've recently been looking at Genomics both from V2 and FHIR perspectives. If I'm being honest I used both at different times to start understanding the data model. The first bit I understood was from the HL7 v2 Laboratory Results Interface where it described the Observations as a panel (is this an archetype? - in LRI a FHIR Questionnaire was used). This started to unlock the model what the profiles were describing. When it came to implementation I was tending to use the tables (aligned to panels) in V2 first and then mapping them to profiles. I'm using the profiles as part of our CI/CD process The main thing from this, is probably starting with an archetype or

As Grahame mentions, you can't eliminate complexity, just move it from one place to another. The question then becomes where do we want the complexity - either in the # of profiles, or within a profile, or somewhere else. of profiles is problematic for reasons we already know - makes it difficult to compare them and working with a large amount of profiles is challenging. adding complexity to the profile itself is then the better option. Additional bindings added a bit of complexity, but thanks to them, I was able to eliminate 3 extra profiles and have 1 profile that covers 4 usecases. Adding more dynamic support here will allow us to combine multiple "copy/paste" profiles into one profile. That's both easier on the humans to work with, and helps reduce profile proliferation. So, my option would be to allow the information model to be a bit more dynamic. fhirpath invariants help us get there, but the UI rendering for them isn't super nice which is the challenge with that appoach. If we could improve on this and allow fhirpath to dictate the information model changes depending on conditions, essentially extending conditional bindings from the terminology model to also work on the information model, that would be super.

I don't know what is missing of if this is still on the problem I raised.

for now i am profiling on Bundle.

the question of how to manage that complexity remains open - I think we are missing something there, and I don't see conditional bindings helps that.

I don't understand how this would be managed at the level of the information models

"conditional elements" would be the new thing. ... don't want to have a profile for each type of observation. With conditional elements+conditional bindings, you could have 1 Observation profile for your Bundle that serves multiple usecases. Let's flesh this out, can you give me the example bundle and constraints on Observations you need to express?

I don't understand what is to flesh out.

i want to a variable set of observations where, depending on the value of the .code, I can either have different VS for valueCode, but i can also have .valueQuantity or valueString.

they key part there is - variable set of...

once i do a profile, if i want to add one subtype to the set, I must republish the profile, which takes a few months.

and I don't want that

conditional bindings only support part of this, and that is a fixed profile.

Okay updating profiles without really updating them is a new problem, let's have aside for a moment i want to a variable set of observations where, depending on the value of the .code, I can either have different VS for valueCode, but i can also have .valueQuantity or valueString. Yes this is where conditional elements would exactly come in. Depending on the value of the .code, you could specify if you want a valueCode, valueQuantity, or valueString, and all of them could be conditionally bound to the right valuesets This would allow one to have 1 Observation profile that covers multiple usecases

but that is not what i want, or I would have implemented that

It sounds like you want late-binding on the actual profile rules without republishing the profile? I am not sure how that could work.

yes, or a way to have informative profiles - something that would indicate "these are just some sub-profiles that we know are based on this generic profile - there may be more but we want to list them for guidance, not to publish every single one"

For that, I would think about just publishing the generic profile and keeping examples in something like a GH repo.

Example sub-profiles? Or example instances?

Or matchetypes...?

Yes? If you are saying there is a lot of content that is changing more frequently than publication and that content is just for reference (examples), it is likely that content should not be in the publication. The content would not be published (e.g., if you are adding profiles, the validator will not resolve them), but if they are just for reference then it makes life simpler.

This is just one approach: In the MCC Care Plan IG( https://hl7.org/fhir/us/mcc/ ) we created a set of base profiles and have a table with guidance about what value sets should be used where, within each profile, Thus we have about 23 profiles - instead of hundreds. See here for general guidance ( https://hl7.org/fhir/us/mcc/mcc_value_set_libraries_and_usage.html ) and here is and example of the value sets used on the MCC condition profile ( https://hl7.org/fhir/us/mcc/mcc_chronic_condition_value_sets.html ) . The downside is that th value sets that are not bound do not participate in validation supported by the IG publisher - but could be leveraged in implmentations.

I like that idea of a parent 'profile' and child 'guidance'

still on this, I did profiling directly on Bundle.

but now I get errors validating an example