Stream: implementers
Topic: Fixed Code vs Pattern
Shovan Roy (Jul 23 2019 at 23:21):
Hi All,
I'm working on drafting bunch of Observation profiles and would like to seek the recommendation from the group which option is better to model Observation.code. As per my understanding, I believe the options are to use open sliced Fixed code or use a pattern for Observation.code.coding. The objective is to let the implementors what code they must supply to make it conformant with our profile but additional codes are allowed
Regards,
Jean Duteau (Jul 23 2019 at 23:21):
pattern on Observation.code.coding. That's what I do for my Observation profiles.
Shovan Roy (Jul 23 2019 at 23:35):
Thanks @Jean Duteau , have you noticed any advantage of using pattern. I'm more inclined towards using pattern but just want to ensure that it doesn't bring any additional complexities for the implementers.
Looping in
@Grahame Grieve , @Brett Esler , @Richard Townley-O'Neill , @Reuben Daniels ,
Eric Haas (Jul 24 2019 at 00:22):
For me it is a matter of style. I shy away from patterns. they are easier to author for sure but I think harder for the reader to understand in the publisher tree view.
Lloyd McKenzie (Jul 24 2019 at 00:40):
Doing fixed code "properly" is hard - because you're fixing the code and system within a single coding without fixing all of them. You also need to declare a whole lot more elements in your profile. The pattern can be easily asserted at the CodeableConcept element level and is harder to mess up.
Lloyd McKenzie (Jul 24 2019 at 00:41):
Only real benefit to setting fixed values for code + system is that "old" validators might not be able to handle pattern. (Same issue if you need to translate your StructureDefinitions into STU2)
Lloyd McKenzie (Jul 24 2019 at 00:43):
@Eric Haas I think both approaches (slicing on nested content or patterns) are hard to make intuitive visually. Anyone with insights on how to make the rendering more intuitive, ideas would be most welcome...
Chris Moesel (Jul 24 2019 at 12:38):
I agree with @Eric Haas -- I prefer fixed[x] because it is easier to read in the IG docs. The fixed[x] components stand out, but the pattern[x] components just render as an ugly JSON blob.
Lloyd McKenzie (Jul 24 2019 at 12:53):
They do stand out - but they are often misinterpreted as fixing the values on all repetitions.
Chris Moesel (Jul 24 2019 at 13:07):
Understood. I do like the idea of not having to slice coding. But when I decided which approach we would take in our tooling, I also looked at all of the official FHIR profiles (like vital signs) and noted that they use fixed codes. It seemed best to follow their lead. I actually do think it would be a benefit to the FHIR community for FHIR to establish some "best practices" for approaching things like this. Whenever there are two ways to do something, it would be nice to have some guidance on which one to prefer.
Lloyd McKenzie (Jul 24 2019 at 13:28):
When vital signs were first authored, pattern either didn't exist (or didn't work)
Eric Haas (Jul 24 2019 at 19:01):
Slicing is usually about one member of a repetition. If you don’t understand that you won’t get it any way. So in summary my way is way easier on the eyeballs.
Eric Haas (Jul 24 2019 at 19:03):
I think a style guide is a good idea. We will call it “Moesel and Haas”
Shovan Roy (Jul 24 2019 at 23:26):
Thanks Everyone, the comments and feedbacks are very interesting and useful.
sounds like majority of the working groups prefer using fixed. @Lloyd McKenzie , is there any plan for the community to publish a 'pattern' version of Vital Sign profiles? As @Chris Moesel mentioned, a guideline from Community on topics like this will be helpful.
@Brett Esler , let's chat around this in the next CWG and see if we can include something as AUS guideline.
Lloyd McKenzie (Jul 24 2019 at 23:27):
We'd never consider publishing the same profile different ways. We could change the style between versions - even if normative - if the change was one of style rather than substance.
Grahame Grieve (Jul 26 2019 at 10:59):
@Chris Moesel I don't understand the point about the difference in rendering between fixed and pattern. I render both of them the same way.
Grahame Grieve (Jul 26 2019 at 10:59):
I strongly recommend pattern rather than fixed unless you really are saying 'no text'. That's generally a bad idea and it's false economy to make things easier for users in ways that breaks them
Chris Moesel (Jul 26 2019 at 13:19):
@Grahame Grieve -- maybe you render using a similar approach, but the visual output is definitely different for this specific used case (fixing a concept).
Sliced w/ fixed system and code (image 1) vs patternCodeableConcept (image 2):
pasted image
pasted image
Chris Moesel (Jul 26 2019 at 13:21):
IMO, the first approach (sliced and fixed) is much easier to scan and visually process.
Chris Moesel (Jul 26 2019 at 13:23):
I strongly recommend pattern rather than fixed unless you really are saying 'no text'.
Ah. I think maybe you misunderstood what @Eric Haas and I are advocating for. I agree that fixedCodeableConcept or fixedCoding would be a bad idea. We're talking about slicing coding and fixing the system and code independently (which would allow text or display).
Lloyd McKenzie (Jul 26 2019 at 14:17):
Actually you're slicing the thing containing the CodeableConcept and you're slicing Coding. It's introducing that two layers of slicing that makes the 'fixed' approach challenging and hard for people to understand.
Grahame Grieve (Jul 26 2019 at 20:16):
it's you that's doing something different - you're fixing primitive fields rather than fixing a pattern for a complex type. Anyway, I'm open to the idea that a fixed value or a pattern value could be represented in a different way
Shovan Roy (Jul 28 2019 at 23:08):
Thanks @Grahame Grieve, @Lloyd McKenzie
If pattern is the preferred option, then as I mentioned, is there any plan to draft Pattern profile for Vital Sign? If I adopt pattern for my profiles (which I'm very inclined towards doing) but Vital sign remains as fixed, then it kind of makes the profile approach for my IG inconsistent. Though it's not a major issue but any I was wondering if anything can be done by the FHIR community so that consistent approach can be taken for the IG publishers. whoever uses fixed they can take the fixed Vital sign and there will be an option for 'pattern' implementer? sorry if it's a too much of ask and sounds non reasonable :)
Lloyd McKenzie (Jul 29 2019 at 00:47):
Feel free to submit a change request to the Vital Sign profiles. I expect the outcome will be some formal guidance on preferred approach from MnM. That will likely result in a change to using pattern, but that outcome isn't guaranteed.
Eric Haas (Jul 29 2019 at 05:44):
We don’t agree on a style. And it appears there is more concern for the authors convenience than the readers ability to understand the content. certainly not a fan of changing the vitals profiles so there will be push back unless a better case for a change can be made.
Grahame Grieve (Jul 29 2019 at 05:47):
It's got nothing to do with author's convenience. if you fix the value of a CodeableConcept yo are not only saying "this code", you are also saying:
- no text.
- no other codes
- no version (unless you fix the version)
- no extensions
Grahame Grieve (Jul 29 2019 at 05:47):
On the other hand, but using pattern, you can say 'this code', while not nailing down the other things. This makes your profile more robust to other use cases, and to underlying terminology issues
Lloyd McKenzie (Jul 29 2019 at 05:49):
They're not fixing the CodeableConcept. They're fixing a single code and system within a slice of Coding.
Lloyd McKenzie (Jul 29 2019 at 05:50):
However, that doesn't work if you're slicing on the CodeableConcept itself
Lloyd McKenzie (Jul 29 2019 at 05:50):
Right now, the tooling doesn't slicing happening inside a discriminator.
Grahame Grieve (Jul 29 2019 at 05:53):
well, a double slicing is not only hard for the validator (where I haven't faced that challenge), it's a cognition load on the user too. It achieves the same as a pattern, but at a higher price. So why not use a pattern? What have I missed?
Is this purely a snit about how the pattern is represented in the table format?
Lloyd McKenzie (Jul 29 2019 at 06:01):
I think that's the main issue, yes.
Grahame Grieve (Jul 29 2019 at 06:20):
well, can we do something about that?
Grahame Grieve (Jul 29 2019 at 06:21):
I'm game, and I have an idea but I'm looking to canvas others before committing time to coding something
Eric Haas (Jul 29 2019 at 07:10):
We don’t agree on a style. And it appears there is more concern for the authors convenience than the readers ability to understand the content. certainly not a fan of changing the vitals profiles so there will be push back unless a better case for a change can be made.
Grahame Grieve (Jul 29 2019 at 07:13):
We don’t agree on a style
This was an exact repeat of above.. probably a technical glitch
Kevin Mayfield (Jul 29 2019 at 07:14):
On a related note, is ObservationDefinition being progressed in R5?
A number of developers I've spoken to, do not like fixed codes profiles (especially those familair with CodeSystems), we have to spend a lot of time working out the 'diff' which ObservationDefinition or a spreadsheet offers. Patterns or profiles on the different types of Observation (Value, CodeableConcept) [with examples] seemed more useful. So if you wanted a 'smoking status' observation, you would use ObservationDefinition to find the smoking status entry, which you tell you the code, valuset and which Observation profile (implied via CodeableConcept type) to use.
Grahame Grieve (Jul 29 2019 at 07:50):
Actually, this is on my todo list - we want a bi-directional transform between profile and a more tabular structure, since you oly have the program the table once
Lloyd McKenzie (Jul 29 2019 at 14:10):
We could quite easily come up with a 'standard' rendering for the common pattern of a pattern that locks down a single coding to a particular code & system. I'm not sure how easy it will be to come up with a generic pattern rendering that's cleaner though.
Robert McClure (Jul 29 2019 at 14:29):
I'd like to understand what you all are wrestling with. Any guidance on how to get up to speed on these two approaches and the visual target you're aiming for? Where would this be discussed in ATL if that is the plan?
Lloyd McKenzie (Jul 29 2019 at 14:34):
If discussed, it would be during a FHIR-I session, or maybe the Monday lunch session
Lloyd McKenzie (Jul 29 2019 at 14:35):
Question is the style you see on code here: http://build.fhir.org/ig/HL7/genomics-reporting/obs-haplotype.html
vs. here: http://build.fhir.org/resprate.html
Lloyd McKenzie (Jul 29 2019 at 14:36):
The former is the only way you can do it in some cases. There are different opinions about which approach is easier for implementers to understand. And no-one's super-enthused about how either approach renders.
Rob Hausam (Jul 29 2019 at 15:15):
I think the pattern approach is simpler and more understandable, but the visual rendering of the two fixed codes in coding approach is better
so not a particularly clear choice
I'm starting to go toward pattern more myself
Yunwei Wang (Jul 29 2019 at 17:54):
@Lloyd McKenzie I can find documentation for slicing at (https://www.hl7.org/fhir/profiling.html#slicing). Where is documentation for pattern?
Lloyd McKenzie (Jul 29 2019 at 23:37):
http://build.fhir.org/profiling#pattern
Chris Moesel (Jul 30 2019 at 01:16):
The link above doesn't go to a specific part of the profiling page (at least not in my browser). That said, the profiling page discusses pattern as it applies to slicing and discriminators. If you just want to know about using pattern to indicate that an element's value should conform to a certain pattern, see this documentation: http://build.fhir.org/elementdefinition-definitions.html#ElementDefinition.pattern_x_
Eric Haas (Jul 30 2019 at 03:33):
@Kevin Mayfield I think we are talking about profile styles. but I agree with your approach and have written a python script to do just that with tables. Its a shortcut to profiling observation
Eric Haas (Jul 30 2019 at 03:37):
I think if we fix the rendered output so its easier on the eyes the we are in agreement.
Kevin Mayfield (Jul 30 2019 at 07:39):
Screenshot_20190730-093811_Chrome.jpg
Grahame Grieve (Jul 30 2019 at 07:43):
right. requires consistent profiles that you plug values into from the table. It's on the to do list for the core, though as you show, it doesn't necessarily need core to make it happen
Kevin Mayfield (Jul 30 2019 at 07:59):
Yep, I think I'm looking at doing the same with ObservationDefinition as the table.
I'm not sure if this is a snomed, read or icd9/10 view of coding but I'm seeing ObservationDefinition as an extension on top of Code (from CodeSystem).
Or put another way, if the code (from codesystem) has a table entry (or ObservationDefintion) then it also has an implied or computable Observation profile.
I've added a picture of the work I'd done, as a developer I'd probably use a screen like this when working with observation profiles. As a developer once I've understood the 'boiler plate' observation profile, I would rarely use it.
Grahame Grieve (Jul 30 2019 at 08:01):
I have a diagram about this somewhere:
Medication builds on rxNorm / DM+D etc
ObservationDefinition builds on LOINC
ConditionDefinition builds on Snomed Findings heirarchy
BodyStructure builds on Snomed AnatomicalLocation heirachy
Grahame Grieve (Jul 30 2019 at 08:02):
They are not the same thing, but they are closely related
Kevin Mayfield (Jul 30 2019 at 08:14):
I'll have a look at those, I'm wondering if they have a set of generic properties which could be in a 'CodeDefinition' resource.
Grahame Grieve (Jul 30 2019 at 09:54):
That’d be a “Concept” Resource. Vocab talked about this in depth at the last meeting, and decided that we didn’t want a definition for this resource. CodeSystem is what we’ll stick with
Grahame Grieve (Jul 30 2019 at 09:55):
But there’s a cut off point - a hazy point - where there’s benefit to a generic concepts with properties, and then others where there is not.
Grahame Grieve (Jul 30 2019 at 09:55):
But in several places we trade between the 2
Kevin Mayfield (Jul 31 2019 at 07:03):
Cheers. I need to research this, I think their will be a difference between developers and modellers/terminologists views in this. I don't see much understanding of terminology (snomed) by developers these days and my gut feeling is advanced use obscures more simple use. A Concept resource could be the bridge to understanding (and more widespread use).
Rob Hausam (Jul 31 2019 at 12:12):
@Kevin Mayfield Could you elaborate more on why and how you think a Concept resource would serve to provide that bridge?
Josh Mandel (Jul 31 2019 at 12:56):
I think this discussion is relevant for the CARIN BlueButton guide (FYI @Amol Vyas (Cambia)), which currently uses fixed bindings for a number of CodeableConcepts. From discussion here, pattern should be the right way to express.
Kevin Mayfield (Jul 31 2019 at 16:00):
@Rob Hausam I’ve noticed a quite a few developers struggling with codes. Example question ‘what is the snomed code for body weight’, My answer would be to use https://snomedbrowser.com/
Using a full snomed browser gives a lot of data but obscured the answer. (A simple test at a recent event got the answer several minutes ahead of official browser by using the simple one.
Likewise terminology queries in FHIR are more involved compared to other resource queries. I’m the only developer in the UK that I know of who has attempted terminology queries. I’m not sure why this is so but I suspect it’s a combo of lack of knowledge of snomed plus more different style of queries in fhir terminology.
I need to look into this though and prove.
Lloyd McKenzie (Jul 31 2019 at 16:21):
@Kevin Mayfield I think that's distinct from how we want to represent slices that are tied to a particular code?
Rob Hausam (Jul 31 2019 at 16:24):
Yes, @Kevin Mayfield. Maybe would be good to post as a topic on the terminology stream?
Kevin Mayfield (Jul 31 2019 at 16:41):
Not sure, I’m aware of a bit of kick back on profiling in the UK (observations was one of them)
Re slices - the ones I’ve seen have caused confusion and developers have tended to look at examples instead.
(I know that’s what developers do.)8888
Richard Townley-O'Neill (Jul 31 2019 at 23:55):
@Kevin Mayfield
Can you say any more about slicing that confuses rather than informs developers?
Kevin Mayfield (Aug 01 2019 at 07:12):
Its not really the slicing but these are sliced https://nhsconnect.github.io/FHIR-NEWS2/news2_and_subscore_profiles.html
Many developers I spoke to, 'couldn't see the wood for the trees' in the profiles, too much repitition and it took a little bit of time form the to work out what to extract (codes, valuesets, units, etc).
I don't know why they have SNOMED and LOINC slices, it could be international compatibility. I ignored them as I didn't have any way of implementing them (I was building a mock EPR not a terminology server). A plain language description might be better explaining use with other codesystems?
My main gripe is how complex definition of Observations is, compared to how they are going to be used: code, value, units, patientid and date.
Grahame Grieve (Aug 01 2019 at 07:30):
the LOINC/Snomed thing is for international compatibility, which really means consumer compatibility
Grahame Grieve (Aug 01 2019 at 07:31):
you'll note that HL7 implementation guides generally do have a narrative explanation of the profiles. The wood/tree thing is a challenge for any specification. We try to do both by having differential and snapshot
Kevin Mayfield (Aug 01 2019 at 07:56):
but we could be talking forests with Observations, not woods. The EPR systems I worked with in the late 90's had a huge amount of Observations.
Grahame Grieve (Aug 01 2019 at 07:57):
I'm not sure what your point is. Is that about the size of the instances? that's a different kind of problem
Lloyd McKenzie (Aug 01 2019 at 15:01):
If you validate against the profiles, that should also yell at you and tell you where you're non-conformant. (Ignoring the LOINC bindings in vital signs means you're non-conformant not only with the UK profiles but with the base FHIR specification.)
Grahame Grieve (Aug 01 2019 at 22:05):
ok. so. here's a draft rendering of a pattern value in the diff:
Grahame Grieve (Aug 01 2019 at 22:06):
Grahame Grieve (Aug 01 2019 at 22:06):
and in the snapshot:
Grahame Grieve (Aug 01 2019 at 22:06):
Grahame Grieve (Aug 01 2019 at 22:07):
Comments welcome (e.g. @Eric Haas @Lloyd McKenzie )
Lloyd McKenzie (Aug 01 2019 at 22:17):
The lock icon implies that patterns are locked down more than they are. Perhaps change "As shown" to "At least the following"
Eric Haas (Aug 01 2019 at 23:02):
Looks good to me
Rob Hausam (Aug 01 2019 at 23:58):
It would be good to see a full real example, but this seems to be looking pretty good.
Shovan Roy (Aug 02 2019 at 00:21):
Looks good to me ..
Richard Townley-O'Neill (Aug 02 2019 at 04:29):
@Kevin Mayfield
Its not really the slicing but these are sliced https://nhsconnect.github.io/FHIR-NEWS2/news2_and_subscore_profiles.html
The profile https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-BloodPressure-Observation-1 slices code.coding with a discriminator of code, but I expect they want to discriminate on system
Kevin Mayfield (Aug 02 2019 at 07:54):
@Lloyd McKenzie yes it won't be conformant but will many EPR's support multiple code systems? Most I'm aware of only have one main codesystem, they may convert to snomed but to another (that won't be used and is just for conformance - it's not causing problems with validation as the validator doesn't support LOINC)
Diego Bosca (Aug 02 2019 at 08:17):
Which example is this?
Lloyd McKenzie (Aug 02 2019 at 14:21):
The FHIR validator should yell if the slices aren't satisfied. If the system doesn't provide a LOINC translation (for the 10ish profiled vital signs) then the instance is not conformant with FHIR. The expectation is that implementers will perform translation (hard-coded translation if need-be) to ensure the correct LOINC codes are in place. That allows a critical amount of cross-border interoperability.
Chris Moesel (Aug 05 2019 at 14:14):
@Grahame Grieve -- your proposed rendering scratches my itch. I think I could be convinced to switch CIMPL over to export patterns if you implement this in the publisher.
Grahame Grieve (Aug 05 2019 at 14:15):
It’s implemented. So have a play
Kevin Mayfield (Aug 07 2019 at 11:02):
Is cross border critical? Sounds like a 'nice to have' rather than mandatory, getting data exchanged locally or even nationally should be a higher priority.
Lloyd McKenzie (Aug 07 2019 at 14:21):
HL7 is an international standard. We strive for international interoperability in those places where the operation of the healthcare system is sufficiently consistent and is within the capabilties of the global implementation community. For many patients, cross-border is critical. And for many implementers, reduction in variation across borders simplifies implementation (which in turn reduces costs for everyone). Requiring interoperability always imposes a cost - someone, somewhere must right extra code, have instances that are a little larger, must spend a few more hours doing mapping, etc. However, interoperability also reduces costs in other areas. The standards process strives to find a balance. If we stay too far one way, the standard gets ignored and isn't implemented. If we stray too far the other way, the standard provides no benefit. Mandating a based level of interoperability for things like vital signs, administrative gender, condition status, etc. has not been without controversy. However, so far, the community as a whole has said that the costs are low enough and the benefits are high enough that it's a reasonable and achievable imposition.
There are other areas where we'd love to have interoperability where the scale of the work would just be too large - we can't expect all implementers to map all lab codes or all procedure codes. There are too many and they're just too dynamic. And some concepts (e.g. billing codes) are too varied due to culture, business convention and politics to have any hope of even national interoperability in many cases, let alone international consistency.
So - we do what's achievable and the combination of connectathons, implementation and ballots provide the feedback loop about whether we're doing it right.
Kevin Mayfield (Aug 07 2019 at 15:08):
I can understand that but why LOINC? I know for some Observations, LOINC has codes and SNOMED doesn't - Is that the reason.
I will experiment automating the conversion but it seems wrong I would do this on an mobile (vital signs) app and seems to be a task for a backend system.
Lloyd McKenzie (Aug 07 2019 at 15:57):
LOINC is freely available to everyone and had appropriate codes for the relevant concepts. SNOMED was never on the table because of licencing issues. (It's possible these could have been managed with work with SNOMED International, but there was little incentive to do so given that LOINC required none of that and was fit for purpose.)
Grahame Grieve (Aug 07 2019 at 21:45):
vital signs are special because in the next few years, we are going to have a deluge of exchange between patients and their devices and the clinical system, and the consumer eco-system is not jurisdictionally bound. Also, fixing a single code is achievable. There will be pressure to solve this problem for other things - glucose measurement,s particularly, but we haven't taken that on yet
Shovan Roy (Aug 07 2019 at 23:27):
@Lloyd McKenzie , as discussed in this thread, I've created a tracker item requesting Vital Sign profile using pattern. https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=23070&start=0
Kevin Mayfield (Aug 08 2019 at 08:16):
The workaround is to not use the intended profile, so for heart rate (and all other Observations) I would use https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-Observation-1 The reason for doing this is my EPR only supports one code per observation (and it would be extra overhead to decide which profile to use depending on the codes being returned).
However that leads to question: Is the results returned here wrong? They validate against the profile being used BUT it is not a vital sign (child) profile https://data.developer.nhs.uk/ccri-fhir/STU3/Observation?code=364075005
Lloyd McKenzie (Aug 08 2019 at 08:54):
That's not an option if you want to be FHIR conformant. If you have an Observation that uses a code from ANY code system and the system generating the Observation recognizes the code system (i.e. You're not converting OBXs from some source where you have no clue what any of the codes mean), then you SHALL comply with the relevant vital sign profile if the code corresponds to a concept covered by one of the profiles. Incurring the overhead is not optional. Comply with the profile or you can't call your system FHIR compliant.
Kevin Mayfield (Aug 08 2019 at 09:37):
I'm not coming from a v2 perspective, in the 90's had (and still do) primary care systems that supported many thousands of different read coded Observations (most now also support SNOMED).
It's an option these systems can also support LOINC, they can choose to support code conversion on the feeds, they can choose to support LOINC on the data they return but that's going to be a binary choice they either do or don't support LOINC for all(/most) Observations
I've converted a couple of US SMART on FHIR apps from LOINC to SNOMED, it was trivial compared to changing the backend to support multiple code systems. So I'm inclined to believe that conversion in the client rather than server is a lot easier and more practical.
David Hay (Aug 08 2019 at 18:06):
I think what Lloyd is saying is that the existence of the Vital Signs profile as a 'core' profile in the spec means that the observations that are covered by that profile (height, weight, blood pressure etc) SHALL be compliant with that profile to be FHIR compliant...
Lloyd McKenzie (Aug 08 2019 at 18:52):
If those systems are going to migrate to FHIR, they'll have no choice but to make an adjustment to how they process vital signs. Feel free to make ballot comments around the next release of FHIR - but for FHIR R4, there's no wiggle room. (And many of us will argue strongly against allowing wiggle room in R5+)
Richard Townley-O'Neill (Aug 09 2019 at 05:42):
Kevin
Think of the LOINC codes for vital signs as FHIR-specific codes that flag certain types of observation.
Being LOINC codes does help those who understand LOINC, for the rest they are part of the FHIR structure that is added on creation and ignored on consumption. There is no need to process them as LOINC, just as magic values.
Kevin Mayfield (Aug 09 2019 at 08:28):
I don't mind the resources having LOINC but I do have issues with it being mandatory.
In the UK we had a similar issue with a mandatory patient identifier (English NHS Number), it meant the standards (mostly HL7v3) couldn't be used in several countries (Wales, Scotland and Northern Ireland) and certain care settings (emergency care). In FHIR it's not mandatory, so it can be used across borders (if a system doesn't understand it, it can ignore it and not persist it). In Scotland you would tend to use CHI number in place of NHS Number, you wouldn't expect NHS Number queries to work.
Likewise in the UK, LOINC can be used and be safe for certain interactions BUT don't expect it work for other interactions (if your working with a SNOMED/ICD9/ICD10/read4-5 system, use the native coding system for queries).
Lloyd McKenzie (Aug 09 2019 at 08:46):
Mandating a standard code to identify key vital signs regardless of where in the world the data was collected doesn't prevent instances from being used anywhere. It does impose a cost on implementers, but provides considerable benefit in terms of interoperability. All standards make mandatory impositions on implementers. The choice of what is mandatory and what is optional reflects a cost/benefit analysis.
Kevin Mayfield (Aug 09 2019 at 09:12):
Ok, so were are arguing similar points but I'm seeing LOINC as a barrier to adoption of FHIR. The requirement to support both LOINC (for international compatibility) and SNOMED (for UK clinical use) for Observations is a big one. In addition the support for different profiles for specific LOINC or SNOMED code is another burden.
As a developer: one codesystem and one profile for Observations would be desirable. Especially on older (primary care) systems which tend to follow the core FHIR Obs model, rather than newer ones which may lean towards HL7v3 and FHIR profiling models (I don't know about non UK primary systems but UK ones tend to lean more on CodeSystems (hierarchies) rather than lists or valuesets).
Grahame Grieve (Aug 09 2019 at 09:42):
you don't need to "support" LOINC. you just need to put a magic flag on the relevant observations. The idea has attracted fierce dislike in only one country... UK
Grahame Grieve (Aug 09 2019 at 09:43):
but from my pov it's not realistic to think that there can be only one code on all observations.
Richard Townley-O'Neill (Aug 12 2019 at 02:05):
FHIR mandates codes from http://hl7.org/fhir/administrative-gender for Patient.gender and from http://hl7.org/fhir/ValueSet/address-type for Address.type.
Most systems have other codes for these things, and do not natively use the FHIR mandated codes.
I think of the LOINC codes used to indicate which type of observation a vital sign is as being the same sort of thing.
Kevin Mayfield (Aug 12 2019 at 08:06):
@Richard Townley-O'Neill a modelling first approach is acceptable in a number of areas, like the ones you've mentioned.
It's an approach we've used in the UK for secondary/acute care however those systems didn't get to the level of maturity our primary care systems did.
However I think it's possible to decouple compliance (layer) [which would do codeSystem and profile conversions] from implementation (layer), so still retain the advantages of CodeSystem first approach (development velocity).
That seems like the correct approach as it copes with retro fitting profiles. e.g. in UK heart rate profile didn't exist a year or so ago but heart rate observations did (as FHIR SNOMED examples) but then we had a heart rate profile six or so months later.
It will have issues around coded Observations when a valueCodeable concept is not in the ValueSet. These issues are going to exist anyway with historic Observation rich data sources.
Lloyd McKenzie (Aug 13 2019 at 04:10):
Implementations should not complain about unrecognized Codings so long as a recognized Coding is present. Complaining because of extra codes forces a custom interface for each receiver - precisely the opposite of what we're trying to achieve.
Kevin Mayfield (Aug 14 2019 at 14:51):
No, I'm complaining that this is making moving both to FHIR and Coded Observations difficult.
The layering (or microservice) is implied by mandatory LOINC, it is exactly what happened when SNOMED became mandatory on UK READ based systems.
Lloyd McKenzie (Aug 15 2019 at 01:38):
It's always easier to send whatever you like. Interoperability inevitably is more difficult.
Eric Haas (Aug 19 2019 at 18:34):
(deleted)
Eric Haas (Aug 19 2019 at 23:36):
I have been converting US Core from fixed to patterns and two issues came up...
1. the way it is rendered by using the slice name may confuse the reader into thinking there an a <slicename> element if they don't immediately recognize it as a slice name of the "parent" element. I added "Slice" to all my prettified slice names to make it obvious. I think this is something the tooling should do like adding "(Slice)" after the slice name. here is my diff to illustrate:
pasted image
Eric Haas (Aug 19 2019 at 23:41):
2. I discovered that can't mix n match fixed with pattern. I tried to use pattern for the code in the above and the tool complains because the base vitals profile uses fixed. I guess that is what all the fuss was about in the first place.
Here is the message:
Unable to generate snapshot for http://hl7.org/fhir/us/core/StructureDefinition/us-core-pulse-oximetry: Slicing rules on differential (org.hl7.fhir.r5.model.ElementDefinition$ElementDefinitionSlicingDiscriminatorComponent@76111797(/open)) do not match those on base (org.hl7.fhir.r5.model.ElementDefinition$ElementDefinitionSlicingDiscriminatorComponent@304cc1dd, org.hl7.fhir.r5.model.ElementDefinition$ElementDefinitionSlicingDiscriminatorComponent@2ee9814f(false/open)) - disciminator @ Observation.code.coding (http://hl7.org/fhir/StructureDefinition/oxygensat)
Eric Haas (Aug 19 2019 at 23:42):
3. patterns are only marginally easier than using Fixed Codes (maybe because I only used fixed until now)
Michel Rutten (Aug 20 2019 at 08:43):
Hi @Eric Haas, Forge renders slices similar to your illustration. Wondering if this is causing confusion and if/how we can improve this.
We could clarify slice rendering using "{elementName}:{sliceName}", e.g. "component:FlowRate". Repeating the element name would provide a more explicit visual connection to the associated slice entry and sibling slices. It does claim more horizontal screen space, which can introduce other challenges (esp. cut off).
Named slices could also be decorated and highlighted using a special icon, like in Forge.
Patrick Werner (Aug 20 2019 at 11:52):
@Grahame Grieve could the rendering of a pattern on coding been improved by actually linking to the fixed System?
Eric Haas (Aug 20 2019 at 13:24):
@Michel Rutten Personally, I prefer the "{elementName}:{sliceName}" over the icon which could be easily overlooked but I see the problem with length. maybe my problem is using element like names and instead standardized on use a short non descriptive slice iteration like 's1' so is
"{elementName}:{sliceName}" becomes for example Coding:s1, Coding:s2. I guess the underlying problem I am trying to solve is how to display the slicing in the tree expecting the naive reader to intuitively know what it means . I don't even know if that is possible.
Eric Haas (Aug 20 2019 at 13:27):
perhaps change icon from a barrel to a full pie with slices and for each slice a slice of pie?
Michel Rutten (Aug 20 2019 at 13:50):
perhaps change icon from a barrel to a full pie with slices and for each slice a slice of pie?
Originally Forge used pie/chart icons to represent slices, however this also seemed a bit far fetched. In recent Forge releases, named slices are decorated with a bucket icon, to reflect the notion of a slice bucket. Seems a _slightly_ better visual metaphor, assuming the user is familiar with the concept of a slice.
Michel Rutten (Aug 20 2019 at 13:51):
(as a validator will try to match elements in an instance to "slice buckets" in the profile)
Michel Rutten (Aug 20 2019 at 13:53):
BTW I think that nesting named slices as children of the associated slice entry clearly indicates the relationship between them, more so than displaying named slices as siblings of the slice entry.
Eric Haas (Aug 20 2019 at 14:02):
I don't understand how a bucket reflect the notion of a slice? I think of a slice of pie or pizza or bread.
Eric Haas (Aug 20 2019 at 14:03):
and I am assuming the user is not familiar with the concept of slice.
Eric Haas (Aug 20 2019 at 14:09):
I think I finally realized what that barrel thingy icon is supposed to be - a stack of discs....
Eric Haas (Aug 20 2019 at 14:10):
if we stick with that metaphor then the icon for each slice would be a disc
Michel Rutten (Aug 20 2019 at 14:21):
Forge represents a slice entry with an icon of a stack of sheets and a named slice with an icon of a bucket. If you try to think about how slices are processed (which is their primary _raison d`être_), then the bucket metaphor makes perfect sense, more so then a silly pizza slice.
Michel Rutten (Aug 20 2019 at 14:25):
BTW I try to refrain from designing my own icons - way too hard. Instead, I try to use suitable free (vector) art from some online icon libraries. Unfortunately, the graphic designers are not aware of slicing... ;p
Josh Mandel (Aug 21 2019 at 15:22):
I am 100% on board with the concern here. I'm looking at things like:
and thinking to myself, "wait, is there an assessplan element in the JSON?" Nobody is going to be able to understand this.
Eric Haas (Aug 21 2019 at 15:27):
I updated that to :
Josh Mandel (Aug 21 2019 at 15:28):
I just see assessplan changed to AssessPlanSlice. The overall layout/presentation is still the same, so I still have the same basic issue of: "is this represented as an element in the JSON"?
Eric Haas (Aug 21 2019 at 15:31):
in the latest Argonaut R4 will be merging over.... I added "Slice" to every prettified slice name for now...as a temp solution... this rendering is very new and Grahame did it to make it easier to read and its a big improvement ( thanks GG ) but I think the challenge is to make easy to understand for the naive reader who is not slicing expert.
Eric Haas (Aug 21 2019 at 15:34):
So it sounds like Coding:<slicename> or Coding:<slice N> or something would be better as Michel suggested.
Eric Haas (Aug 21 2019 at 17:11):
like this?...
pasted image
Grahame Grieve (Aug 21 2019 at 19:41):
there's a certain irony here... we changed it after a discussion to make it easier to understand, but not everyone is finding it easier...
Eric Haas (Aug 21 2019 at 19:50):
I think its better - but just needs a few tweaks. slicing in not easy to understand and trying to represent it visually is a challenge I think you did pretty well actually.
Grahame Grieve (Aug 21 2019 at 19:52):
I'll play around with it tomorrow
Eric Haas (Aug 21 2019 at 19:52):
only issue is the name slice - I think the <element>:<slice-name> is better and the root still does not display the cardinality
Josh Mandel (Aug 21 2019 at 19:54):
Nesting levels is another issue: the slices shouldn't be drawn with an extra level of nesting, since the property-hierarchy/JSON/XML serialization doesn't have an extra level of nesting.
Grahame Grieve (Aug 21 2019 at 19:55):
hah that was the change everyone asked for
Josh Mandel (Aug 21 2019 at 19:56):
Whelp. I wonder if we could do some real-world user testing on this.
Grahame Grieve (Aug 21 2019 at 19:57):
I wonder too. you have the best resources for that
Eric Haas (Aug 21 2019 at 20:12):
I disagree with Josh - I think is easier for the reader to understand in the current layout since a slice is a part of the whole. I don't think it needs to mirror the serialization.
Chris Moesel (Aug 21 2019 at 20:53):
@Eric Haas -- I don't think your example slicename in the screenshot above (Coding:AssessPlan) is quite right. It's the category that's being sliced (which is a CodeableConcept, not a Coding) -- so it should be CodeableConcept:AssessPlan.
That said, if we were going to move toward that type of format, I think I might prefer category:AssessPlan -- as it might make it clearer that it's the same level as category (to maybe address Josh's concern), and it is more consistent with how slicenames are serialized into the id (for the nerds like us who know those technical details).
Grahame Grieve (Aug 21 2019 at 20:55):
we can just start with :
Eric Haas (Aug 21 2019 at 22:23):
Thanks @Chris Moesel I was a bit too quick and dirty with that. but My concern isn't for us nerdy types who are in the weeds but for the casual reader who needs to understand what it means without having written a profile. so whatever we do should make sense to them.
Eric Haas (Aug 21 2019 at 22:25):
i'll try using Chris' excellent suggestion
Eric Haas (Aug 21 2019 at 23:32):
Kevin Mayfield (Aug 22 2019 at 07:56):
(I know I went of on a tangent earlier in the thread). That representation is quite clear and understand better what you're intending to achieve.
Michel Rutten (Aug 22 2019 at 09:23):
@Josh Mandel
Nesting levels is another issue: the slices shouldn't be drawn with an extra level of nesting, since the property-hierarchy/JSON/XML serialization doesn't have an extra level of nesting.
Forge has always represented named slices as children of the associated slice entry. I don't think that a visual rendering MUST be a 1-1 representation of the underlying xml/json serialization; instead, we should try to provide a human-friendly representation. Different serialization formats have slightly different internal structures, visual rendering should abstract those away and show the common conceptual model.
That also explains why Forge displays extensions at the bottom; conceptually this makes more sense to me, as the extension element is "appended" to the base profile. The fact that extensions in the actual serialization are listed at the top is just an internal implementation detail that IMHO modelers shouldn't have to worry about.
I think rendering named slices as "{elementName}:{sliceName}" is quite explicit. And the nesting level clearly shows the conceptual relationships of the slicing constraints. Named slices inherit common constraints from the associated slice entry, so there is a notion of an hierarchical relationship.
Lloyd McKenzie (Aug 22 2019 at 12:22):
The core spec used to put extensions at the bottom too, but we had lots of questions from implementers who were then confused about why they had to appear at the top in instances.
Michel Rutten (Aug 22 2019 at 12:35):
Yes, initially when there was no tooling available, the early adopters were forced to work with low-level XML/JSON, and both formats have their peculiarities. However I'd prefer to hide such details internally. Conceptually, there is no reason that custom extensions should be listed _before_ standard elements.
Does ProtoBuf also introduce extensions first...?
Josh Mandel (Aug 22 2019 at 13:07):
I'm not saying that nesting is necessarily wrong -- just that it leads me personally to be confused and it would be nice to understand more about this.
Michel Rutten (Aug 22 2019 at 13:30):
Considering that named slices inherit common constraints from the associated slice entry, conceptually there is a parent-child relationship. This relationship is similar to, but different from, child elements. We are trying to represent both concepts by indentation and this may cause confusion. In a way, slicing represents a separate dimension. However I'm somewhat reluctant to implement 3D tree visualizations...
Rendering named slices as child elements also allows a visitor to collapse the whole slice. This can be quite convenient, e.g. for a (Composition) profile with a large number of slices.
Nesting named slices also makes sense in Forge. A flattened view would complicate the UI.
Josh Mandel (Aug 22 2019 at 14:31):
However I'm somewhat reluctant to implement 3D tree visualizations...
;-)
Michel Rutten (Aug 22 2019 at 14:38):
Would be fun to code, I'm sure, but probably just adds to the confusion...
Eric Haas (Aug 22 2019 at 14:40):
I like the last one I made: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Fixed.20Code.20vs.20Pattern/near/173840967
the best and think we should go with that one.
Lloyd McKenzie (Aug 22 2019 at 16:02):
I don't like the 'lock' icon when we're dealing with 'pattern' because it's not truely fixed values. But fine with that otherwise.
Grahame Grieve (Aug 23 2019 at 01:17):
catching up on this thread:
Considering that named slices inherit common constraints from the associated slice entry,
That's not entirely true :-(
Grahame Grieve (Aug 23 2019 at 01:27):
ok, how about this (@Eric Haas @Lloyd McKenzie @Michel Rutten @Chris Moesel @Josh Mandel ):
pasted image
Lloyd McKenzie (Aug 23 2019 at 02:29):
If that's a pattern, then I'd rather you say "Pattern" rather than "Fixed value". If it was a fixed value, then having an 'id' or extension on the system or code would be prohibited. However, if it's a pattern, then including those things is fine. It's a subtle distinction, but I think it matters.
Grahame Grieve (Aug 23 2019 at 02:30):
I don't know what that is. I'm just owrking on slicing rendering
Lloyd McKenzie (Aug 23 2019 at 02:30):
What do you mean when you say "that's not entirely true"? Slices absolutely inherit the constraints of the parent. The only exception is minOccurs, which can be less as it's a constraint that must be met by the slice collection as a whole.
Lloyd McKenzie (Aug 23 2019 at 02:31):
Don't know what 'what' is?
Grahame Grieve (Aug 23 2019 at 02:31):
whether it's a pattern or a fixed value - I haven't looked at that particular profile details. I'm just working on it as the first example of slicing I found
Grahame Grieve (Aug 23 2019 at 02:32):
Slices absolutely inherit the constraints of the parent
Almost. When you have a slice in a parent profile, and you define another profile, the parent of the slice is the slice in the parent, not the slicing element that contains the slice in the child
Lloyd McKenzie (Aug 23 2019 at 02:33):
True, but the constraints of the slicing element that contain the child still apply
Eric Haas (Aug 23 2019 at 03:43):
Yes I think the icons are better and having the cardinality there is certainly helpful. thx.
Michel Rutten (Aug 23 2019 at 08:59):
the parent of the slice is the slice in the parent
LOL... I guess we could say "the base of the slice is the (matching) slice in the parent"
Chris Moesel (Aug 23 2019 at 12:10):
LOL... I guess we could say "the base of the slice is the (matching) slice in the parent"
Yeah. Good thing this stuff's not complicated at all. ;-)
I like the new rendering, @Grahame Grieve! The slice is actually a little slice of the barrel thing. I think it works!
Josh Mandel (Aug 23 2019 at 13:41):
Agreed -- this rendering proposal is a definite improvement! The icons and the repetition of the element name for each slice helps reinforce the structure for me
Josh Mandel (Aug 23 2019 at 13:41):
Thanks for putting this together!
Michel Rutten (Aug 23 2019 at 13:43):
Great, I will harmonize rendering in Forge.
Grahame Grieve (Aug 23 2019 at 20:54):
Michel - the slice icon can be found at http://www.fhir.org/archive/icon_slice_item.png
Michel Rutten (Aug 26 2019 at 08:30):
Thanks! But as Forge uses vector icons, I will try to improvise something vaguely similar :wink:
Pete Salisbury (Sep 02 2019 at 08:55):
This is a really interesting thread and I have found it helpful as I've been trying to understand the vital signs requirements and what needs to be done in order to be compliant. I think that the snip from Graham makes the slicing profile clearer.
One thing that I do still find a little confusing though is in how the slice is described for code in the vital signs profile. @Richard Townley-O'Neill asked if the profiles that @Kevin Mayfield quoted should have been sliced on system rather than code.
"The profile https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-BloodPressure-Observation-1 slices code.coding with a discriminator of code, but I expect they want to discriminate on system"
To me this makes sense as then if following the slice there was a SNOMED code it could have a wider possible valueset which seems to be in line with what is intended. For example for blood pressure it would have a Loinc slice with the code 85354-9 followed by a SNOMED slice that may have a value for sitting blood pressure or standing blood pressure.
Would the above be correct or have I misunderstood?
Kevin Mayfield (Sep 02 2019 at 09:08):
?Do we move this out to UK or other thread.
That's an interesting thought. I'm not clear on how standing or sitting, if known, would be differentiated.
Michael Lawley (Sep 02 2019 at 09:12):
Note, LOINC free as in beer, not as in freedom; there are things that the LOINC licence prevents you from doing. Specifically: "users shall not use any of the Licensed Materials for the purpose of developing or promulgating a different standard for identifying patient observations"
Kevin Mayfield (Sep 02 2019 at 09:14):
Does that mean the UK needs to BREXIT? (sorry poor humour)
Rik Smithies (Sep 02 2019 at 10:24):
@Pete Salisbury Slicing on "SNOMED" wouldn't be that helpful in a BP observation profile I imagine. You would be ruling in thousands of unwanted codes. It is true that slicing on code limits you to one patient position, but I expect that in most cases that would be fine. The profile is meant to guide/enforce uses in the majority of cases. You could have other profiles for the less common cases but with diminishing returns.
I am not sure if you can slice on a value set (of several patient positions). But even if you can, BP is so basic I think you'd want to keep it as simple as possible. Those who know what they are doing can always go outside the profile and add codes for different positions and situations.
Pete Salisbury (Sep 02 2019 at 10:33):
@Kevin Mayfield the sitting and standing would be differentiated by different codes e.g. 163035008 - Sitting Blood Pressure
@Rik Smithies I'm working with the GP systems suppliers in the UK and they will have blood pressure readings associated with a number of codes. I think we would need to define a valueset in SNOMED and define this in our implementation guidance if as you say it is not possible to associate the slice with a valueset.
Kevin Mayfield (Sep 02 2019 at 10:54):
@Pete Salisbury my understanding is the read codes for BP would be converted to 75367002 and LOINC 85354-9 (and I would be sending you a question about standing and sitting conversions :) via the supplier)
Rik Smithies (Sep 02 2019 at 10:54):
Curious to know what amount are not just the basic systolic and diastolic with no patient position. I realise that other codes are available. Profiles only standardise the common things. Otherwise you replace thousands of codes with thousands of profiles :-)
Pete Salisbury (Sep 02 2019 at 12:28):
@Rik Smithies it is difficult for us to be able to tell what percentage would be recorded with a code other than the simple blood pressure. We are looking to be able to send records from all the GP systems in england so it is some 60 million records spread over 4 clinical systems that allow the data to be entered in different ways. I'm sure most will be under the simple BP code. I guess the question then is would we be non-compliant if we don't make sure the others are sent in the same format?
@Kevin Mayfield we could look to get the suppliers to map at their end and then put the original rubric in codableConcept.text. The spec does say,
'Other additional codes are allowed - e.g. more specific LOINC Codes, SNOMED CT concepts, system specific codes. All codes SHALL have an system value'
Which seems to suggest that it would be feasible to send the more detailed codes though?
Rik Smithies (Sep 02 2019 at 13:41):
@Pete Salisbury
The only point of profiles is to foster interoperability by making it easier to follow business rules.
imho profiles need to be simple, otherwise they won't help.
Don't try to cover all the edge cases if that means diluting the usefulness for the basics.
e.g. if by allowing extra, unusual, BP codes, you also allow lots of other non-BP codes to be used accidentally, that seems worse not better.
You can always send other data, outside of this profile. The data is the data, not the profile.
Michel Rutten (Sep 02 2019 at 13:48):
Postel's law comes to mind:
https://en.wikipedia.org/wiki/Robustness_principle
i.e. relaxed profiles on the receiving side and strict profiles on the sending side.
Kevin Mayfield (Sep 02 2019 at 13:55):
Agree with Rik. I'd never heard or seen sitting or standing BP codes (after 12+ years with a GP supplier) . It was only after starting to work more on standards in acute (I've never seen a BP code at all in 10 years of community and acute)
Peter Jordan (Sep 02 2019 at 20:43):
Don't try to cover all the edge cases if that means diluting the usefulness for the basics.
e.g. if by allowing extra, unusual, BP codes, you also allow lots of other non-BP codes to be used accidentally, that seems worse not better.
You can always send other data, outside of this profile. The data is the data, not the profile.
@Rik Smithies The Terminology Binding Group in the SNOMED on FHIR Project are working on a Vital Signs Profile using SNOMED CT concepts. Their approach for Value Set binding is to use query-based (intensional) Value Sets which cover both the 'basic' & less commonly-used concepts for blood pressure results, etc without including irrelevant concepts. Granted, the ECL queries are more complex than using fixed (extensional) lists, but they are more flexible (in terms of use across different SCT editions and versions) and use the grammatical power of a clinical ontology as opposed to a fixed classification system such as Read.
Rik Smithies (Sep 02 2019 at 21:11):
thanks @Peter Jordan sounds good. I'd like the profile to be simple to understand by people implementing it and for all the validators to be able to check against it. It may be good to have a "simple BP" profile, (e.g. 2 or 3 fixed codes) and a "complex BP" profile (ECL based etc) for those who feel the need for it.
Peter Jordan (Sep 02 2019 at 21:31):
@Rik Smithies that seems a good approach. For example, an IG for GP2GP might only require a "simple BP profile" (in fact, the NZ CDA IG for GP2GP contains only 3 SCT concepts for BP).
Richard Townley-O'Neill (Sep 03 2019 at 00:27):
@Rik Smithies @Pete Salisbury
@Pete Salisbury Slicing on "SNOMED" wouldn't be that helpful in a BP observation profile I imagine. You would be ruling in thousands of unwanted codes. It is true that slicing on code limits you to one patient position, but I expect that in most cases that would be fine. The profile is meant to guide/enforce uses in the majority of cases. You could have other profiles for the less common cases but with diminishing returns.
Slicing Observation.code.coding with a discriminator of code means that all instances with a code value of "75367002" must have a system of "http://snomed.info/sct". This implies that if the value "75367002" is a valid and relevant code in a different code system to SNOMED CT, it cannot be used. I expect that this is unintended, but it might not be a practical problem.
Rik Smithies (Sep 03 2019 at 00:30):
It can't be used in that profile, true. But that's the idea anyway I think. We want that code, from SCT.
Lloyd McKenzie (Sep 03 2019 at 02:02):
If you're going to slice by value, you should always discriminate by both code and system. (But slicing by pattern is easier.)
Kevin Mayfield (Sep 03 2019 at 05:31):
@Pete Salisbury has done some research on use of codes in UK primary care. What I could see was codes that:
- included context information (e.g. BP taken at home or in a ambulance)
- included body site
- different position (sitting/standing)
I'm wondering if these is a more recent trend in primary care, it was just (well at least 96%) a BP when I (and @Rik Smithies ?) worked on GP systems. I mean several years ago we mostly used 1 or 2 codes for BP.
As an API consumer, if I asked for the by BP vital signs codes (75367002 or LOINC), I would expect all the BP codes to be returned (inc child codes). However if I asked for ambulatory or home BP I would only expect those BP codes to be returned. (is the former the same as the ECL queries? @Peter Jordan ). [Don't believe using the vital sign BP codes in the Observation is necessary here, the code conversion is done in the query by the system that understands it]
Interactions between systems (primarily messaging) would need to hold the 75367002 BP and LOINC codes in the Observation. Endpoints can't be expected to understand the child codes, etc. [Conversion is done by the sender].
I'm a bit wary this is getting too complicated and it needs to be easily understandable by implementors. Having to go to a profile or ObservationDefinition to find the valueset and units, then a terminology service to expand the snomed ecl in the valueset to get code lists. Then the database to retrieve the data and finally a terminology service to perform code lookups within a codesystem and also conversion to another codesystem ..... is too complex.
Kevin Mayfield (Sep 03 2019 at 05:45):
@Pete Salisbury I'm currently working (in-directly) for a GP systems supplier. They have read to snomed functionality, I'm wondering about how to handle mapping profile+code from base to relevant vital signs profile+codes. In the ideal world I would suggest this is either a NHSD provided service or effort is pooled - it doesn't make sense for them all to produce the same conversions.
Grahame Grieve (Sep 03 2019 at 06:47):
I'm a bit wary this is getting too complicated
FHIR: easy to understand. Healthcare: complexity that keeps giving ;-)
Peter Jordan (Sep 03 2019 at 07:09):
@Kevin Mayfield Optimising the interactions between GP systems and terminology services is certainly a significant architectural challenge! Dynamic, in context, querying of SNOMED CT using ECL may become a popular approach, IF the associated presentation layer issues of usability and responsiveness are addressed. The one requirement that FHIR Terminology Service implementations appear to be struggling to meet is where properties, other than identifiers, descriptions and versions are required for all the concepts in a ValueSet.
Michael Lawley (Sep 03 2019 at 07:14):
In general, if you're after child concepts as well then FHIR search has the :below modifier. So, Observation?code:below=http://snomed.info/sct|75367002 will get you what you want
Pete Salisbury (Sep 04 2019 at 15:16):
@Kevin Mayfield Indeed from the figures that Jeremy Rogers provided for me you could see that over a year 2014-2015 it showed there were 700k standing BPs, 437k sitting BPs and only 173k plain BPs. So we need to work with some of these if we are going to get the data out.
It is also important to note and I'll quote Jeremy here " that in SNOMED a naively curated binding of the 'its a blood pressure' profile to e.g. 'all codes in SNOMED below 75367002 Blood pressure' would potentially have disastrous effects, because that tree includes e.g. 723236006 Minimum blood pressure as well as 315612005 Target systolic blood pressure, neither of which are statements of the patient's current 'vital sign' blood pressure reading. One of them is a statement of a pressure you'd like them to have."
There has been some work done on this already by the SNOMED on FHIR group that takes this into account for systolic and diastolic bindings that is published here,
https://confluence.ihtsdotools.org/display/FHIR/Vital+Signs+panel+binding
In our situation I think it makes more sense to carry the more detailed codes where possible. That way consumers can decide if they want to ignore the detail and use a high level code or to use the detail.
Apologies, realise I am now some way off topic but thought that the link might be useful.
Rob Hausam (Sep 04 2019 at 15:38):
Yes, SNOMED on FHIR has been working on this, including working toward a FHIR IG that will contain the guidance. I agree with retaining the detailed codes, which can (and should) be sent along with any other codes that are specifically required for conformance to the profile(s).
Kevin Mayfield (Sep 04 2019 at 17:33):
I’m not sure having two snomed codes in a resource is going to work. If it’s a standing BP then it’s a standing BP (uk base profile) not a vital sign BP.
A standard Api could query BP using all the codes it’s after (a list). In many cases the difference in profiles won’t be necessary in a client app.
Kevin Mayfield (Sep 04 2019 at 17:34):
Correction - won’t be noticed.
Lloyd McKenzie (Sep 04 2019 at 18:28):
Having multiple SNOMED codings for a single element is certainly legal and there are cases where it makes sense to do so. (Whether you choose to do so is a different matter).
Grahame Grieve (Sep 04 2019 at 20:50):
Having multiple SNOMED codings for a single element is certainly legal
Absolutely, but that doesn't change the fact that it's tricky. If you have the magic LOINC value that says "I'm a BP" and a snomed code 123456789 that says "I'm a standing BP done by X while the nurse was on drugs in the back of an ambulance" (or whatever), then you can easily differentiate between the 2 codes and know which you want to use.
But if the Obs contains 2 different snomed codes 123456789 and 987654321, then you actually have to consult snomed and figure out which one you want to use.. that's both time consuming and semantically challenging. I think that's the point of what @Kevin Mayfield is getting at
Kevin Mayfield (Sep 05 2019 at 05:57):
Exactly. Putting semantic rules into the profile is going to lead to difficulties with BA's and developers trying to implement the profiles. At a restful level you don't need a deep understanding of semantics (and even FHIR), I can easily tell a developer if they want to query for BP they should use Observation?patient=1234&code=1234567890,9876543210 or even Observation?patient=1234&code={magiccode or ecl}
Kevin Mayfield (Sep 05 2019 at 05:59):
note: I don't agree with using ecl at the moment, the UK doesn't have an operational way of resolving them.
Michael Lawley (Sep 05 2019 at 10:20):
@Kevin Mayfield I think you're confusing ECL (which is a mini query language) with PCG (the post coordination grammar) that is used to construct snomed expressions (eg to say fracture of left leg)
Kevin Mayfield (Sep 05 2019 at 10:26):
nope, you ruled out pcg in a previous reply. Reworded: Searching on a list of SNOMED codes (i.e. ValueSet which is defined by an ecl expression).
Michael Lawley (Sep 05 2019 at 10:36):
my mistake :)
Kevin Mayfield (Sep 05 2019 at 10:41):
:) no worries. This topic is worrying me a lot.
I think it's fair to say in the UK we have GP systems using a lot of SNOMED/Read codes, of the others probably key/value pairs are most common with some new entrants following the vital sign profiles.
Most of the others will not be familiar with coding systems, maybe ICD9/10 but not SNOMED.
So I would suggest caution with use of ecl, pcg and terminology services.... maybe a path that brings people along that route?>
Grahame Grieve (Sep 05 2019 at 10:44):
Terminology services are definitely a tool that everyone should have as part of their bag of tricks. They haven't been practical until now, so now we have to endure the adoption cycle. I counsel government decision makers to accelerate that as best they can right now.
But terminology services are not the solution to the problem, only part of the solution. In the end, however you organise the deck chairs, real interoperability requires considerable work, some of it in integration code, some of it in the source products, and some of it in people's heads
Michael Lawley (Sep 05 2019 at 10:44):
This is a topic that would best be moved to #terminology I think
Richard Kavanagh (Sep 05 2019 at 12:32):
Exactly. Putting semantic rules into the profile is going to lead to difficulties with BA's and developers trying to implement the profiles. At a restful level you don't need a deep understanding of semantics (and even FHIR), I can easily tell a developer if they want to query for BP they should use Observation?patient=1234&code=1234567890,9876543210 or even Observation?patient=1234&code={magiccode or ecl}
There is an operational way, just not a "national" operational way...
John Silva (Sep 05 2019 at 13:14):
And then you have meta-thesaurus like the (US) NLM's UMLS that try to bridge (cross-correlate) multiple disparate coding systems: https://www.nlm.nih.gov/research/umls/knowledge_sources/metathesaurus/index.html
BTW. Back a while ago there was a great article about coding systems and the pre vs. post coordination problem that happens in coding systems. This paper was in the JAIMA in 1999, but is still relevant today. This article used to be on HIMSS website, but is no longer there but a copy of it is available on the Internet Archive here:
https://web.archive.org/web/20030902215601/http://www.himss.org/content/files/jhim/13-3/him13309.pdf
[This should definitely be moved to the #terminology thread ;-) ]
Kevin Mayfield (Sep 05 2019 at 13:57):
There is an operational way, just not a "national" operational way...
DELETED for being too honest :)
Last updated: Apr 12 2022 at 19:14 UTC
