# Operative Procedure Coding {OPCS,HRG} **Category:** [New to openEHR?](https://discourse.openehr.org/c/new-to-openehr/13) **Created:** 2022-10-20 23:55 UTC **Views:** 1755 **Replies:** 38 **URL:** https://discourse.openehr.org/t/operative-procedure-coding-opcs-hrg/3080 --- ## Post #1 by @sobath Hi all, I am a vascular surgeon interested in EHRs/EMRs. I am relatively new to OpenEHR. Is there a representation in the openEHR framework analogous to "OPCS procedure codes" or "HRG Codes" that can represent different surgical/radiological procedures? --- ## Post #2 by @pablo Hi @sobath welcome! I think the best entry point is the architecture overview document https://specifications.openehr.org/releases/BASE/Release-1.0.3/architecture_overview.html It touches all the basics. --- ## Post #3 by @ian.mcnicoll Hi Sobath, OPCS/ HRG are complimentary to what openEHR offers. Typically you would use a Procedure archetype, perhaps in an operative notes composition template, then the procedure name would be coded using an OPCS and/or HRG code. The Procedure archetype is at https://ckm.openehr.org/ckm/archetypes/1013.1.204/mindmap This is from the openOutcomes project ![image|562x500](upload://8aOOb4zztjoh6EunT9gbyhAMckX.png) The template can be viewed at https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJGI2ODZjNjE4Y2UyMTQ3OTg5OTliMzlmMmI0ZDM3YTk1 From a different use-case, her is how the data would look - where the procedure name is coded using SNOMED CT - it would be exactly the same for OPCS etc, and you can carry multiple codes if required. ```json "procedures_list/procedures/procedure:0/procedure_name|value": "Excision of palmar aponeurosis for Dupuytren's contracture of hand", "procedures_list/procedures/procedure:0/procedure_name|terminology": "SNOMED-CT", "procedures_list/procedures/procedure:0/procedure_name|code": "398211002", "procedures_list/procedures/procedure:0/comment": "No intra-operative problems", ``` For imaging procedures we would normally record a result with https://ckm.openehr.org/ckm/archetypes/1013.1.1494/mindmap --- ## Post #4 by @sobath Dear @pablo, Many thanks for your reply and the link. Please bear with me as I am trying to understand the basic concepts behind the openEHR framework. Is there a need to try and represent every medical concept in archetypes? Since 50% of medical concerts become outdated in 5 years how do you keep up with the changes? I believe you have to abstract the archetypes using templates and forms to manage the complexity for practical use at a busy clinic or hospital ward. But why do you need such complex modelling when clinicians will only use an abstract version of it? With modern NLP-NER techniques do we actually need to represent all these concepts analogous to Entity--> relationships in an RDBMS? --- ## Post #5 by @ian.mcnicoll What you are asking is why do we need information models? The simple answer is that once you move out of a very specific, controlled context, it becomes very complex to understand the data that is collected, and you may be very surprised at the variability of data recording by clinicians. Ultimately the data has to be coherent and queryable across many different care contexts, use-cases and organisations. To do that you need a coherent, 'opinionated' target for data entry - whether typed in or captured via NLP etc. Just as a simple example - do we know if your OPCS-coded procedure code is in the context of a planned procedure, a performed procedure, or indeed not even in a patient context at all? --- ## Post #6 by @sobath Dear @ian.mcnicoll, Many thanks for the reply and the explanation with the links. I have been exploring surgical concepts using the clinical knowledge manager. I feel that something as complex as an operation is represented in a very high level of abstraction compared to the concept of blood pressure. ![archytypes.|690x298](upload://8gPyTYVIL6BYOzZhQWuEfEYGZSK.png) If you try to map all surgical concepts to the detail of blood pressure, how do you keep up with the changes in each surgical speciality? --- ## Post #7 by @ian.mcnicoll Typically we would plug in a procedure details cluster, specific to each speciality/ procedure. This is from the openOutcomes Hip arthroplasty template ![image|489x500](upload://ofub0pwpVIflzCHKala515Vl4GY.png) and is based on a form used for outcomes reporting. If nothing else, this acts as a conversation space where we might try to rationalise the datapoints and related coded valuesets, captured very variably even within the orthopaedic knee surgery community. Is this hard, yes, does it keep changing yes. but I don't think NLP shortcuts the standardisation/rationalisation process, though it may be a great way to enter the data. You still need to get some degree of clinical consensus on what are the questions and the related acceptable answers and other data constraints --- ## Post #8 by @sobath Dear Ian, Many thanks for your reply. I hope you don't mind all the questions. I am trying to understand the basic concepts. I admire the enormous work gone into the openEHR and the 30+ years of experience underpinning the framework. My problem is operative procedures keep changing very rapidly over time. Who is going to capture all these changes? I have been working within my own speciality in vascular surgery to model the operative procedures and use a hybrid approach with NLP. ![opnotebuilder|688x500](upload://iTAjeEv5yas4QJ7JFiOrLHbceTh.jpeg) Even I am overwhelmed with the complexity and version control due to the rapid changes in my speciality. As an academic exercise modelling each concept is very scientific. But at the practical level in the implementation how do you keep up with the changes? eg. template editing -> validation -> changes to forms -> end-user training etc. --- ## Post #9 by @ian.mcnicoll Welcome to our world!! Even quite experienced clinical informaticians often fail to understand the overwhelming complexity, even within a single speciality. We certainly do not have a perfect solution but I think the openEHR methodology (coupled with terminology use) gives us the best approach possible. We do not have to structure everything, large chunks of what you have might reasonably stay as free text. Perhaps the NLP can be be applied downstream - that is fine for analytics where inaccuracy is tolerable but it is no good for operational use. When things do need structured/codified, you need to be able to get real domain expertise (and that means debate and variance), and that's where archetypes are really helpful in giving clinical domain experts a change to really pin down and agree what they can. And yes it it will change repeatedly, so this needs to be an ongoing conversation with versioning so that developers know what they are working with , as it changes. The cool thing about CDR technology is that once any changes are made and agreed, they can be deployed without any further database analysis , entity modelling etc - essentially this is a no-code dataset deployment ecosystem. And yes, that means changes to forms and training but you will have that regardless of the technology you use, and you are not compelled to change everything locally any time an international archetype is updated. It is up to your local implementation and clinical community to decide if/when to update. --- ## Post #10 by @pablo Hi @sobath [quote="sobath, post:4, topic:3080"] Is there a need to try and represent every medical concept in archetypes? Since 50% of medical concerts become outdated in 5 years how do you keep up with the changes? [/quote] It depends. In general an archetype represents information about a topic or concept. In some areas structured information is needed about the concept, so yes an archetype is needed. In other areas you just need to reference a concept, not to have structured data about it, in that context you just need terminology/vocabulary (a coding system like SNOMED CT). When you need archetypes, there is an archetype lifecycle, since medicine and information requirements change in time, so do archetypes. They can be updated, versioned and even be obsolete and superseded by newer ones. The nice thing is: the information recorded complying with old archetypes is not lost, it just complies with a structure that previously (at the time that info was recorded) was totally valid. So you can still query and use that older info. In fact, one goal of openEHR is to have a lifelong clinical database, so your clinical information follows you through your life, and maybe after that (useful to your family). [quote="sobath, post:4, topic:3080"] I believe you have to abstract the archetypes using templates and forms to manage the complexity for practical use at a busy clinic or hospital ward. But why do you need such complex modelling when clinicians will only use an abstract version of it? [/quote] Archetypes should try to be maximal data sets, but they can start small considering only current requirements, then be improved and completed later. Then with templates, built on top of a set of archetypes, you can manage the complexity, and make them as simple or complex as the context/requirements needs. From a template you can cherry-pick specific fields from archetypes and use only those, not the whole archetype structure. On the other hand, if the information you are trying to model and record is complex, the models will be as complex as that. Complexity of clinical information is another related topic. So sometimes you feel the openEHR models are complex, but is really because they model a complex reality (though to be correct those models are not modelling "reality" but the information that is generated by real life events or processes). [quote="sobath, post:4, topic:3080"] With modern NLP-NER techniques do we actually need to represent all these concepts analogous to Entity–> relationships in an RDBMS? [/quote] You will use NLP-NER techniques over free text, not over structured data. The focus of openEHR is structured data, though it can be used for narrative text records, coded text records and multimedia records. The goal of NLP-NER would be to get structured data from narrative text, then you can manage that structure with openEHR models. Mapping objects to a relational database (ORM) is a different thing, I don't think it's a good analogy here. --- ## Post #11 by @sobath Dear @ian.mcnicoll and @pablo, Many thanks for your clarifications and explanation. As a use case; how does openEHR represent a bypass surgery eg. **Common femoral to distal anterior tibial artery bypass using ipsilateral reversed great saphenous vein?** If I want to document that the pulse of the **bypass graft behind the knee was palpable** on my EHR what are the archetypes underpinning this documentation? Assuming that this data would be very important for reimbursement, quality assurance and research. --- ## Post #12 by @pablo [quote="sobath, post:11, topic:3080"] As a use case; how does openEHR represent a bypass surgery eg. **Common femoral to anterior tibial bypass using ipsilateral reversed great saphenous vein?** [/quote] It depends if you want to record structured information about the procedure or if you want to identify the procedure. The first could be done by openEHR archetypes, the second is related to terminology not to structured information (see the comment about that in my previous message). --- ## Post #13 by @sobath I want to do the former (structured information about the procedure ). So that we can perform queries to interrogate concepts related to operative procedures. What archetypes do I need to use? I couldn't find an archetype for bypass in the Knowledge Manager. And how do you record the pulse of the bypass graft? The current pulse archetype is limited to the pulse of a native blood vessel. --- ## Post #14 by @pablo I don't know if there exist an archetype for that specific procedure. If not, it would be useful to document your requirements and ask clinical modelers, or propose an initial archetype yourself in the CKM. --- ## Post #15 by @joostholslag Dear dr. Prem, Welcome to the openEHR community, and thank you for your most interesting questions. I agree with Ian, openEHR is by far the best we have to get a chance of modelling the clinical world. And I agree with Pablo, openEHR archetypes are only ever as complex as the clinical concepts. Regarding your statement 50% of clinical concepts are outdated in 5 years, I’m wondering what kind of concepts you are referring to? But even if you’re right, openEHR makes the technical side of modelling and implementation very easy, it’s just the understanding of the domains information aspects and requirements that will always be hard. And the amount of work needed to spent on that can be nicely equivalent to the value of standardisation. Given your example of palpable pulse behind the knee after bypass is quite interesting. A quick and dirty model can be made into a form and deployed within 10 mins, see screenshot. Now if you want to model this properly, there’s quite a challenge, and I don’t think the pattern has been figured out yet. Some thoughts: The main concept may be the presence of a pulse. Which mostly fits with the pulse/heartbeat archetype. One could easily add a value to body site for “dorsal side of knee” and use snomed coding to standardise that value. Now to model it’s a pulse measured after bypass graft, one could use the action.procedure with procedure name set and encoded using snomed again.and the pathway step set to completed. Now if this measurement is done in context of a postoperative check one could use a template on composition.report-procedure. Now there are multiple debatable points in this strategy. One way that is helpful to me to scope the concepts is to look at it from the querying perspective. If I query for “pulse/heartbeat” does it make sense to have this value returned. My best guess is “yes”, since a pulse in the graft quite certainly means there is a pulse and heartbeat. (Unless it’s still in a donor, or on a pump or so) ![PNG-afbeelding|349x500](upload://A1AjXDEWOXqG6zgE7kAY73dvEd4.png) --- ## Post #16 by @sobath Dear Dr Joost, Many thanks for your reply and the compliments. Regarding the first point; > Regarding your statement 50% of clinical concepts are outdated in 5 years, I’m wondering what kind of concepts you are referring to? I am still unclear on the definition of a "concept" in the openEHR framework. But I can explain using an example. The gold standard treatment for varicose veins ten years ago was vein-striping. Then came Sub-fascial endoscopic ligation, foam sclerotherapy, ultrasound-guided laser, ultrasound-guided radiofrequency ablation (current gold standard), ambulatory conservative hemodynamic treatment venous insufficiency (CHIVA), pharmaco-mechanical ablation, cyanoacrylate glue embolisation and Echotherapy over the last 10 years. This is just one surgical procedure. There is an exponential growth of techniques in modern surgical specialities as new techniques are adopted. How are the modellers going to keep up with all these changes? For the second point, I feel that you will have to create a new concept (archetype?) for "bypass surgery". ![Bypass|690x386](upload://9mOQwiy2DWihWmSHjIOpUo3rHhM.png) The pulse of the bypass conduit would be recorded at Bypass > Patency > Location of patency. But bypass operations are performed by vascular, cardiothoracic, transplant, and bowel(upper GI, lower GI) surgeons hence more complexity will be added. I haven't the knowledge or experience to properly model this concept but I am happy to help. --- ## Post #17 by @ian.mcnicoll [quote="sobath, post:16, topic:3080"] There is an exponential growth of techniques in modern surgical specialities as new techniques are adopted. How are the modellers going to keep up with all these changes? [/quote] You are absolutely correct that this is a huge challenge, and of course, is equally true in almost every other specialty. However, it is not a challenge that every data/database/concept modeller faces, especially when within a speciality individual organisations, specialities and and even individuals may have somewhat different recording practice. And then each application developer has to acquire that knowledge from those clinical teams (again and again), and then turn that into computable artefacts. These are likely to be non-interoperable, so a different set of work then has to be undertaken to develop exchange models and related transform code to allow data exchange between the different siloed apps. The openEHR premise is that we can save all of these application developers a lot of time and effort, if we try to agree the definitions from the outset, make that definition process and review very easy for clinical folks to engage with , and then have smart datastores that allow for immediate deployment of the models without further engineering. Nice start for a data model!! --- ## Post #18 by @ian.mcnicoll Operative bypass detail archetype ![image|595x499](upload://frYx1n4lkBpbc0OlmRwXJFqp0rG.png) And in context of a By pass surgery note 'composition and Action Procedure archetype. The dates/times and context are handled by the Composition and Procedure. ![image|475x500](upload://swjfwCaXC3WTMkhNmSKVAkOFofp.png) https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDNhODQyNjZiYjJiYjQzNTVhMjQ2YmM0ODUwNWU5Y2I5 And as @joostholslag pointed out in his version, these are immediately deployable to an openEHR CDR (datastore) This is a crude form built from the template plus you can see the JSON data being built up at the left-hand side - this is what is sent to the CDR and is immediately stored and queryable. ![image|690x445](upload://tBfVxgAAXMZYYOhDxV831xEqkzI.png) --- ## Post #19 by @joostholslag Dear dr. Prem, The key question in this interesting challenge of how to model “bypass surgery” is in defining “concepts”. The mindmap is a very helpful example of how one could define “bypass surgery”. It makes sense as a mental model for a surgeon to understand what a bypass surgery *is*. Now in openEHR mapping out a concept is a useful and regular step when modelling a clinical concept like bypass surgery. But the perspective on defining a concept is oriented towards *processing information* regarding the concept not (necessarily) around *understanding* it. This perspective change can be quite a challenge for us practically oriented doctors, but one I found very rewarding. So I hope I can interest you to follow one openEHR modellers perspective. One starting question is what kind of data would you like to record around “bypass surgery”? This is nicely captured by the mind map you shared. Though other users probably want to record additional information regarding the bypass, for example suturing technique, intra-operative anti-coagulation used etc. etc. A second key question is in what context (situation) this data will be recorded. The openEHR view is that data entered into the system at one moment should be a complete “form”. This means, a report describing the procedure will have many of the elements described (date of creation, specialty, donor vessel etc.). While others: e.g. “indication” may be recorded at a preceding event (clinic visit where the indication for surgery was determined). And e.g. the patency and the improvement in (lower leg/foot) perfusion and reduction of symptoms will be determined after the procedure in a postoperative check. So in openEHR this will probably be 3 separate forms. These “forms” are called *templates*. Now there’s a question of what data elements have already been modelled. The CKM archetypes, especially the “published” ones are extremely high quality in my experience, so I would definitely recommend always using those. E.g. the [action.procedure](https://ckm.openehr.org/ckm/archetypes/1013.1.204) archetype already has an element “indication” that should be reused. (Reuse of an element from an archetype is part of “templating”: where the template contains references to elements of archetypes and constrains them to be specific for the form. E.g. use the indication element, fix the procedure name to “fem-pop bypass” and don’t use the “urgency” element from action.procedure. and usually combining elements from many archetypes into a single template.) Now even stronger reuse is recommend for data elements of the underlying openEHR reference model (RM). E.g. the “date and time of creation” and the “specialty” are elements already mostly defined in the RM. So now the question is how to model the elements that are not yet part of an existing archetype. Here the key question is “what is the scope of an archetype”?. One of my preferred ways to reason about this is to look at it from an information retrieval/querying perspective: If I ask the database for information e.g. blood pressure it should give me all data regarding what is generally understood as blood pressure regardless of the form it was recorded in. (Systemic arterial Blood pressure is the same concept in a diabetes checkup form as in a “arterial insufficiency/claudicatio intermittens” exam, but a pressure in a toe in arterial disease is not). So the quest is to find the underlying concepts of a bypass surgery that holds together along many different usecases and query’s. Getting this right is hard, getting it wrong is dangerous, once people/machines start to make conclusion from the data, e.g. using decision support algorithms. This will require experience (good and bad). And is a process of continues learning and adaptation we go through as a community. And it’s one of the key reasons we hold public reviews of archetypes. Luckily there are resources to help, e.g. [described design patterns](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns), asking experience modellers, [old review comments](h https://ckm.openehr.org/ckm/archetypes/1013.1.204/reviewscontent) in CKM, discourse discussions etc. etc. The best modeller I know is @heather.leslie author of most of the CKM archetypes. For modelling specific procedures, I’m not aware of any established detailed design patterns. The good thing is that once we have that it will be much easier to do additional procedures. I agree with you and Ian that it’s a lot of work to model all procedures in the world. However my hope is, a smallish group will be able to determine reusable design patterns using a basic library of core archetypes and reusing clinical terminology like snomed. Tools to do this modelling are also improving along the way. And so I hope the work of modelling the bulk of the concepts (e.g, operatives procedures) can be done by many people with only some basic openEHR training. My utopia is that the original authors of a procedure, when publishing in a scientific journal also share an archetype modelling the procedure. Reusing this archetype in a live openEHR system then is a piece of cake, as I (partially) demonstrated in my example above. So I do have good hopes that we have a system with openEHR that is up to the challenge you describe, of modelling all clinical concepts, even though they change rapidly. Now if I made you eager to get started on modelling “bypass surgery”, I’m very curious for some details on your ‘project’: usecases, technical details (CDR), input forms, number of users/hospitals etc. Etc. :innocent: --- ## Post #20 by @ian.mcnicoll [quote="joostholslag, post:19, topic:3080"] I agree with you and Ian that it’s a lot of work to model all procedures in the world. [/quote] The key point here is that 'someone' has to do this and right now that is being done for every new procedure or method by thousands of different clinical application implementers right now without any coordination and where standardisation is an afterthought. Part of the academic work to develop and document a new procedure or method should include a related data model from the outset. Clinical informatics input should be just as key an input to any paper as a statistician. --- ## Post #21 by @thomas.beale [quote="sobath, post:16, topic:3080"] How are the modellers going to keep up with all these changes [/quote] I'll just add a small reality check in here. Models of the sort created in openEHR will report the following kinds of things with respect to procedures (assuming some initial appropriate Dx): * the order & booking * procedure note, i.e. standard summary of what was done * follow-up care orders and actions. The long list of 'new terms' you mentioned above are taken care of by terminology such as Snomed, not openEHR. openEHR data will record the procedure type and location using Snomed (or some other) terminology, potentially one day in the form of sophisticated post-coordinated expressions (this has not happened yet in the field). In the worst case, let's say there is some new procedure that isn't even listed in the terminology - it will just be recorded as text. So, as an overall challenge for industry, the ongoing churn in 'concepts' is mostly a challenge for terminology. openEHR takes care of the structures of how to record the various kinds of investigations, notes, summaries, etc etc but the anatomical / physiological and procedural specifics will come from terminology. Where change is a challenge for openEHR is where any of those specifics are encoded directly into the *structure* of the information, not just the *values*. Examples: imagine medicine invents something to replace systolic / diastolic / MAP BP with; imagine 12 lead ECGs are replaced by some new kind of device (already happening), then openEHR modellers will have to react. Here's a [blog post on semantic scalability](https://wolandscat.net/2014/12/15/semantic-scalability-the-core-challenge-in-e-health/), containing some estimates on how large the numbers might be, both absolute and rate of change. The whole design of openEHR is predicated on change being constant, and being able to technically keep up without a break in service in all those 24 x 7 x 365 systems. Hope this helps. --- ## Post #22 by @heather.leslie [quote="thomas.beale, post:21, topic:3080"] So, as an overall challenge for industry, the ongoing churn in ‘concepts’ is mostly a challenge for terminology. openEHR takes care of the structures of how to record the various kinds of investigations, notes, summaries, etc etc but the anatomical / physiological and procedural specifics will come from terminology. [/quote] I think there is a lot of truth in this statement - not many people outside openEHR have witnessed the power that comes from the reuse of well-designed, stable archetype patterns, combined with strategic use of terminology. Anyone can easily whack some data elements into an archetype and start using it for local purposes, but if we want to create a coherent ecosystem the data needs to be designed with careful consideration about how it fits within, and complements, the entire modelling ecosystem. This takes some time & forethought, but surprisingly is often much less onerous than anticipated; the rewards for the initial implementers and all those reusing it can be enormous. This requires a deliberate design choice - with consequences for each option. The design of the published ACTION.procedure archetype is clearly intended as a framework, as the Use states, for use in the simplest, everyday procedures through to the most complex imaginable. This archetype is well-used in many implementations, but this is where the modelling momentum/resourcing has faltered. It is critical that the archetypes that we design to extend procedures further are created in the context of the broader surgical domain. There is no doubt in my mind that a huge number of standardised patterns that can be elucidated in collaboration with clinicians - think 'approach', 'closing', 'intra-surgical exam findings', etc - there will no doubt be many. And while none of these will be specific for bypass surgical documentation, many should be suitable to provide the general context for the specific bypass use case. The concept of a surgical bypass is really interesting in this context and @sobath's mind map is a great initial insight into the clinical requirements - clearly, they have identified some valuable, emerging patterns. I have so many additional questions for @sobath , especially to determine whether a maximal 'bypass' pattern can be archetyped for all bypass situations and how we cater for variables required in specific situations. At some point, we will probably need specific 'end point' archetypes that are simply unique for each individual procedure, such as this rather old [Myringoplasty procedure](https://ckm.openehr.org/ckm/archetypes/1013.1.1672) example - although I acknowledge this archetype could also be revisited to utilise better reusable patterns. The art of skillful clinical modelling resides in the identification of the repeating patterns that underpin clinical practice and its associated documentation. When we identify a practical, reusable model, we know we have been successful. When we create a 'dead end' archetype only applicable for a single use case, it should be a trigger to question our design - sometimes it may be quite appropriate; but sometimes we will have gotten it terribly wrong. The surgical domain has had very little strategic modelling activity to date - it is largely a greenfields domain. Identifying the next level of reusable CLUSTER patterns for nesting within, and extending, the ubiquitous ACTION.procedure should be the next priority - patterns which represent the activities and findings common to many surgical activities. Unfortunately, I suspect most implementers are utilising the 'quick & dirty approach for modelling extensions for ACTION.procedure in their clinical systems. As @joostholslag suggests, we need resourced modellers working in collaboration with savvy surgeons to plan and develop a coherent surgical domain ecosystem of archetypes that the openEHR community deserves. --- ## Post #23 by @sobath Dear Ian, Many thanks for illustrating the bypass archetype and the link to the archetype designer. If there is an effort to model surgical concepts I am willing to help with some input into the following specialities.; vascular surgery, endovascular procedures, transplant surgery, gastrointestinal surgery. Is there an LMS or an online course for someone like me to learn more about modelling? --- ## Post #24 by @sobath Dear @joostholslag , Thank you for pointing out how you can incorporate existing archetypes to document bypass surgery. My illustration was to show how I think of a surgical concept relevant to my speciality and the type of information I would want to retrieve from the documentation. Concepts like suturing technique and intraoperative anticoagulation are not unique to the bypass and should be captured in other archetypes and linked to the bypass concept. For my understanding can you explain the definition of a concert in openEHR modelling? If you check on Pubmed, there are more than 180,000 articles on the word "bypass". This concept will provide valuable information to the surgeons, and researchers to identify and extract information such as patency and its relationship to the conduit used etc. It will also be useful to the industry engaged in the development of bypass conduits. To answer your query regarding the project we are working on; we are attempting to identify concepts like the operative procedures, relevant OPCS codes, prosthesis used, and surgical consumables used during surgical procedures to document and maintain registers that any surgeon can use. We are employing NLP-NER techniques and trying to identify the best model for this purpose. ![NLP NER|685x500](upload://tm3f7fVkI6qcFJjAaeRRIzI9LM6.png) --- ## Post #25 by @sobath Dear @thomas.beale , Thanks for the explanation on how models are created and used in openEHR. Examples you have given ; [quote="thomas.beale, post:21, topic:3080"] * the order & booking * procedure note, i.e. standard summary of what was done * follow-up care orders and actions. [/quote] Are more relevant to managerial tasks that are useful in running a clinical service like a hospital. But if I want to identify information like; * Is bypass more durable for treating an occluded external iliac artery than a "covered stent graft"? * Compared to bypass surgery, is endarterectomy more durable for treating occlusions/stenosis at the level of the common iliac artery? To answer the above questions you need to model surgical concepts like "bypass", "endarterectomy" and "covered stent" analogous to blood pressure and ECG. Please correct me if I am wrong about these concepts as I am still trying to grasp the basic principles of openEHR. --- ## Post #26 by @heather.leslie ![NLP NER_HL edit|682x500](upload://2vmHN8QO1zikvdM820035etxSip.png) My approach to the Operation report would be to create a template using COMPOSITION.report at the root level, then adding a variety of ENTRY-level archetypes, extended as necessary with CLUSTER archetypes. In the attached example: * Existing archetypes * COMPOSITION.report * ACTION.procedure * ACTION.medication * OBSERVATION.imaging_exam_result * OBSERVATION.capillary_refill * Proposed new archetypes * Surgery-specific CLUSTER archetypes related to general surgical concepts such as approach, closing etc for nesting within the 'Procedure detail' SLOT in ACTION.procedure * Vascular surgery-specific activity-related archetype/s for nesting within the 'Procedure detail' SLOT in ACTION.procedure * ACTION.imaging - to record the process of planning to completion of an imaging examination/procedure * Terminology value sets - used to populate the myriad of procedure and imaging test names, device names, consumables etc. *This is where you'd find “bypass”, “endarterectomy” and “covered stent" and all the rest of the procedure names - a value set used in the 'Procedure name' data element, within the ACTION.procedure archetype.* In this way, we should be able to build up a common-ish, reusable pattern of archetypes as building blocks that form the foundation for representing the most common types of vascular surgery. Then we can aggregate and constrain the archetypes to suit a typical vascular surgical process, such as your use case. Adding relevant terminology value sets will support further refinement and differentiating between the same type of surgery performed in different locations or under different circumstances. Additional archetypes may need to be added for outlying situations such as when complications occur or more complex procedures are undertaken eg combos, pregnancy, paediatrics etc. --- ## Post #27 by @sobath Dear @heather.leslie, Many thanks for your explanation and the suggestion how you can modify the operation note template to capture these surgical concepts. When I was designing the my d map for bypass surgery I was thinking on the more border reach as you have suggested in your previous post. As bypass can be done not only blood vessels but also for bowel, billiary system. --- ## Post #28 by @heather.leslie Don't let me discourage you from thinking about all types of bypass! We usually have the opposite problem of people modelling for a single purpose. I don't have enough detailed insight to say if your approach could work or not. The pattern you showed in the mind map works in theory, but we need a plan for where and how the specific details for bowel, biliary etc would also be modelled and whether it works for each possible context. The only way to work out what works best is to model within a plan for the ecosystem - it's an investigative process in practice. If we just add archetypes piecemeal and without a strategy, we run the risk of ending up with disconnected fragments. This is the 'art' I was talking about in a previous post. Trying a design, testing it, maybe failing - there are many archetypes that were good in theory but we found didn't work in the context of the bigger ecosystem view. For example, we used to model all measurements in a single archetype - you know, length, height, width, area, volume of an 'object' - good in theory, especially from a potential reuse point of view. We thought this would be a ubiquitous pattern but querying on a standardised data element of 'length' was found to be of little value & removing irrelevant measurements in every template became a modelling burden, so we eventually found it was actually easier just to add relevant measurements into each exam archetype, and only the ones that were relevant for each context - this works better. We learned that sometimes we can overthink patterns as well. Cheers. So pleased to see your enthusiasm. --- ## Post #29 by @sobath @heather.leslie, I do agree, we need to have a broader consensus on how to model surgical concepts. How do we achieve it? --- ## Post #30 by @thomas.beale [quote="sobath, post:25, topic:3080"] Are more relevant to managerial tasks that are useful in running a clinical service like a hospital. But if I want to identify information like; * Is bypass more durable for treating an occluded external iliac artery than a “covered stent graft”? * Compared to bypass surgery, is endarterectomy more durable for treating occlusions/stenosis at the level of the common iliac artery? [/quote] Now you really are into details. These detailed procedures would be modelled with a process model, such as [these ones you can see here](https://specifications.openehr.org/releases/PROC/latest/process_examples.html#_multi_drug_chemotherapy), expressed in openEHR Task Planning formalism. (This formalism is still under development.) Note that this formalism includes decision rules / pathways, which could implement the kinds of choices you mention (i.e. what method is better in what circumstance), and indeed, some 'plans' can be mainly formed of such decision rules. Other ways to express such processes include [BPM+](https://www.bpm-plus.org) (also emerging, and I guess about 2y away from implementation in tools). There are also various products on the market, not standardised, but that would allow you to build some kind of process definition. Theoretically you could just try to use a normal BPMN tool, but there are limitations in this approach and they do not handle data definition well (which is why BPM+ exists). So this area is at the 'leading edge'! There is already some capability to create Task Plans within the [Archetype Designer](https://tools.openehr.org/designer/#/) (main openEHR archetyping tool, produced by Better), but things are still changing in the specifications. So it would be good to know if your needs are immediate, or if you are thinking more over the next say 2-5 years. [quote="heather.leslie, post:26, topic:3080"] My approach to the Operation report would be to create a template using COMPOSITION.report at the root level, then adding a variety of ENTRY-level archetypes, extended as necessary with CLUSTER archetypes. [/quote] Great slide & analysis! These kinds of data would be created in the EHR as a *result* of Task Plans being followed (future), or just of work being done today (i.e. with no computational plan). They report / summarise activities after the fact of course, rather than defining a plan of work to do. So according to Heather's analysis, we have a 'pretty good' means of reporting what was done, in detail (and using terminology). We (= the whole industry) still have some way to go on being able to routinely create prospective, detailed plan definitions for such work. --- ## Post #31 by @ian.mcnicoll Some of our older course material is at https://freshehr.com/resources/ --- ## Post #32 by @ian.mcnicoll Although clinical registries are not always the best guide to how to model operational data, they can contain a lot of helpful information This is from the [UK national vascular registry](https://www.vsqip.org.uk/content/uploads/2022/09/Bypass-Proforma_2021.pdf) ![image|430x500, 75%](upload://sRXXNiyaZiX3GTZzYPJS6ADvjA9.png) --- ## Post #33 by @heather.leslie I used to facilitate this work on behalf of the openEHR community but I was forced to step away from that role just over a year ago. The methodology we developed works well and I still follow that methodology in work with clients, and I ensure our archetypes are always designed so they can be contributed back to the public good via CKM. We still run reviews through CKM to garner broader participation and consensus. I'm not sure how this will change when the openEHR Board kickstart its new Clinical board that will endeavour to recreate & expand on what we had - @joostholslag is one of the key players. I suggest you get in contact with him. --- ## Post #34 by @sobath Dear @ian.mcnicoll, I do use the national vascular registry to record all the vascular procedures I perform. Most specialities have their mandatory quality Improvement registries. The main aim of these is to compare the performance of all the units in the country. But the data structure they use is a very basic one. Here is a tool I developed almost 10y ago as an SHO(resident) for one of the London vascular units. This was to record bypass procedures and generate information useful for research. ![distaks|690x459](upload://y8tjFUw5n69FFJQkZjNhAXmeOUc.png) ![ER|690x450](upload://cQsQVBRz6Iit664QaBu2npQjtm3.png) I was using SQL to generate simple queries ; ![distaks1|690x257](upload://djLSIND0tgUhLBD8Oeltrx1Nhke.png) A typical query was; **How many male patients over 60y, currently on clopidogrel preserved their Femero-Antierio tibial bypass constructed using vein after 6 months with only one salvage revision?** But for the current project, I would like to go further and develop a tool for all surgical procedures. --- ## Post #35 by @sobath Dear @thomas.beale , Many thanks for your explanation and the links. [quote="thomas.beale, post:30, topic:3080"] These detailed procedures would be modelled with a process model, such as [the ones you can see here ](https://specifications.openehr.org/releases/PROC/latest/process_examples.html#_multi_drug_chemotherapy), expressed in openEHR Task Planning formalism. [/quote] Just to clarify if I understood it correctly, do you plan to use the process modelling to capture the entity relationship relevant to different specialities? [quote="thomas.beale, post:30, topic:3080"] Other ways to express such processes include [BPM+](https://www.bpm-plus.org) (also emerging, and I guess about 2y away from implementation in tools). [/quote] I did come across BPM+ at one of the British Computer Society - Health and Care group lectures. Sounds very interesting and will have a look at it in more detail. --- ## Post #36 by @sobath Dear @heather.leslie, Did you work on the vascular society - National vascular registry? If that so I am not surprised about; :wink: [quote="heather.leslie, post:33, topic:3080"] but I was forced to step away from that role just over a year ago. [/quote] --- ## Post #37 by @johngrant4est @sobath At the risk of expanding this already lengthy and very interesting thread, I just wanted to highlight that the Anaesthetic community are facing similar challenges. In particular, we have struggled to come up with a coherent representation of a clinical procedure such as an epidural, where there are multiple concepts such as guidance, positioning, monitoring and invasive devices. It strikes me that there are many similarities between surgical and and anaesthetic procedures and it may be useful to abstract these at a high level and then try to specialise for specific use cases. We've been at this for years in the HL7 community, but are a long way from having a usable IG in Anaesthesia, as the modelling entities such as ACTIONs and OBSERVATIONs are currently unable to deal with the all the nuanced complexity. As @thomas.beale points out, there is a wealth of Terminology to support the effort. The SNOMED Anaesthesia CRG has 5,000+ terms in its vocabulary - no doubt the vocab for surgical procedures is even larger. The challenge is that Terminology only gets you so far - eventually you need robust yet flexible clinical models to represent what happens in the real world. I'd be very happy to join forces in a project to model surgical procedures as it will undoubtedly present similar challenges to the work we're doing in structured care records for Anaesthesia. --- ## Post #38 by @joostholslag This is really helpful! So your primary aim is collecting data for research/case review. In openEHR this would usually be considered secondary usage of health data. But certainly is part of the goals! The primary implementation would be collecting data for the principal care proces (OR report, post-operative instructions etc; the stuff described in my and others earlier posts). And getting the data you want for research will be done using AQL. Where one can query across entries in the primary EHR for identical concepts. @ian.mcnicoll are you up to create an AQL example for the query @sobath desribed? This research vs primary process is probably why openEHR data modelling feels different/needlessly complex even to you? But what you’re trying to achieve is certainly possible with openEHR. And I would encourage you to try. And others have done similar things, there’s been a recent webinar by Better.care about rare disease registry’s in Italian/Slovenian pediatrics iirc. Let me know if you need a link. But honesty demands to share other standards like omop-ohdsi, might be a bit quicker to achieve your goal. If however you want to be able to perform the research query from data collected in the primary process, without additional work, openEHR is by far your best shot. But depending on your EHR (provider) that might be (too) far in the future. --- ## Post #39 by @bna This is a great answer @ian.mcnicoll. It gives the benefits of #openehr to handle real (clinical) life complexity. --- **Canonical:** https://discourse.openehr.org/t/operative-procedure-coding-opcs-hrg/3080 **Original content:** https://discourse.openehr.org/t/operative-procedure-coding-opcs-hrg/3080