# Cardiology templates and archetypes **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2025-02-13 14:16 UTC **Views:** 984 **Replies:** 36 **URL:** https://discourse.openehr.org/t/cardiology-templates-and-archetypes/6327 --- ## Post #1 by @Olha_Nikolaieva Hi everyone, At the University Hospital Basel, we’re excited to announce the start of a major cardiology project. This initiative involves developing templates and modeling cardiology-specific archetypes to address gaps in the openEHR ecosystem. The first archetypes currently in development are: * **Duke ISCVID Infective Endocarditis Criteria** and * **European System for Cardiac Operative Risk Evaluation (EuroSCORE) II**. Together with @jannisp and @amanda.herbrand, we are committed to creating detailed, reusable models aligned with openEHR principles and international standards. Transparency and collaboration are key to our work, so we’d love to hear community feedback, ideas, or insights. Stay tuned for updates, and feel free to reach out if you’re interested in contributing or learning more. Looking forward to your thoughts, Olha --- ## Post #2 by @SevKohler Awesome :) we did some cardiology stuff, most of it needs some love (different quality) and some of it have had no flow back yet (resources missing) . I hope you can find smt of use here. https://ckm.highmed.org/ckm/projects/867.116.7 For CAEHR (connecting GP and Hospitals tracking patients etc.), please check the incubator CAEHR on the HiGHmed CKM, here all the models labeled with CAEHR_C where designed for the cardiology use-case. These contain more up-to-date templates as the HiGHmed UCC ones and some new archetypes for questionnaires (here its not so easy with the IP of these some of them we had to take down from the CKM). --- ## Post #3 by @Olha_Nikolaieva Thank you so much for sharing this and pointing me in the right direction! :slight_smile: I’ll definitely take a closer look at the HiGHmed CKM and the CAEHR_C models. --- ## Post #4 by @heather.leslie Hi Olha, Great to see you advertising your work in the community to promote reuse rather than reinvention. Thank you. It may be helpful if you can post what you think the gaps are in the CKM library or a mind map of the domain scope for your project. IMO many archetypes that may be useful within a cardiology context may not be cardiac-specific. For example, I have many years worth of archetypes uploaded to incubators or early drafts local on my machine that may be of interest even though I have not worked on cardiac-specific projects. Kind regards Heather --- ## Post #5 by @amanda.herbrand Hi Heather, I absolutely agree! We already found the Cluster for imaging of the heart and also the ones for Physical examination of heart and lung each, amongst others. We had planned to get in touch with you about how to best further develop those and maybe achieve a stable version when our roadmap has become a bit clearer. Currently, we are still in a project planning phase. Our high-level gap analysis has shown that many archetypes are already available, however, some (not many) are a .v0 and few missing. Happy to share our gap analysis if of interest. We are tackling the easier, missing ones first (such as Duke and EUROII) and then moving on to the existing unstable ones. Regarding echocardiography, we are also in touch with Åsa (@Asa_Skagerhult) and colleagues from the ASHA project in Sweden to collaborate. Let's stay in touch! Best, Amanda --- ## Post #6 by @simonegli Hi everyone, I have recently joined the clinical data modeling team in Basel and am taking my first steps with the archetype designer. As Olha has outlined above, we are at the beginning of a cardiology project with the long-term aim to model the cardiology documentation (i.e., clinical examination, imaging, interventions etc.). Currently, I am working on the clinical examination of the heart and cardiovascular system. The idea is to model it with the complete physical examination of all organ systems in mind. So far, I have found the following resources: • Proposal for the physical examination pattern from Heather: https://openehr.atlassian.net/wiki/spaces/healthmod/pages/380993560/Proposal+-+Physical+examination+findings+pattern • CKM project on physical examination findings: https://ckm.openehr.org/ckm/projects/1013.30.25 Based on these resources, I have tried to model the examination of the heart, starting from CLUSTER.exam-heart.v0: ![Draft-examination-of-the-heart-250402|320x500, 100%](upload://moL34P1rqV67YHd3Cx3nK1qUvOO.png) The data elements are based on the textbook “Macleod’s Clinical Examination” and the physical examination standard on internal medicine wards at the University Hospital of Basel. It is a first draft and not at all meant to be final. I’m a clinician who has mostly worked in internal medicine and have little experience in data modeling, so the archetype probably looks very crude to experienced modelers. I find it quite difficult to get my head around how to model the complexity of the physical examination. I’m looking for other people in the openEHR community working on this who could provide some guidance, especially regarding the general structure. At the moment, I’m mostly thinking about the following questions: 1. Is building specific CLUSTER archetypes for each exam finding, specialized from the generic exam archetype still the recommended way to model specific examination content? 2. Are there other approaches? 3. What would be the recommended way to model findings such as cyanosis or oedema (a v0 CLUSTER for oedema exists already)? Would be great to find other people working on the physical exam of the heart and beyond 😊 Kind regards, Simon --- ## Post #7 by @ian.mcnicoll Hi Simon, and welcome to the community. I must confess that you have induced some PTSD in me!! First the mention of “Macleod’s Clinical Examination” which I clearly remember from my medical student days in the 1970s!! I used to use it to send myself to sleep. The second is the whole issue of how to do detailed physical examination, which is really, really fraught. @heather.leslie is undoubtedly the expert here having grappled with the problem over many years. Here is an earlier 'rejected' attempt https://ckm.openehr.org/ckm/archetypes/1013.1.111 I would definitely not use that, but I think it helps to see where we have gone in the past and found it problematic I think the default pattern, is as you say, to specialise an examination around a part of the body or system but how to handle further complexity like heart sounds etc , is I suspect still bit unclear. A large part of the issue is the sheer disparity in the granularity of the exam needed by different clinicians and the context in which the examination is performed. My gut instinct , though(@heather.leslie @siljelb @varntzen might disagree!, is to split out things like heart sounds into a separate cluster archetype to be slotted in. Expect debate, and good luck. this is real 'dragon' territory. I also do sometimes wonder if this is still a valuable area to be recording as structured data, or at least to attempt to standardise, given the increasing use of more definitive examination through imaging etc. --- ## Post #8 by @simonegli Hi Ian, Thanks a lot for your answer and advice, I’m very sorry for inducing some PTSD in you! I must admit that I find modelling the physical examination quite mind-boggling and thinking about it too much makes me feel a bit dizzy. So, it’s a relief to hear that it’s tricky even for the most experienced in the community. Thanks a lot for the link to the rejected archetype, it's very interesting to see how much thought has already been put into this. I've also been thinking about how much detail in structured documentation of the physical examination is both feasible and helpful in clinical practice. For now, it is definitely a good exercise. Thanks again and have a nice weekend! Kind regards, Simon --- ## Post #9 by @ian.mcnicoll This the real culprit ![image|349x500](upload://oWY5XPLo0nE02LcTC2rA3YwKSrw.jpeg) --- ## Post #10 by @Koray_Atalag Hmm...I'd start with these :rofl: ![ChatGPT Image Apr 5, 2025, 12_12_43 AM|690x460](upload://dR8dJqL84lXqtO2G2Q5iix5nBcA.jpeg) --- ## Post #11 by @heather.leslie Hi Simon, Welcome to the community. You've not started with an easy task. [quote="simonegli, post:6, topic:6327"] Is building specific CLUSTER archetypes for each exam finding, specialized from the generic exam archetype still the recommended way to model specific examination content? [/quote] Yes, the pattern is still the basis for creating physical exam archetypes. I would start as simple as you can, especially if this is a new experience for you. Also to keep it aligned with what current systems are recording, knowing that we can grown it and extend it in the future. More specifically, I would advise you to begin with investing time in developing a mind map outlining your proposed pattern, including links to related archetypes. This is a way of testing whether the pattern will work before you commit to building an archetypes Just adding the data elements that you know you need and are pretty sure will be ubiquitous. While we are aiming for inclusivity of all information about the heart it doesn't all have to happen at once. That said, the mind map will help identify the road map for other possible data elements or related archetypes as well - effectively an ecosystem of the heart/chest related archetypes. Only once the mind map is agreed by your peers, would I start to use the Archetype Designer tool. This advice is one of the best kept secrets, in terms of not wasting time. Mind mapping is a much more effective tool to test a modelling pattern. [quote="simonegli, post:6, topic:6327"] What would be the recommended way to model findings such as cyanosis or oedema (a v0 CLUSTER for oedema exists already)? [/quote] The oedema archetype originally designed to be nested in any higher level Exam CLUSTER, for example, the theory was to nest it in an archetype related to the lower leg, to record pitting oedema of the calf. But again, looking at this very old archetype, it also needs some more work to make this clearer. OR We need someone to do the investigation (via mind mapping) to work out if it is more efficient to just add relevant data elements in the ankle/leg/sacrum archetypes and if there are other use cases for oedema that would make this archetype inappropriate. Cyanosis may be best modelled directly and explicitly in the Exam archetypes where cyanosis is examined eg face, fingers or create a reusable one for broader reuse. Again, we need further modelling and investigation before we can make that decision. There are some heart-related archetypes that have been rejected (and the underlying reason for Ian's PTSD) and the 'Auscultation' CLUSTER that @ian.mcnicoll pointed you to has some good possible content related to heart sounds even though the concept is not correct. Heart sounds could be modelled as an internal grouping/cluster in the Exam of the heart archetype, although I wonder if there is ever a use case where we might record heart sounds outside of a formal heart examination? For example, if there is a rupture of the diaphragm, you can hear breath sounds in the abdomen. Is it also possible to need to record heart sounds within an 'Exam of the abdomen' archetype context? I have certainly used my dusty old version of Macleod to assist in designing these archetypes, but I'd also just caution you to remember that we are not designing them for academic purity but to reflect actually clinical practice, which may be somewhat messy and we need to be able to capture recording for the least untrained or remote health workers who may only be able to document that a murmur is present, through to the most experienced cardiologists who want to document every diagnostic 'click'. This is our 'art' and calling in designing high quality archetypes and, simultaneously, our collective world of pain! You are not alone, it is challenging but also very satisfying when you 'nail' an archetype and it gets published. :smiling_face_with_sunglasses: --- ## Post #12 by @simonegli Hi Heather, Thank you for the warm welcome and your helpful insights. I’ll definitely take the mind map approach to explore the pattern and connections, and to identify the road map. The examples around oedema and cyanosis really helped clarify the kinds of questions I should be thinking about. If there are any additional resources from previous attempts to model the physical examination—such as older archetypes not available in the CKM, or documentation of the thought process—I’d be very interested in having a look. Thanks again for your help! Kind regards, Simon --- ## Post #13 by @Olha_Nikolaieva Hi, I'm happy to announce that the two scores (Duke ISCVID Infective Endocarditis and EuroSCORE II) are now ready and have been uploaded today to the proposed archetypes on CKM. I highly welcome any feedback and comments. "EuroSCORE II" is a registered trademark, and we have received permission from the IP holders to use the name in our openEHR model. I have added this information accordingly to the licensing section. Could you please check if it was done appropriately? Should any additional steps be taken regarding this matter? @varntzen @siljelb @heather.leslie Would it be possible to move these two scores to the Team Switzerland Reviews project so we can manage the review process there? The next step will be to develop the **Heart Echocardiography archetype**. We have completed the requirement analysis on our side and compared it with the requirements received from @Asa_Skagerhult. It is a massive dataset (around 320 data items), and I’m a bit puzzled about how to translate it into the openEHR model. I’ll start a new thread to describe the full scope of the issue :sweat_smile: Cheers, Olha --- ## Post #14 by @davwet Hi, In Region Östergötland, Sweden, we have resumed work on modeling echocardiography measurements. We have been in contact with Basel but sadly their work is on hold for the time being. But their work has inspired us a lot. We have some questions that we hope to get answers or guidance on here. Regarding anatomical localization, how deep should we go with specialization archetypes? That a measurement concerns the left ventricle, where is this best expressed? With a new specialized cluster archetype for the left ventricle or in an attribute in a more general imaging examination of the heart cluster archetype or with precoordinated concepts? Then regarding different modes/views/methods for each measurement. Each measurement can be done in different ways, in different modes such as 2D, from a specific view such as PLAX and with a special method such as biplane. Where should this be expressed? In the observation archetype one level up from the cluster archetype? This is specific information for each individual measurement parameter, not to the examination as a whole. Can it be expressed as a separate cluster under each measurement parameter? Or should we stop trying to model it and use pre-coordinated codes to express this more detailed information. A related question concerns how to specify which phase the heart is in during the specific measurement? Or if this also is better handled by a specific attributes tied to precoordinated concepts. Another avenue we have considered is whether we can take inspiration from the spirometry archetype that uses runtime name constraint. But maybe this is outside of the current design pattern of imaging archetypes? Measurement example: IVSd - Interventricular septum thickness at end-diastole, measured with **M-mode**, PLAX IVSd - Interventricular septum thickness at end-diastole, measured with **2D**, PLAX A standard examination in Sweden might contain about 20-30 measurements and there are about 80 measurements that are could be of interest for our clinicians. Kind regards, David --- ## Post #15 by @siljelb [quote="davwet, post:14, topic:6327"] Regarding anatomical localization, how deep should we go with specialization archetypes? That a measurement concerns the left ventricle, where is this best expressed? With a new specialized cluster archetype for the left ventricle or in an attribute in a more general imaging examination of the heart cluster archetype or with precoordinated concepts? [/quote] I think this depends on the information requirements at each level. If the left ventricle is ever examined in isolation *and* has its own set of unique attributes that need to be recorded, I might choose to make a separate specialisation. Otherwise I think keeping it all in one “Imaging examination of the heart” archetype is likely a better choice. [quote="davwet, post:14, topic:6327"] Then regarding different modes/views/methods for each measurement. Each measurement can be done in different ways, in different modes such as 2D, from a specific view such as PLAX and with a special method such as biplane. Where should this be expressed? In the observation archetype one level up from the cluster archetype? This is specific information for each individual measurement parameter, not to the examination as a whole. Can it be expressed as a separate cluster under each measurement parameter? Or should we stop trying to model it and use pre-coordinated codes to express this more detailed information. [/quote] Are the measurements expressed using the same set of parameters in other modalities relevant for an imaging examination of the heart? If so, could they be modelled as one element per relevant permutation of the parameters, so that they’re easily comparable across instances without having to align a full set of parameters in a query? So in your example, each of the two would be a separate element? --- ## Post #16 by @Lars_Fuhrmann I’m not a cardiologist, and I would trust @siljelb ‘ s judgement over my own, but I think will face similar challenges in eye care (we do ultrasound, too!). So I thought I might share my thoughts. If anyone is free to share a list of cardiac ultrasound parameters in question that may be helpful! * The Archetypes families seems to draw a line between imaging- Vs. nom-imaging based measurements, but in ultrasound that line can be blurry. Not sure how strict we should be about it? Blood velocity measurements based on Doppler curves are still sort of image based, but A-scan scan ocular ultrasound is a one-dimensional measurement. You can display that in a graph, but not an image. Also, the same concept may be measured by either imaging or non-imaging methods. Ocular axial length could be measured by CT (Image-based), A-scan ultrasound (non-image based), B-scan ultrasound (image-based, not precise), optical biometry (non-image based). From what I understand cardiac output could similarly be calculated based on imaging and nom-imaging based methods. Am I wrong or would the current CLUSTER pattern force a duplication of these parameters, once within the imaging CLUSTER Family and once outside of it? I seems to me such variables may be best situated in CLUSTERs that can be used across imaging and nom-imaging Observation Archetypes? Maybe sometimes it may be helpful to draw a line between morphometric (like axial length) and functional (like cardiac output), parameters? Would seem less method-dependent to me. * The probe would not be oriented different ways at the same time, and the special modes are (I expect) mutually exclusive. This is reminds me of similar to the distance at which a Visual acuity chart is shown, it is never 35cm and 5m at the same time. We could argue that the *state* of the examination is changing and each instance of that being a different event? When drafting the visual acuity Archetype we found it helpful to move such parameters to the “state”, so that they may change over time from event to event. perhaps adding an element or slot for “Mode type” or “ultrasound probe position” in the state of the imaging examination result archetype may be helpful? It does overlap with the “technique” element in protocol though. And it may not work with regard to the DICOM/imaging study structure. * I initially thought precoordinating pulse-related timing (end-diastolic etc) would be unproblematic, but I’m not sure if there are edge cases where the pressure cycle works differently. Have you considered how this would work in patients with an LVAD? Are there exceptions to the end-diastolic/end-systolic pattern? Having the pulse related timing in a separate element may be the “safer” option.. Apologies if this is not making things any simpler, feel free to ignore if it is not helpful. I’m just trying to wrap my head around how these patterns can work across different specialties… --- ## Post #17 by @heather.leslie Hi David, It is hard to answer such specific questions without understanding all the requirements. You are modelling a very complex domain. As @siljelb noted, it depends. Not to be difficult but the principles she outlines are a very useful starting point. The current Imaging of the heart CLUSTER is intended to be used for all modalities, a single source of consistent data, not just for echo, so any changes to this need to keep this in mind. It is conceivable that after investigation there are data elements that are only echo-specific and if this blows out the size of the archetype or creates confusion within this single archetype or there is a need for reuse in other contexts, it may be useful to create an ‘echo-specific’ CLUSTER. This will require analysis of all heart imaging and the detail of the echocardiography domain before we can make any recommendations as to the best approach. The phase of the heart during recording is complex. In general this is necessary for correct interpretation, so should be recorded as part of the state of the patient. This indicates to me that it may be necessary to consider specialising the Imaging OBSERVATION to support specific heart phase in State, unless the ‘Confounding factors’ in the current archetype can represent it well enough. Then you can reuse the data/state event group combo (0..\*) if the protocol is consistent. If anything in the Protocol differs between the measurements, then a new instance of the archetype should be recorded. I’m guessing this might be necessary to document the difference between measurements taken using a different technique or procedure such as 2D PLAX or M-mode. If multiple modality imaging exams are done in a single session, then they can all be recorded as part of a single report. The use of Run-time name constraint in Spirometry works because they are measurements made using the same device, the same state, and the same protocol. But it appears echocardiography, is more complex. Hope this helps, Heather --- ## Post #18 by @Lars_Fuhrmann Hi Heather, Currently neither the Physical Examination nor the Imaging Result OBSERVATION Archetypes have a SLOT in **state** that allows for CLUSTERed reuse of state parameters. Would that maybe be quite a versatile solution? Then there could be a “cardiac ultrasound probe position” CLUSTER, and a “ophthalmic ultrasound probe position CLUSTER”, “pulse Phase CLUSTER” each of which would be reasonably concise and have it’s own review/publishing cycle. This would get especially interesting when we consider that some of these state parameters may be required both for imaging and for simple examination findings family. Sorry to pick another eye care example, but “gaze position” (patient looking up, down etc) could be a relevant state for photos documenting the eye motility (in the imaging family) but also for some simple observations such as Lid aperture height (in examination family). Lid aperture height in relation to gaze position is pretty important in [Duane Syndrome.](https://en.wikipedia.org/wiki/Duane_syndrome) It is also probably worth considering [Stress Echocardiography](https://www.escardio.org/static-file/Escardio/Subspecialty/EACVI/position-papers/EAE-stress-echocardiography-expert-consensus-statement-slides.pdf) as a not-so-rare special case, so exertion level also seems relevant, and it already has a cluster… --- ## Post #19 by @heather.leslie Hi Lars, This is another pattern to investigate and solve - is it best to specialise or add CLUSTERs. There are pros and cons. The level of exertion is a valid use case as you rightly point out, but it was modelled as a group of reusable data points and has reusability utility in many ENTRY level archetypes, so the decision to make it into a CLUSTER made sense. If there is an echo specialisation it could include a SLOT for exertion and the cycle phase and potentially for the other parameters you suggest. The alternative is to develop CLUSTERs for these ‘extensions’ in state, data and protocol. Then assembling a template with all of these components might be quite difficult, especially for new modellers. For ophthalmology we could add ‘gaze position’ and others directly to a single Physical exam specialisation OR add a variety of CLUSTERs. This is what we need to balance - utility from reuse is paramount but there are many factors that need to be considered including modeller confusion or increased (?unwarranted) variation in modelling. Reuse for reuse’s sake is not ideal either. Historically, we tend not to create an archetype for a single data element, although technically it is possible to create an ELEMENT class. So far we discovered that if we built an archetype with one data element, someone inevitably asks for a ‘Comment’ etc, so it all breaks. Regards Heather --- ## Post #20 by @davwet Thank you @siljelb, @Lars_Fuhrmann and @heather.leslie for your answers and informative discussion! Thats a lot to process and we will get back to you. Hopefully we will have a mindmap over the parameters we want to capture to share with you later this week. We will also bring your questions and thoughts to the clinicians we are working with next week. --- ## Post #21 by @davwet Our preliminary understanding is that one might examine only a specific part of the heart in an examination in some cases. But the standard examination is much broader. Some of the attributes are unique and some are not. For example, the attribute list for left ventricle differs from the list for the right ventricle. If this is because of clinical relevancy or structural differences, we will have to ask the clinicians. Concerning the question about measurements in other modalities one can in at least some cases measure the same thing using MR for example, but the measured result will vary. I’m not sure which if any parameters that concerns state and protocol corresponds across the modalities. We will have to ask the clinicians here as well. --- ## Post #22 by @Lars_Fuhrmann Thanks @heather.leslie , good to know that those options are on the table ;) I think because ultrasound probe position is relevant across nearly the whole body it is really interesting to think about how it will work in general.. Not only does the probe position use 4-6 degrees of mechanical freedom depending on the organ , but the terms used to describe the positions (or views) mix references to general anatomical planes (saggital plane view…), clock hours (eye), anatomical structures (apical 4 chamber view). Plus where one “area examined” starts and another begins may be a bit unclear, say looking at a bit of the diaphragm/pleural space/lung as part of a liver ultrasound would be expected, i think finding a bit of pleural effusion would not be super rare in abdominal ultrasound exams. SNOMED CT does have specific qualifier values for specific [cardiac imaging views](https://termbrowser.nhs.uk/?perspective=full&conceptId1=399043000&edition=uk-edition&release=v20250730&server=https://termbrowser.nhs.uk/sct-browser-api/snomed&langRefset=999001261000000100,999000691000001104) which may be useful inspiration for @davwet and i guess often onse such value to describe probe position may suffice? In DICOM the “View Name Attribute” (0008,2127) seems to *basically* be a short string if I understand it correctly. However, the [DICOM controlled terminology](https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_d.html) contains lots and lots of (precoordinated) cardiac ultrasound terms including some view descriptions, not sure how much they are used in practice but I am sure a lot of thought has gone into them. A pearl here is that the apical 4-chamber view acutally gets split up further into into “RV focused” (130681) and “modified” (130682), based on a [consensus statement](https://watermark02.silverchair.com/jey042.pdf?token=AQECAHi208BE49Ooan9kkhW_Ercy7Dm3ZL_9Cf3qfKAc485ysgAAA14wggNaBgkqhkiG9w0BBwagggNLMIIDRwIBADCCA0AGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMj8OjiqxNqOKjVvPpAgEQgIIDEfBjZzpbLhD_IskgU8GfVgcHVa17wuRZJXnjB3b_ah8T9D4fzsvjo9yiHC1G7URe6A7DGeK7dZWdgh6rmSF-wSgn1RuFJcaDnpPPPLYnvZnFk7C_49aRwRMaIYgVj8v_c2nDM6h7XqaSEpbdBkPkIzB7HEjveB4D1cICi6iJP1_27arZ6_QFsRvokHriw-ZuEh4zOu9LWoF4jWjDphrnRNp-iscOC5wSm4usogfDs5vLHn1Ix5EDb-i1yjUTmsHzz7pNvrE5laNP1E8HoK50RPkjP3YKer8diKnpBlKTH3F0Hy570cuZzb0LiGocKrApX5CjQnsZQco7BFItdTR7zNkMg3UZCM866vsJB95mwRWx8TU_NKfgxZfj03Txs785ZVeaRPznD5sn84Cf5klLjecLRQYvncTI8PxRAzlB-_bzDx1XWzEj7Fuw5DJ9NDS63XAyIN2N1zNdApH-Chq9LIkV-E10mMT9-MVQdmrVYoIVDyzcfjU-gH4KRcz6iVF-lIdi2n3djNiLFG_um-38SinU0GbBh6T229a83jLLfp0RAuCCFRSk_0RzqKU5jSEdqPcPJDqi_ROpRKcIIKTvjp1-kvjG1kMYlA2KpGmMQhJS5L8f7owc8_uTRbMO_jaX_kRlg1iVwDu0NY1w-9hJZ7OWdIN5ww1JDFbN4lh9MDFfqTLdyHUdVR-HW1r4W-ZUVJyJjN1ywOmVOk3WdDQ4VKGVkV1tNmXRe3ZwvN0K_MiYNpCKcOlCRhZdehzm6HEHOvXvGlZvjdppobG248aVacgPXb82SNC2OSbcDlXnNSlcomBRGu5g10TVRu8Mj4Um_GK9Rxxo0r9ZgF4ovzJtBnDmmVoK3iGZqaNRRqQ2j5fCbr25Q43PGq9IUPAxKsW1pbGeDIbAPK580YwHTbMKmZL-Hq8KN7cDnqEwIEBWCUiTTJoChM9ulRnCy4tqt1oO4-A7bacVurOXxeOwgbxJvz-hHYR5zRyb5KiyP9U8E6yQV1QST9I8wb1BFBGOrcycEa5k32tCp6yPGc_aQb-3db4g). What a rabbit hole, I need to get out, now! :wink: --- ## Post #23 by @davwet We would like to invite you to a workshop to discuss the modeling of the archetype(s) for imaging examination of the heart. Would any of you be interested in participating? We think it would be easier and make us arrive at our goal faster than only continuing the discussion in this thread. Just throwing out a date, how about 9 October sometime around 08-12 CEST? In the meantime we have some additional questions: **General modeling question** When modeling an archetype, should you constrain the modeling in a way that makes it difficult or impossible to implement it in a way that does not correspond to an actual state in reality or do you leave it open for the person implementing the archetype to make a judgement about what permutations are acceptable? For example, leaving the possibility to set attribute A to X and attribute B to Z even though that specific combination is practically impossible. **The combination of the imaging observation archetype and the cluster archetype** How do we best handle the combinatorial explosion (with reservation that we have misunderstood the discussion above) when we then configure the template based on the pattern discussed above, i.e. handling cardiac cycle phase in state and view and mode in protocol. As we understand it, we would need many observation archetypes in our template with different combinations of values ​​for attributes for mode, view, method, exertion and cardiac phase. Instinctively, the resulting template feels counterintuitive with one observation with all the measurement done on 2D images in biplane view at the end systolic point in time and another observation for all measurement done on 2D images in single plane view at the end diastolic point in time etc. etc. The structure will probably allow for powerful yet easily understood queries but the templating would probably need a complementing implementation guide. > Are the measurements expressed using the same set of parameters in other modalities relevant for an imaging examination of the heart? If so, could they be modelled as one element per relevant permutation of the parameters, so that they’re easily comparable across instances without having to align a full set of parameters in a query? There seems to be some overlap, e.g. regarding views even though the value set for the parameter may differ. We have to continue study the possibility of precoordinated elements that work across all modalities. We think that we should build clusters per structure. Partly because of previous reasoning that you might only examine specific parts or a few parts of the heart and that the selection of measurements differs between these. But also because when analyzing the results, you most likely look at each part separately. We attach an excerpt from our work in progress, the variable list, a mind map of all variables and a picture of the observation and the new cluster archetype(s). ![image|690x122](upload://iXhxQ94Di5OTHNi8XTu6lXcbDyC.png) ![image|690x344](upload://cPTAIewuaYxwTBwD6bdkVGbV6bU.png) ![image|690x373](upload://xbXY3IVH4YMcoUnVJGAcCd3FcV8.png) --- ## Post #24 by @Kanthan_Theivendran This looks interesting. There is colleague I recently met doing heart scans in Wales (UK). Her name is Emma Rees: https://www.linkedin.com/in/emma-rees-b38566368/ Her email is: **[e.rees@swansea.ac.uk](mailto:e.rees@swansea.ac.uk)** Emma would be interested to join this Cardiology archetype/template group. Could you send her an invite explaining the aims of this collaboration. Emma doesn’t know anything about openEHR apart from my elevator pitch (actually a transfer bus from terminal to plane pitch) a few days ago. --- ## Post #25 by @davwet Thanks @Kanthan_Theivendran ! We will contact Emma. --- ## Post #26 by @heather.leslie Hi David, It’s difficult to provide a definitive response to such a complex modelling question via this forum. You're working in a space that, while we’ve tried to anticipate it in the design of existing archetype patterns, remains relatively unexplored in practice. I don’t yet have direct modelling experience with this level of anatomical and physiological detail, and I can’t know what I don’t yet know. To provide a thoughtful and appropriate response really requires a deep understanding of the context and specific requirements. Ideally, that would be through a face-to-face workshop over the course of a day, where domain experts are directly interacting with modellers. Translating language adds another layer of complexity that makes it even harder to give immediate or accurate feedback. From first principles, I can say that we don't typically create specialisations for left and right sides of a structure separately. So, if we need an archetype for imaging examination of a ventricle, I’d expect only one archetype, with the laterality (left or right) represented using the 'Body structure' element. This is consistent with how we approach other paired anatomical regions. To do complex modelling justice, even with a solid understanding of the clinical background, it is common to enter a significant phase of exploration. There is usually a period of trial, error and iteration before the optimal approach becomes clear. In Australia, I often describe this as “going down a deep rabbit hole” and hoping to eventually find my way out. I’m not sure if that analogy translates well, but it feels apt. This is a normal part of my process, even with extensive experience. Each new clinical use case presents its own conundrums and we rely on existing patterns to support solving the next one. But your situation has little existing for us to leverage at this point in time. At this stage, I do think it would be valuable to have guidance from senior modellers or CKAs to ensure your work aligns with CKM modelling patterns and has the potential to contribute meaningfully to the shared archetype library. Unfortunately, we don’t yet have the resources in place to fully support that kind of mentoring or review. I wish it were different. As a first step, perhaps consider collaborating around and sharing a mind map or structured outline that captures what data you would expect to record for each specialisation or structure. This might help clarify why a separate archetype may be justified, or whether your needs can be addressed through templating or compositional approaches. The complexity of phases of the heart is another layer on top of the basic identification of CLUSTERs required to correctly represent the structures that need to be imaged. I hope this helps you make some progress. The more collaborative your approach, the more likely it is that the modelling requirements will become clearer. From there, we can hopefully work out a way to support translation into the correct scope for each of the archetypes that follow the established patterns. This is important work, and thank you for your efforts. Kind regards, Heather --- ## Post #27 by @Lars_Fuhrmann Hi David, thank you for suggesting a workshop, I would be generally interested but can’t make it this Thursday i’m afraid and will be too busy in the next month. If you are in Barcelona next week please do reach out. [quote="davwet, post:23, topic:6327"] **The combination of the imaging observation archetype and the cluster archetype** How do we best handle the combinatorial explosion (with reservation that we have misunderstood the discussion above) when we then configure the template based on the pattern discussed above, i.e. handling cardiac cycle phase in state and view and mode in protocol...... [/quote] I think part of this is just the nature of the beast that we are grappling with, we just can't change the fact that us clinicians are controlling 3-10 distinct variables at the same time, and may change 5 of them from one measurement to the next. It reminds me of my visual acuity work, where , within seconds, we like to change the chart used, distance tested and type of correction/glasses, all of it in ways that are hard to predict when writing a template. Not sure if precoordination in the archetypes would be a good idea, I think it is necessary to avoid a cartesian explosion and to maintain reusability across different modes of measurement/imaging. Maybe it may be sensible to question whether you really need to predict all variable combinations at the template level? To make the rather complicated visual acuity archetype implementeable I have been considering if the templates could be kept quite liberal, both in terms of the number of events/observations and combinations of variables they contain. Because I have no Idea how many VA tests the next patient will need and with which combination of variables. In order to ensure the right variables are used in combination with one another precoordination may still be useful, but what if that is only performed at the front end/application level and neither the Archetypes nor the template? I am imagining a UI where all those variable have been precoordinated, so there is just a single field for something like "right ventrical volume in 4 chamber view at the end systolic point", but after being entered and before the composition is written this gets mapped out into like 3 elements. * Body site: right Ventricle, * View: 4-chamber, * Pulse Cycle timing: end systolic. All of which on the complicated different paths that suit the rather liberal template. So in a way this would be having both the precoordination and the rules just in the front end, not the template. My hope is this could both make templating relatively easy and keep clinicians from having to fill in 5 drop down menus for a single observation. This may or may not be problematic as the data is not saved exactly as seen by the user, but maybe it is an option somewhere? Again, I'm just sharing my thoughts as because we have similar issues in eye care, not because I think that I have the perfect solution for them.. --- ## Post #28 by @davwet Hi Heather and thank you for your answers. Our modeling efforts are part of a larger project where we are building a registry of clinical physiology data and we will be working with this throughout this and the next year. So hopefully we can come to a point where we can collaborate internationally more closely. We will continue to share the results of our exploration here. I will attach a mind map of an echocardiography measurement. ![image|690x304](upload://6PaZV0VnmQeAScap5sgInZn7gS1.png) [quote="heather.leslie, post:26, topic:6327"] From first principles, I can say that we don’t typically create specialisations for left and right sides of a structure separately. So, if we need an archetype for imaging examination of a ventricle, I’d expect only one archetype, with the laterality (left or right) represented using the ‘Body structure’ element. This is consistent with how we approach other paired anatomical regions. [/quote] Is this approach viable even when there are functional and structural differences between the paired anatomical regions? I know to little to argue either or, I’m just asking out of interest. Kind regards, David --- ## Post #29 by @davwet [quote="Lars_Fuhrmann, post:27, topic:6327"] Hi David, thank you for suggesting a workshop, I would be generally interested but can’t make it this Thursday i’m afraid and will be too busy in the next month. If you are in Barcelona next week please do reach out. [/quote] We are working in a project spanning this and next year so hopefully we can find an opportunity to collaborate. I will not attend the conference but my collegue @Asa_Skagerhult will. [quote="Lars_Fuhrmann, post:27, topic:6327"] Maybe it may be sensible to question whether you really need to predict all variable combinations at the template level? To make the rather complicated visual acuity archetype implementeable I have been considering if the templates could be kept quite liberal, both in terms of the number of events/observations and combinations of variables they contain. Because I have no Idea how many VA tests the next patient will need and with which combination of variables. In order to ensure the right variables are used in combination with one another precoordination may still be useful, but what if that is only performed at the front end/application level and neither the Archetypes nor the template? I am imagining a UI where all those variable have been precoordinated, so there is just a single field for something like “right ventrical volume in 4 chamber view at the end systolic point”, but after being entered and before the composition is written this gets mapped out into like 3 elements. [/quote] I like this thinking to keep the template simple and let the front end/application coordinate it into a more complicated composition. This might be close to how we actually will do it in our use case as we will transform the measurement from our echocardiography PACS into openEHR format. Kind regards, David --- ## Post #30 by @heather.leslie [quote="davwet, post:28, topic:6327"] Is this approach viable even when there are functional and structural differences between the paired anatomical regions? I know to little to argue either or, I’m just asking out of interest. [/quote] Off the top of my head I can’t identify data elements/questions that are different between left and right but my anatomy study was a long time ago. Of course, the values/answers may differ immensely that’s why we will specify the structure clearly as left or right ventricle. I’m happy to be proven wrong but there is at the very least a huge amount of commonality and I’ll be interested to understand your reasoning to separate them. And of course the interventricular septum thickness is common to both left and right so should be recorded once within a higher level concept. --- ## Post #31 by @davwet Yes, you are correct. There are no differences that would affect the data elements. There are structural differences that make certain assumptions invalid when calculating specific values using particular echocardiographic methods. But such assumptions are not necessary when using MR. It has now been a month. I’ve been away from work for a couple of weeks, and since returning, we’ve made some progress in our analysis and modeling. To make it easier to share this with the community, here is a link to our GitHub page where you’ll find our documentation (README.md) and models: [https://github.com/regionostergotland/CKM-mirror-via-modellbibliotek/tree/AP3-ekokardiografiregister](https://github.com/regionostergotland/CKM-mirror-via-modellbibliotek/tree/AP3-ekokardiografiregister) --- ## Post #32 by @davwet @heather.leslie There is a Imaging examination of the heart archetype in the Public health surveillance incubator that was uploaded by you last year. How should we approach this? We are currently looking more at measurement values and yours is focused on findings. --- ## Post #33 by @Lars_Fuhrmann Thanks for sharing @davwet, I really like your readme and mindmaps, I have not had the chance to look at your drafts in detail, but I still think we share the problem of how to handle concepts that can be measured both with imaging and non-imaging methods. For you I assume things like the aortic valve pressure gradient could be measured using both imaging and non-imaging (invasive) techniques. I’m facing similar dificulties concerning things like central corneal thickness. Am I right to think that with the current structure you would end up with one “aortic valve pressure gradient” element in an imaging CLUSTER another “aortic valve pressure gradient” element in an cardiac catheterization OBSERVATION? So MRI and Ultrasound would feed one element and catheterization would feed another - is this better than trying to reuse the same element across them using a method-neutral CLUSTER? Maybe it depends on how thick the line is betwen an imaging-based and invasively measured result in the minds of cardiologists? Would they rather look at this as different measurements of the same “thing” using two different methods, or two different things? --- ## Post #34 by @linforest [quote="davwet, post:28, topic:6327"] mind map of an echocardiography measurement [/quote] @davwet Have you considered shifting some of the modelling complexity to terminology(ies) such as LOINC? For example: [LOINC 79988-2 Left ventricular posterior wall Time to peak displacement during systole by US.M-mode+ECG](https://loinc.org/79988-2/) ![image|690x424](upload://6OOmPt3lCyWJ0gQNwFtEi06saYd.png) --- ## Post #35 by @davwet [quote="Lars_Fuhrmann, post:33, topic:6327"] Am I right to think that with the current structure you would end up with one “aortic valve pressure gradient” element in an imaging CLUSTER another “aortic valve pressure gradient” element in an cardiac catheterization OBSERVATION? So MRI and Ultrasound would feed one element and catheterization would feed another - is this better than trying to reuse the same element across them using a method-neutral CLUSTER? [/quote] Yes, you are correct. In the current structure we would end up with one element for imaging observations and one for catheterizations. We will look into if a method-neutral solution would be prefereable and possible. It seems as if pressures are the only parameter that could be measured using a different method than imaging. What does this mean for the method-neutral cluster? [quote="Lars_Fuhrmann, post:33, topic:6327"] Maybe it depends on how thick the line is betwen an imaging-based and invasively measured result in the minds of cardiologists? [/quote] Concerning the result of measurements of pressures, echocardiography is described bythe BMA in our project group as good enough for clinical use but the gold standard is catheterization. But catheterization is very uncommon. --- ## Post #36 by @davwet Hi @linforest! We are considering whether to use LOINC in some capacity in the wider scope of our project. For example as a help to map the measurements into openEHR format or to terminology bind our openEHR templates using LOINC. The concepts seem to be too precoordinated to be used in an archetype though, based on how we currently think about the modeling of the archetypes. --- ## Post #37 by @heather.leslie Hi David, Many measurements are findings in my world. But how we represent them differs depending on the requirements. The distance from A to B by itself can be a single data element or length, width and circumference of a finding could be a single SLOT that reuses the [CLUSTER.physical_dimensions](https://ckm.openehr.org/ckm/archetypes/1013.1.7812). However if the measurement needs to be represented within a specific context then it may need to be represented as a discrete archetype. See the [Intraocular pressure archetype](https://ckm.openehr.org/ckm/archetypes/1013.1.1369) which has just gone out for review. Maybe some would frame this as a ‘test’, but it has state-related data that needs to be associated for correct interpretation so it requires it’s own archetype. Visual acuity and visual field measurements will be the same. Hope this helps Heather --- **Canonical:** https://discourse.openehr.org/t/cardiology-templates-and-archetypes/6327 **Original content:** https://discourse.openehr.org/t/cardiology-templates-and-archetypes/6327