Stream: implementers
Topic: Generic or specific profiles?
Dave Barnet (Jun 05 2018 at 12:15):
I'm trying to get a handle on options for profiling resources, and to what level to profile. Take the Observation resource for example - if a specification said to record a person's head circumference (in cm), would the general expected approach be to create a profile of Observation that had a fixed code (to represent a head circumference measurement - SNOMED 363812007 | Head circumference), fix the units to "cm" & profile out the bits not required such as the component section. I can see that this allows tight validation of head circumference, and may help in some code generation(?). However, following this method you'd end up with 1000s of observation profiles. Or is the expected approach to have fewer more generic profiles (and if so, what level of granularity is appropriate?).
Stefan Lang (Jun 05 2018 at 13:00):
On a national level. our apporach is to have open profiles (i.e. mostly non-forbidding). They are mainly about things like "If you want to put identifier X in your profile, use 'http://fhir.de/NamingSystem/X' as identifier.system". Or: "Use at least ICD-10-GM when coding a condition".
More detailed/specific profiles, which may also be more strict, e.g. forbidding certain elements, are rare on the national level, but possible. For example we have 5 well-defined observations within the national profiles (i.e. fixed code and value[x] restricted to valueWhateverDataType). These exist because there is a national use case for them.
For regional or project specific profiles I would expect very strict profiles where they are needed (as in "This profile exactly represents the capabilities of my system / of the systems involved"). This may well end in a whole bunch of Observation profiles and also others, when you need things like required ValueSet bindings.
But even in these use cases I would prefer the use of Must-Support over hard cardinalities.
Lloyd McKenzie (Jun 05 2018 at 13:12):
This is a bit of a philosophical question. There are definitely groups that like to define very narrow profiles. Your primary considerations should be "what can you expect your communication partners to support?" and "What do we have time to create and get consensus on?"
Kevin Mayfield (Jun 05 2018 at 15:15):
I think in some cases examples may be more useful? It could be time consuming to look through many profiles.
Kevin Mayfield (Jun 05 2018 at 17:39):
Adding a little context, when we looked at examples for Care Connect Reference Implementation we were ok with most Observations. We could see from DSTU2 profiles we would be expecting SNOMED for codes, so we created a head circumference examples which match your profile http://yellow.testlab.nhs.uk/careconnect-ri/search?serverId=home&pretty=true&resource=Observation¶m.0.qualifier=¶m.0.0=¶m.0.1=363812007¶m.0.name=code¶m.0.type=token&resource-search-limit=
Kevin Mayfield (Jun 05 2018 at 17:43):
Where we were unsure was around complex codes such as blood pressure, we did find examples (which matched how we done them in primary care systems years ago). Possibly this would be profiled to make it easier for implementers.
Our use case is RESTful API though and is your's a messaging/fhir document paradigm?
Grahame Grieve (Jun 05 2018 at 18:47):
one issue that we need to explore further is that of profile vs dictionary
Grahame Grieve (Jun 05 2018 at 18:47):
e.g. there's 4 or 5 profiles for lab results:
- numerical result
- coded result
- MCS
- immunology panel
- text report
Grahame Grieve (Jun 05 2018 at 18:48):
but for each of these there's 100+ or (1000s) or variants, all structurally the same.
Grahame Grieve (Jun 05 2018 at 18:48):
I think that this is StructureDefinition vs ObservationDefinition but that's work in progress
Grahame Grieve (Jun 05 2018 at 18:49):
e.g. set up a profile, and then link observation codes to units and reference ranges by Observation Definition (which equates to / represents LOINC concepts)
Kevin Mayfield (Jun 05 2018 at 18:57):
What is MCS?
I like the idea of Observation definition or a service like it. So I given a code I could query if it's coded or numeric plus which which units to use?
Grahame Grieve (Jun 06 2018 at 02:56):
yes that's right. MCS = Micro Culture and Sensitivity
Eric Haas (Jun 06 2018 at 03:02):
I've thought about this and I really don't see any short cuts to creating profiles. observationDefinition with a matrix of codes, allowed values, reference ranges and interpretations is simply deconstructing a profile. So my question is who does the 'Dictionary' + base profile benefit?
Grahame Grieve (Jun 06 2018 at 03:04):
it benefits the consumer because you know there's only one 'shape' of the observations. So one shape + 1000 variants that plug in (code + units + possible interpretations) is a lot less than 1000 profiles that say who knows what ?
Grahame Grieve (Jun 06 2018 at 03:04):
as in the consumer application that reads the observations
Lloyd McKenzie (Jun 06 2018 at 03:11):
The profile shape drives user interface design and a few other things. Dealing with 10 styles that cover 1000 lab tests is much better than dealing with 1000 profiles that could each contain totally different structures.
Bryn Rhodes (Jun 06 2018 at 03:27):
+1, having a single shape to deal with provides a lot of benefits from an implementation perspective.
Eric Haas (Jun 06 2018 at 03:38):
I don't see it as "1000 profiles that could each contain totally different structures." I see it as 5 base profile and 995 derived on top of one of those" I don't see a benefit in duplicating this in another structure. HIde the static stuff and you back into a dictionary.
Lloyd McKenzie (Jun 06 2018 at 03:41):
995 derived profiles can do all sorts of funky things - constrain out elements, add in additional slices or extensions, etc.
Lloyd McKenzie (Jun 06 2018 at 03:41):
A set of dictionary entries that only define values for the elements defined in the base profile is much more predictable and easier to manage.
Eric Haas (Jun 06 2018 at 03:54):
I remain a skeptic that this will be any easier. I think you make profiles sound scarier than they have to be, there is nothing stopping one from defining simple derived profiles without slicing and extensions btw.
Grahame Grieve (Jun 06 2018 at 03:56):
right. you could. But how do consumers know that you did?
Grahame Grieve (Jun 06 2018 at 03:57):
LOINC has 1/4 of the number of codes as SCT. But implementing LOINC is considered 1-2 orders of magnitude cheaper... and this is main reason why: It's at table., and people know how to deal with it as a table
Grahame Grieve (Jun 06 2018 at 03:57):
It's all about assurance
Eric Haas (Jun 06 2018 at 03:58):
Expose what they need as a table then, I don't think you need to expose everything
Eric Haas (Jun 06 2018 at 03:59):
Are we talking about a csv file or resources
Eric Haas (Jun 06 2018 at 04:02):
for a dictionary because I thought the premise was an observationDefinition resources for defining the dicitionary entries.
Grahame Grieve (Jun 06 2018 at 04:15):
well, I am talking about using ObservationDefinition as the table (dictionary). That's not all it's for, but I've asked OO to make this part of the scope / existence question for ObservationDefinition
Kevin Mayfield (Jun 06 2018 at 07:10):
@Dave Barnet , @Jonathan Mew and I has discussed this yesterday morning.
What we did was look for the differences between the DCH profiles, we came up with SNOMED codes, units, numerical/coded result. Which is sounding like a table/spreadsheet and is matching Grahams observationDefinition. I don't think it would be difficult to prototype.
Eric Haas (Jun 06 2018 at 15:20):
taking a look at ObsDef and ignoring components for now and thinking how a spreadsheet would unfold from this and some influence from Questionnaire I took at stab at it.
Eric Haas (Jun 06 2018 at 15:21):
| DE | Card. | Type |
|---|---|---|
| ObservationDefinition | DomainResource | |
| ProfiledObs | 0..1 | Ref(Observation) |
| code | 1..1 | Coding |
| Units | 0..1 | CodeableConcept |
| RefRange | 0..* | |
| type | 0..1 | CodeableConcept |
| value | 0..1 | Range\|canonical\|string |
| targetPop | 0..* | CodeableConcept |
| targetAge | 0..1 | Range |
| possibleAnswerValueSet | 0..1 | canonical |
| interpretation | 0..1 | conceptMap |
| or | ||
| possibleAnswerList | 0..* | |
| value | string\|coding\|integer\|decimal\|etc | |
| interpretation | string\|coding |
Eric Haas (Jun 06 2018 at 15:26):
obviously there is a choice of Units vs possible answers depending on whether a quantitative or nom/ordinal type of observation. with RefRange dealing with both.
Eric Haas (Jun 06 2018 at 15:31):
or you could just stick with a csv and a json template ;-)
Bashar (Jun 24 2018 at 14:53):
Hey,
Why to use Simplifier.net? Are there tutorials that teach how to use Forge ? I don't know, why should i use Forge and Simplifier together
Dave Barnet (Jul 13 2018 at 13:14):
I'm just revisiting the idea of Observation profiles and ObservationDefinition. At the moment I'm aligned with @Eric Haas earlier points, in that I can't really see a difference between an Observation profile and an instance of an ObservationDefinition. As ObservationDefinition.code is mandatory, and the example given is a list of LOINC codes, then an ObservationDefinition instance must relate to clinical concept - for example a waist measurement. If this is the case I can'r see any material difference between creating an Observation profile with a fixed code of "Waist Measurement" and some fixed units of "cm" as against creating an ObservationDefinition where the ObservationDefinition.code is fixed to "Waist Measurement" and the ObservationDefinition.quantativeDetails.unit is "cm".
Can someone enlighten me?
By the way, the ObservationDefinition says "Observation.basedOn references ObservationDefinition resource", but Observation.basedOn doesn't reference ObservationDefinition.
Vadim Peretokin (Jul 13 2018 at 13:24):
@Bashar Make profiles with Forge, upload them to Simplifier to publish them and show to others
Lloyd McKenzie (Jul 13 2018 at 18:36):
It's mainly a question of how systems want to access the information. A system that wants to download a lab's catalogue isn't necessarily going to want to have to deal with arbitrary nested slicing in order to convey allowed reference ranges, for example.
Eric Haas (Jul 14 2018 at 07:54):
The idea for using something like an observation definition instead of a profile is for a lightweight shortcut to making a bunch of profiles. I don't think we have worked out the right name for structure C but essentially:
Profile A + ObservationDefinifition B = Observation Template Instance C
Observation Template Instance C contains variables where you plug in the subject, effective time and value using something like the Python str.format() method to allow you to do variable substitutions.
I worked out a python example here
- This is what I thought Grahame was talking about.
Amir Mehrkar (Jul 15 2018 at 19:00):
Hi @Eric Haas @Lloyd McKenzie @Stefan Lang @Grahame Grieve - this is definitely an issue that has raised it's head again in www.INTEROPen.org - where we are creating UK national profiles, called CareConnect - @Dave Barnet post here started the discussion. I wrote a post for INTEROPen that summarised some of the issues bouncing around: https://docs.google.com/document/d/1N6xs5ZSq7aOwWxv5wb784vJCd8STtSqUa9kT0jCbUpQ/edit and there is quite a bit of debate on the topic in our discussion platform, https://interopen.ryver.com/#posts/1832297 , which may be of value. I cant copy the entire stream, but if you would like to access it do let me know - I can give you an account.
It looks like through our debate we have also "independently" hit on this issue of a possible rule-book for many "simple observations" of the code/unit form, which looks like it might also be the ObservationDefinition resource that I'm trying to get my head around.
I can see this OD is creating debate here as too as to its utility.
Ultimately, trying to understand the use cases for 1 type of template observation at a national level, version 1000s of profiles for simple code/unit pairs.
As we work with many vendors too, I'm particularly keen to understand what is the best approach (esp cost) for implementers.
And is there any real world experience of this challenge ....has anywhere 100s/1000s of observation profiles?
Grahame Grieve (Jul 16 2018 at 00:44):
firstly, I think that observation definition is more than a short cut for profiles on observation. A profile on observation is strictly confined to describing how the observation is reported, but Observation Definition can also deal with the context of the observation, and how to request it be performed, related methods etc.
Grahame Grieve (Jul 16 2018 at 00:48):
I've come to the conclusion that the central problem with lots of observations is shape. If you have 1000s of observations that all have the same shape, you only have to don one implementation, and just plug-in the variables into the code. Whereas observations that have different features require real work.
just giving implementers 1000s of observation templates leaves them out in the cold because they have to reverse engineer them back to figure out how they differ from each other. So we should be vigorously working out how to different between shapes and variables - that's what the dictionary idea that Eric is referring to is about
David Hay (Jul 16 2018 at 01:40):
Can you define what you mean by 'shape'? a set of common elements and (in some cases) values?
Lloyd McKenzie (Jul 16 2018 at 01:48):
Shape = primarily how value and components are used, though other things such as whether interpretation and normal ranges are relevant and what value sets they should have are part of it too.
David Hay (Jul 16 2018 at 02:34):
ta
Kevin Mayfield (Jul 16 2018 at 07:18):
Graham's second paragraph regarding shape, matches what we've been saying on Rvyer.
It is what we've been calling simple or generic Observation. Specific profiles can sit alongside the generic profile.
Eric Haas (Jul 16 2018 at 17:27):
We have a problem with a common set of terms to represent these ideas. But the words we use aside ... my main point with my posts is that ObservationDefinition needs to handle the use case we are talking about here and adequately covers the other contextual things that lie outside the Observation which Grahame mentioned above. ( I was being overly reductive when I said short-cut but that is essentially what we are talking about here.) As it is drafted is does neither. Unfortunately am unable to focus enough time with the topic and committee working on it to try to fix it.
Eric Haas (Jul 17 2018 at 14:34):
An alternative we discussed is to use a form ( aka Questionnaire ) to represent the actual 'variables' for a 'specific profile'. But then there would be no way to represent other context the the Observation
Amir Mehrkar (Jul 18 2018 at 14:03):
Thank you for the replies: So this issue of shape or pattern is exactly what I’m trying to understand: what is best for implementers, as the higher the barrier to entry, the longer we keep data locked up and reduce improving care.
One key shape/pattern I’ve come across is of “Fixed snomed code and Unit” pattern (aka simple observations) needing to be exchanged in an observation profile
eg a weight snomed code (or 1-3 codes allowed) and a unit (or 1-2 units) - I guess a UCUM server helps with the latter.
One approach that has been suggested is a profile for each of these codes. And one reason is that FHIR structuredefinitions allow for computational validation to ensure the message is conformant.
However, is this what implementers need?
Some have said, for a pattern like Fixed code / unit, you could use another validation mechanism to assure the message and 1000s of profiles is not the right approach.
And for validation/assurance, is there anotjer mechanism where you can say use say a terminology validation look up service?
Is that what ODefinition is providing? Or is there another method?
The other thing is that OpenEHR colleagues have been saying, such models of weight and height for example do tend to complexity - ie they tend to need other meta data - so whilst we may start with code/unit lists, in future we will need more specific meta data for these observations and so we should consider creating weight and height and other specific profiles now. However, most systems may not be recording all such meta data yet, so maybe we should just create these profiles “when” we need them....
Amir Mehrkar (Jul 18 2018 at 14:09):
as an example of the issue that may proliferate see the observations and procedure profiles: https://fhir.nhs.uk/StructureDefinition
Lloyd McKenzie (Jul 18 2018 at 14:59):
Implementers need to be able to define appropriate user interfaces and map to and from their legacy data structures. The number of patterns they can afford to do that for is in the low tens (and <10 for many). So the profiles at that level have to be pretty limited. If you can write your code once and load metadata that lets you send additional types of Observations over time, that's more managable. I think that's the intention with ObservationDefinition - the profiles are what you write your code to and are pretty static and limited in number. The ObservationDefinitions reflect what you can share with each of those profiles and are dynamic and have large numbers.
Eric Haas (Jul 18 2018 at 16:36):
We are talking about our hopes and dreams for ObservationDefinition right now I think as is drafted now it falls short . I've made some rather specific and pointed recommendations and I recommend anybody who is interested to give @Hans Buitendijk a holler to see when they are meeting again to discuss.
Eric Haas (Jan 23 2019 at 23:24):
reopening this stream to present an example of what I'd like be included in ObservationDefinition Scope. Here is a quick simple demonstration using it to generate multiple types of laboratory observations from a single generic profile. In Short, add Patient data, lab result value data and ObservationDefinition to a generic profile and create instances.
Eric Haas (Jan 23 2019 at 23:26):
I have a bunch of proposals for ObservationDefnition to make this more robust.. @François Macary When can we discuss this?
François Macary (Jan 25 2019 at 11:33):
@Eric Haas ObservationDefinition is discussed during the Order Catalog calls: Wed, 1pm Eastern. Next call is planned for Feb 6th.
If you like we can also arrange a 1st discussion with @Rob Hausam and I. My first availability is Monday 5pm Paris time (8am Sacramento).
Stefan Lang (Jan 25 2019 at 12:20):
If ObservationDefinition is intended to avoid large numbers of Observation profiles, the spec should also specify that validation of Observation instances against ObsDefs must be possible through the standard validation mechanisms (validator, $validate operation). Just as it is the case for QuestionnaireResponse against Questionnaire.
But I had a short chat with Hans on that at the WGM, and I understood that this use should probably not be within the scope of ObsDef?
Eric Haas (Jan 25 2019 at 14:51):
But I had a short chat with Hans on that at the WGM, and I understood that this use should probably not be within the scope of ObsDef?
I think we need to discuss this use case before making a decision about restricting its use to catalogs.. If we come to that conclusion then the resource name should not be observationdefiinion but observaioncatalogentry or something like that.
Stefan Lang (Jan 25 2019 at 15:05):
I think there are pros and cons to both. The complexity of the big number of observations that exist won't go away, so basically I think it's a question what would be easier from an implementer's point of view in terms of generating as well as validating Observation instances.
Eric Haas (Jan 25 2019 at 15:11):
I agree. Since obsdef reduces some of that complexity and is essentially a shorthand version of structuredef - it begs the question why not use it for that too. Otherwise we should be consistent and use structdef for catalog entries too. I appreciate your point on validation but isn't that accomplished at the profile or instance level (after applying the observation definition to a profile)
Lloyd McKenzie (Jan 25 2019 at 15:25):
I'd be opposed to ObservationCatalogEntry. Resources are supposed to be context-independent. There's lots of reasons for talking about a type of Observation that can occur without it being part of a catalog.
Rob Hausam (Jan 25 2019 at 15:58):
I happy for us to find a time to discuss this. That time on Monday (10:00 AM Eastern) would work for me.
Eric Haas (Jan 25 2019 at 17:02):
I was being rhetorical about ObservationCatologEntry, my point is that its scope needs work and ObservationDefinition implies more than catalog entries. On @Stefan Lang point of validation, I did not get it at first but I agree may then require a 2 stage validation - one for the Obsdef and one on the SD and it still needs to be determined if indeed is a shortcut for developers or not.
Stefan Lang (Jan 25 2019 at 17:06):
Right. Any implementer could somehow apply an ObsDef to an Observation profile, but if this use case was to be in the scope of ObsDef, this should just be part of the FHIR spec and especially be mentioned on the validation documentation page.
Last updated: Apr 12 2022 at 19:14 UTC
