[Procedure / General] Postcoordination VS SupportingInfo on procedure (?) - revision value

[annabel-uzl]

Hi, I'm wondering how to put Re-Procedures in FHIR. I'm talking about a 'revision' of a procedure. In SNOMED this could be done using the qualifier value e.g. 41453009 |Strabismus surgery (procedure)|: 246513007 |Revision status| = 255231005 |Revision - value (qualifier value)| could reference to the re-procedure of strabismus (using 261425000 - Second revision e.g.). Or with the labeling << 255231005 |Revision - value (qualifier value)| OR << 257958009 |Part of multistage procedure (qualifier value)| OR << 261424001 |Primary operation (qualifier value)|) one could reference to a primary procedure or a multistage procedure But how does this fit in FHIR? I thought about misusing the reasonCode by adding the qualifier value - code to it, but this feels illegal. Any suggestions?

This question is now focused on revisions but I think this can be extended to adding other details. This question is also in the context of an FPS Health datacapabilities project (KWS FHIR)

[bdc-ehealth]

@mlambot, @annenerenhausen

Marie-Alexandra, Anne, there are other people, besides @LionelCremer, who are interested in starting to use post-coordination on a Belgian level. We really need a general approach to these questions. Sadly, we could not discuss this on the Validation Team meeting today.

[costateixeira]

I think the first thing would be to evaluate whether/where there is a need for post-coordinated expressions. Some requests may be actually end up being handled in some other way.

So I recommend avoiding post-coordinated expressions in the key elements of the interfaces, unless there is no FHIR alternative.

[annabel-uzl]

I think it would be handy indeed to have an overview of requests where we might need post-coordinated expressions. Another one I'm thinking about is laterality. Idk if that might be discussed already, but when you do a Procedure at a certain body part denoted in the bodySite field, but that code does not contain the laterality, do you add the code for laterality as an extra bodySite value or is this also something that might be handled using post-coordinated expressions or do we use an extension or ...

[bdc-ehealth]

@annabel-uzl ,

for laterality, we have an extension on the Belgian level.

For post-coordination in general, you might also want to read this thread: https://chat.fhir.org/#narrow/stream/179202-terminology/topic/Searching.20for.20postcoordinated.20code.28fragements.29 It will make clear to you that post coordination is not very supported on an international technical level either.

[annabel-uzl]

@bdc-ehealth thanks I understand why post coordination is not the way to go, and I wouldn't want to use it either. I'm just wondering on how do solve certain cases. But I completely agree with @costateixeira on trying to avoid post-coordinated expressions at all times.

[mlambot]

It is almost impossible to draft general rules about the use of postcoordination because where to put the cursor between pre and postco depends on the circumstances. Regarding procedures, we have to decide such questions as to where to specify if it is a primary or revision procedure when we discuss the Procedure Care Set because this "qualification" or metadata we want to add the central core meaning of the SNOMED procedure concept can be put either in the terminology or in the data model with advantages and disadvantages in both. It has to be a decision taken based on the needs of the users and taking in consideration what exists in SNOMED CT, the maintenance loads and risks of both approaches. Other qualifiers or metadata must be considered too. Frequency has a role to play.

If the nuance of primary vs revision touches just about 100 concepts like hip interventions or hernias, then you'd better put the nuance in the terminology. If near all procedures can be primary or revision (which is not the case medically), then you should put it in the data model.

If I look at SNOMED CT, the specification exists as precoordinated concepts for some procedures like this 112727005 |Revision of hip replacement| and is modelled like that

=== 280460009 |Revision of hip arthroplasty (procedure)| + 448972009 |Revision of prosthetic replacement of joint (procedure)| : { 246513007 |Revision status (attribute)| = 255231005 |Revision - value (qualifier value)|, 260686004 |Method (attribute)| = 129284003 |Surgical action (qualifier value)|, 405814001 |Procedure site - Indirect (attribute)| = 24136001 |Hip joint structure (body structure)|, 363699004 |Direct device (attribute)| = 67270000 |Hip prosthesis, device (physical object)| }

If revision procedures are missing that are commonly needed at national level, the creation of those concepts can be asked to the BE NRC (first). The NRC can (then) forward this demande to SNOMED international, because it's unlikely only Belgian surgeons do revision for those procedures and so eventually, the few missing concepts can find their way so to the international Edition.

But there are clinical questions to ask too. What do you call a revision of strabismus surgery? Maybe the concepts already exists but with another procedure name, it's own intervention name of what you actually do as "revision" (move a muscle, stitch something ) and the notion that this procedure on this eye occurs after a first other intervention has to be captured in the timeline of the patient disorder history about this eye disorder in the "based on" link, where you can see why a procedure was performed. Or through a special link between the two procedures. I've already proposed in the Problem care set preliminary study that we should be able to link problems with problems, problems with procedure (and reverse) and yes, maybe procedures with procedures then with qualifiers for these links in the data models.

@bdc-ehealth no question here regarding SNOMED CT should be answered without the BE NRC to be at the very least aware of it. You can try to be helpful and provide answers to users as fast as you can, we can try to help you in that, José can too, but the BE NRC is the authority in charge of Terminologies en Belgium.

@annabel-uzl you should submit each use-case for postco separately I believe because the answers will likely be different in each case. The question of laterality as things are, was already addressed in previous Care Set data modelling (vaccination). Adding to this SNOMED international has moved toward creating almost all concepts that can be lateralized as precoordinated now opposed to their initial historical position which was to add them only "on demand".

[annabel-uzl]

@mlambot thank you for your extensive answer :) I agree on looking at it case-by-case so I'll focus this message on my initial question about the revision attribute (and I changed the title).

At this point it feels too soon to go ask the NRC for the creation of extra concepts regarding the revision of procedures. If we would do that, would we ask for different concept for the second, third , ... revision of certain procedures? Just a revision of a procedure in general? Would that be enough? Idk, just some thoughts...

The clinical questions are interesting. I think for my question the "based on" link would not suffice, as it is not like the revision is based on the first procedure (or am I wrong?) About linking procedures... For problems I thought the idea of FHIR was to use a List Resource and put each item of your problem list in the right resource (procedure, observation, familyMemberHistory, allergyIntolerance, …) and then in your List resource with list.code = problems and then all the different items are linked through the use of the List. Idk if that's another discussion or something we can also use for linking procedures. For this question particularly, I don't see it. I don't know what your study concluded about linking problems-problems or problems-procedures?

At this point, asking the NRC for the creation of new concepts seems the only 'answer' to my question but I just want to keep the discussion going and think about a better solution.

[annabel-uzl]

@costateixeira had the great idea of creating an extension for supportingInfo We would then have the Procedure as is and in the supportingInfo we could mention that it's about a revision.

Any thoughts about this suggestion?

[bdc-ehealth]

This would be the preadoption of an R5 feature in an R4 resource. There are no technical objections to this. The workgroup should decide.

[mlambot]

@annabel-uzl you have to step away from "the idea of FHIR" when you construct things regarding care sets. The first thing is to figure out what we want, what we need at bedside, for primary use, then also for secondary use if possible if the second doesn't mean hindering the first and we have to see what is possible with the terminologies that we have and that's not only SNOMED CT, never forgetting we don't have to use terminologies for everything and that too much is the enemy of the good. Some thing are beter kept to words, at least for the time being. FHIR... it is just a standard of exchange. You will always find a way to manage sending your content with FHIR. And FHIR is not a standard crafted so much by an organization in a coordinated way. It's IT stuff, done by voluntaries mostely, in a collaborative way. It evolves all the time with the feedback. Sometimes it lacks feedback and things are like they are just because it was done by a few for their use and on-one brought a different use-case to challenge it. Or at least that's the feeling I get from my 2y and a half getting into this world. SNOMED CT had big US-UK biais and it has changed dramatically in the last 2y since the number of translating countries have overweighted those who use it in its native English form. It's the same for FHIR. There are things designed for US EHRs and healthcare systems. And our health systems are wayyyyy different. So as FHIR gets adopted live in Europe and in Belgium it si bound to change a lot. As it is adopted live anywhere because FHIR isn't that much used for real today, hey! So don't forbid yourself to thing about doing something because FHIR doesn't propose it natively.

You could have a revision of a revision and link the procedures as a chain each to the previous one or have a "counter" of the "position" of the revision saying it's the 2nd, 3rd etc regrading to the first performed. But then how often does it happen to make 3rd revisons? Not sure I'd want a surgeon that has to revise three times his eye operation on me nor that this should be a gold standard in our medicine. We don't have to create rule to support every exceptions either, especially at the start.

My idea of the links between diseases/procedures is indeed to add a kind of supporting info that adds "flavors", like telling that one disease is the consequence of another or is caused by a procedure, that a procedure is done after (temporal like a second time of a general change one ones to bring to a body structure) another or because another (the due to in SNOMED, which is a specific type of temporal attributes adding causality to the after notion). I think there might be a small list or relationships between some specific instances of problems and/or procedures in some clinical use-cases that would bring very valuable clinical insight and that we could capture in a structured way. How technically is less important. First we must think about is it useful, what is useful. Then how to capture the clinical meaning of it (in SNOMED CT in this case if possible). There will be several ways mainly preco or postco or what I call "spit postco" meaning postcoordination but used in the data model (using the rules of SNOMED CT attributes but in spilt fields not to make one expression in one field). Regarding FHIR, we have to make sure the core philosophy and best practices of designing of FHIR are respected but FHIR profiles are meant to be customized, that is most people fail to get. FHIR is a flexible toolbox not an unbendable contraint.

Regarding the NRC, of course it's too early to ask for the creation of your concepts but not to early to handle them this debate. If you think you might be feeling ill, you're not supposed to sort it out in your corner till you know what to do yourself from A to Z thought the aid of internet and then go to your GP only to get him to prescribe you the drugs you concluded yourself you need to straighten yourself out. Just the same, SNOMED international vision of an NRC isn't that of a Mr Donald drive in where people only come to order a concept they want and go. NRCs are there to advise and help you in your thinking process. At SNOMED international and in many NRC I know well, one "simple" user question can have them call in a full group of external field experts and that may debate for several months until the right solution arise, that fit with the true needs of the field (not always the same as the need perceived and expressed originally). It is not good practice to do otherwise in Belgium. And this doesn't equal "encommisionner toujours les choses" in the Belgian way. ;-) What I say is that one should fear to ask questions to the rightful experts for fear it's too early or not well thought about yet. At the very least it is useful for the NRC to know the questions that are running into the population of stakeholders so they won't be surprised when a demand comes in to create stuff related to these issues. It allows them to see also if many persons have the same question. So it can avoid you and 50 others do research on this topic on your own when you could actually all sit together to sort it out. Ultimately, Belgium needs in fact ONE ticketing entry point regarding data structuration in general with in backoffice a sorting out of who should know about/be the answering party for each question between terminology experts, structuration experts, FHIR experts, IT connection experts, architecture design experts etc. It's not the requestor who should have to determine where his/her question should go, the issues are too complexe and intermingled. It'll come, but things need time to be put into place. In the mean while, now your question is known and will be handled by all the right persons, they are all aware.

[annabel-uzl]

@mlambot thanks again for the feedback! Since my FHIR (and SNOMED) experience is only 3.5 weeks long and I've only heard of the NRC for the first time yesterday (after I discovered it's not the Norwegian Refugee Council), feedback like this really helps me to grow and get to know and understand the right way to think about FHIR / the steps to take / the resources for help available / ... So many thanks again 😃

[mlambot]

@annabel-uzl Yes abbreviations ....Norwegian Refugee Council, oups, I'm sorry National Release Center is the official SNOMED international denomination for their national contact point within a Member Country. In Belgium the NRC is the Belgian Terminology Center located in the FPS Health and their ticketing is available here for questions and requests : https://be-rmp.snomedtools.org/fr.

In case of doubt hospitals can also get help from peers finding their way into the maze of the building of the new Belgian health data ecosystem within our CSCT community which can be contacted also by non-members at https://csct.be/helpdesk/index.php. We regularly deliver crash courses about SNOMED CT and interoperability to those in need since 2017. Sadly our last one was only 2 months ago but we can arrange for short 2h educations for hospital teams or even individuals, that can spare a them lot of fumbling. We also have community tools for the CSCT members, so you can play with yours ideas more safely than alone in Excel. Feel free to get in touch with us if needed. The CSCT was founded by hospitals and is there to support the safe and effective journey of the healthcare actors toward the achievement of the BE and EU health data space.

[bdc-ehealth]

WG: we point @annabel-uzl in the direction of using the extension in her own application, although at the moment we have too little information to confirm this as a belgian standard.

[annabel-uzl]

@costateixeira @bdc-ehealth In my head I saved this as 'supportingInfo is the e.g. the string 'revision'', but I now notice that supportingInfo is actually a reference to something else https://hl7.org/fhir/R4/extension-workflow-supportinginfo.html

If we just want to add '255231005 | Revision - value (qualifier value) |' as info, what is the best way to do this? Making a valueset with that one value 😱 🤢 ?

I start to wonder about just putting it in the 'note'-element

I'll ask in-house about an estimate of the amount of 'revision' procedures. If there are only a few, we can ask new concepts to NRC but I'm concerned it will be quite a few so I would like your opinions (again)

[annabel-uzl]

Something else that came up: in SNOMED there is apparently a general Revision (procedure): 118635009 | Revision (procedure) |

We can use this in three ways:

• our main code (UZL code) is the main procedure & both the revision procedure and the SCT code specifying the procedure are partOf
• we have our mapped SCT procedure and put the Revision as 'partOf'
• make a generic 'revision-procedure' with 118635009 | Revision (procedure) | and use this as a reference in the supportingInfo

Personally I like the third option better (and that might be what you meant but I just didn't got my EUREKA moment yet), since I feel 'partOf' is more about 'actual' procedures / actions that are partOf another procedure. And the revision procedure is more 'extra info: it's a revision'.

[mlambot]

Hi @annabel-uzl ,

I'm sorry I'm not sure understand what you describe by "our main code (UZL code) is the main procedure & both the revision procedure and the SCT code specifying the procedure are partOf". Do you mean that you use in house codification for the field "Code" and that the corresponding SNOMED CT code that maps to the procedure goes into "part of"?

If so, this isn't correct. You can put several codes in the "code" element from different code systems if you declare the code system the code belongs to.

See here than one code may be used in CodeableConcept. The concept may be coded multiple times in different code systems (or even multiple times in the same code systems, where multiple forms are possible, such as with SNOMED CT). Each coding (also referred to as a 'translation') is a representation of the concept as described above and may have slightly different granularity due to the differences in the definitions of the underlying codes. There is no meaning associated with the ordering of coding within a CodeableConcept. A typical use of CodeableConcept is to send the local code that the concept was coded with, and also one or more translations to publicly defined code systems such as LOINC or SNOMED CT. Sending local codes is useful and important for the purposes of debugging and integrity auditing. Note that these concepts may be cross mapped using the ConceptMap resource instead of or in addition to being represented as translations directly in the in CodeableConcept."

So you should declare your codeS as "system": "http://uzl.be/myprocedurescodingsystem", (this is an example url, what goes there is the url representing your local code system) "code": "abecedefg", (your local code for this procedure) "display": "Strabismus ingreep" (your local term for this procedure code) }, { "system": "http://snomed.info/sct", "code": "41453009", (the SNOMED CT code corresponding to your local code) "display": "Strabismus surgery" (preferred term of the SNOMED CT code or FSN, normally the FSN isn't for display in clinical practice given it has a semantic tag)

There is also a way to do this representation in two code systems using conceptMap I have not yet studies this so I leave that discussion to the specialists here.

Now as to the question of the precision that this is a revision procedure, you can indeed create another Procedure care set instance where you put the SNOMED concept 118635009 | Revision (procedure) | and you link that record to the procedure performed on strabismus using part of to indicate that the strabismus procedure is part of a revision procedure general process. It might actually be the smartest way to put up things that you've put a finger on there as by doing it that way, you could link several distinct specific procedures to one single "entry point" or revision concept. That would allow a kind of grouping of several therapeutic gestures that have separate SCT concepts but are performed together (simultaneously or sequencially) within the revision process,

Now within the "main" 118635009 | Revision (procedure) | procedure care set instance, you can add why it is performed using the basedOn, reasonCode and reasonReference elements or in free text using the notes element.

This way of doing it avoids direct postcoordination with all the maintenance and interoperability issues and offers that advantage to allow you to code as specifically as possible each operation times/gesture and to group them through their common link to the same "main procedure" which is a revision procedure, while revision of what and why can be specified using basedOn and Reasoncode/reference.

This proposal has to be put forward to the Procedure Care Set workgroup but I find it a good candidate for business rules that would maximize the granularity of coding while not requesting creation of concepts or postcoordinated expression banks. It might however require some change to the way you encode things in your own local code system and how users need to do it in the user interface, unless you let them select one single local code at user interface in a drop down do a technical mapping in back office that somehow splits this entry into the two corresponding SCT concepts (of revision and of the procedure itself) and send the in the your FHIR database into the right elements with the right links between them.

[annabel-uzl]

Hi @mlambot No thats not what I meant :) I actually meant what you were describing next:

We encounter many times that one in-house procedure maps on multiple SCT codes (this because the in-house procedures often are actually multiple procedures during one surgery). So the way we map this is One main procedure with our inhouse code >> then the N multiple procedures with SCT codes that describe al the procedures done during the main procedure; and all these N SCT Procedures are partOf the main procedure. You then get something like This is what was discussed between Jose and I on https://chat.fhir.org/#narrow/stream/216261-Belgium/topic/Linking.20multiple.20procedures.20during.20one.20operation

So what I meant was doing like this: We have our inhouse code that represents 'Revision of blabla' and then we make two procedures: blabla and Revision and we denote those two procedures as being partOf the procedure with the inHouse code

But I find it a bit 'weird' to denote 'revision procedure' as an actual procedure. But that might just be me.

Would it be weird to make a small LM for 'RevisionProcedure' and just saying, the code is always 118635009 | Revision (procedure) | and the reasonCode is mandatory.

Idk I would like to discuss it in a WG, the thing is that we're implementing this at the moment with nexuzhealth so for our project there is almost no time left

[annabel-uzl]

On a second thought, we think it's better the other way around: Procedure with code blablabla and reasonCode '118635009 | Revision (procedure)', since the most important information is than in the code element and not in the reasonCode element

[mlambot]

It's not weird in SNOMED world to denote a revision procedure. Procedures in SNOMED is every time you do something. So counselling the patient, teaching the patient, are going to be procedures also and it'll feel weirder to us to consider such as procedures than seeing the revision as a procedure (which is is) because in our mind a procedure is operating room procedures or at least something invasive. There is a bit of a mental adjustment with SNOMED CT vocabulary, how the name families of concepts like what we would call a sign or symptom is for them a "clinical finding" which is a term no-one would use here.

Yes the main information in the logical model is the Code element, all the rest are metadata of this central meaning. So you should put your local code "UZL3527 - repair of eyelid and canaliculi system", which is the most granular thing as I understand it, in Code. Reason code is why your procedure is performed. From a clinical point of view, I'd expect a disorder to be there or a symptom like for example "341501000119103 |Cicatricial lagophthalmos of left eyelid (finding)|" or the link to the encounter/consultation note where you explain the whole problem. And then upon use of your local code "UZL3527 - repair of eyelid and canaliculi system" you'd have an automatic generation of two separate records in your data model, based on your mapping and that would be S001.1 and S001.2 as in your schema, those elements are going to be referencing your main code using "partOf" in their record.

I agree that as you said in your FHIR chat thread, the relationship isn't bidirectional in FHIR like this. One would like to be able to say that procedure S001 is composed of S001.1 and S001.2. I believe it might be worth creating a local field for this in your data model and ask that it would be supported by a BE extension for exchange called procedure_composedOf or something like that like you have procedure extensions in FHIR currently to specify procedure.causedBy or procedure.approach. We could even propose this extension to Patient Care group for wider adoption if it gets successfully used here because it is a way to avoid direct SNOMED CT postcoordination using what I call "spit postcoordination" meaning postcoordination info in the data model not in the terminology itself nor using expressions written in SNOMED compositional grammar language in one field.

What do you think @costateixeira ?

[KarlienHL7Belgium]

WG meeting 2 May: we need a separate meeting that includes NRC. It is also applicable for other caresets. @KarlienHL7Belgium will set this up asap (Annabel & Filip V want to be included as well with RIZIV & HL7 Belgium & Dr Lambot)

[annabel-uzl]

Revision of a procedure.docx I made a first document with the options and some argumentation. We will internally talk to some clinici about this issue to see what their approach is when using source codes with regard to revision