Ankle brachial pressure index

We’re looking for an “ankle brachial pressure index” archetype.
We did not find anything in CKM. But we did find such an archetype in norwegian ckm by @siljelb.

I wondered why the pressure measurements are part of the archetype. In my opinion the brachial pressure would best be recorded as observation.blood_pressure. And the ankle pressure as OBSERVATION.intravascular_pressure (since it’s not a surrogate for the systemic arterial pressure). Similar to BMI.
I would be interested to discuss adding references to the values used to the observation.ankle brachial index archetype, probably as DV_EHR_URI, under the protocol section?


Hi Joost! This archetype was imported based on this proposal back in 2017, and has been sitting there untouched since then.

I don’t have any strong feelings about the modelling pattern, other than the fact that both the upper arm and the ankle are measurement locations included in the OBSERVATION.blood_pressure archetype, and should therefore both be possible locations to measure a surrogate for the systemic arterial pressure? I’m not sure what the difference is between an ankle systolic blood pressure which is measured as a surrogate for the systemic arterial pressure, and one which isn’t?

Yeah, I saw the obs.bloodpressure has an ankle measurement location.
The (main?) indication for taking a ‘ankle brachial pressure index’ is suspected low (regional) blood pressure in the foot, as part of suspected peripheral arterial disease. So the ankle pressure has a high chance of not adequately reflecting the systemic blood pressure when taken as part of a ankle brachial index.
If we agree on this, maybe we should add a comment to the obs.bloodpressure. (if even one of the most experienced modellers doesn’t think of this, we can’t assume regular modellers do.)

I agree. Though also perfectly valid to use the ankle pressure as a systemic pressure (assuming we are confident that it is not compromised by peripheral; disease).

I bet the banks don’t have to think of this sort of thing!!


Hi Joost,

today I came across a somewhat related question and maybe this deserves its own thread (of course only if I did not miss an existing discussion), so sorry for bringing this up in this context.

There is a relatively common pattern where an observation like heart rate is part of an assessment. I have an example here:

The Rockport Fitness Walking Tests sounds like it should be its own observation archetype but I would still like to find all heart rate measurements using the known paths from its own archetype. Would we design a corresponding template in a way that would store each value twice, inside the Walking Test and a referenced openEHR-EHR-OBSERVATION.pulse.v2 entry?

I was about to say that ls what I would do, as very often there is some kind of overall score or calculation, associated.

However , in this case, the Rockford Fitness Walking Test (on the basis of the screenshot) is really just a repeated simple heart rate observation but against a specified set of events and overall protocol.

So, I think I would use the Observation pulse archetype with multiple events (one per lap) and document that it was carried out against the ‘Rockford test protocol’


Yes I think this is the correct approach. It’s like doing an ECG, which could be done with different protocols: at rest, Bruce protocol (treadmill) etc.

Main thing is that the OBSERVATION.state or else the EVENT.state includes a representation of the patient state, so that like samples can be compared with like e.g. ‘at rest’, ‘walking 5kph’ or whatever.

Nice question.
Agree to template on obs.pulse making sure to faithfully record state. And not recording the values twice. However I do feel there should be a specific Rockport fitness walking test observation. However what goes in there I’m not sure. Maybe a list of links to the individual obs.pulse?
It makes me think about the citation problem.
To me it btw is a very different problem from the ankle pressure, because there it’s a conceptual mismatch: the obs.bp concept is a measurement of the systemic arterial pressure, while ankle pressure is not expected to reflect that in this test. While here it’s about a special state for measurement pulse, while still trying to capture the same concept of a pulse. And additionally how to template/archetype tests containing elements that are an archetype in itself.

An additional note (less relevant to your research oriented highmed project) is that recording pulse data like this makes it extra important to carefully construct AQL queries for e.g. a vital signs dashboard: do you want pulse from test scenarios like this to show up there? (I don’t have an easy answer). The important think to me is to be mindful of user expectations. How do you show the user that some pulse observations have been recorded in a special state? Possible solutions are plenty: filter out of vital signs dashboard, distinguished colouring of data point in graph, annotating using symbol etc. Etc.

My understanding of the requirements is not to record the pulse per lap but to record the pulse rate at the time of completing a 1-mile walk or jog at submaximal and an undefined level of exertion PLUS the time it took them to cover the distance. That puts quite a different tilt on the modelling IMO and potentially segues into modelling other activity-related records such as from fitness devices - activity, duration of activity, distance or repetitions completed, heart rate/max heart rate etc - ping @erik.sundvall. The laps seem to be a red herring and probably only a local (form-related) requirement where the 1 mile is comprised of multiple laps of an athletics track or sports field.
The formula used to calculate the predicted VO2 max varies depending on male/female and requires knowledge of weight and age. Predicted VO2 max should probably be recorded separately as we know there are at least 2 ways to calculate it and it is likely that the measured VO2 max should also reside there.


Thanks everybody for providing such valuable input, I had the suspicion this could be a bit tricky.

@ian.mcnicoll: my concern would be that having very sophisticated constraints on the template level would make it unlikely that people would come up with the same representation twice, making interoperability unlikely.

@joostholslag: the thing is that HiGHmed is not really about research, but evenly about standardized medical documentation in care. Hence, we are pretty much concerned with the questions about “best practice” in our clinical application systems.

Regarding the question of data retrieval: this is really the philosophical question if the Archetype should be used to capture all pulses. My gut feeling is that it should be shown and we need to explicitly exclude certain protocols (as mentioned by @thomas.beale) if these are not relevant for a use-case. If we ask “give me all pulse measurements of a patient” these should certainly be included (even if the question might be naive).

@heather.leslie: thanks for your analysis, this makes lots of sense to me. Would you say that besides all the details around state/protocol etc. this would still be a “proper” pulse measurement?

1 Like

After reading @heather.leslie 's excellent analysis, I agree that a separate Observation is more appropriate. Partly because of the complexity of constraints but more because the circumstances of the test require very specific conditions.

I would now say, on the basis of Heather’s analysis see these are not “proper” pulse measurements in infomation terms.

To partly address @joostholslag concern that “These are still pulse rates”, it might be good to think about how we could flag certain key elements in Observation archetypes as being independently queryable via a coded name e.g a SNOMED mapping. This would also help some issues we have in hooking up to other formalisms like FHIR Observations which are driven by this kind of coding. I know @Bna has been partly down this road

In theory we should be able to query on ELEMENT (just as we can already do directly on CLUSTER) but I understand this might be challenging to make this work for every ELEMENT. So could we tag a subset of ELEMENTS as e.g Observable , saying that these are key data items that should be queryable directly by SNOMED code independent f the parent OBSERVATION archetype?

Something like

select o from EHR CONTAINS OBSERVATION o CONTAINS ELEMENT el WHERE el/name/value/ mappings/target/code_string matches {"snomed-ct::123456}

I realise there are issues with mixing up context, so these queries would have to be used carefully, perhaps mostly for research, integration or data quality fixups.


That’s why ‘health informaticist’ is not on the list of 20 most likely professions to be replaced by AI!

This is the thing to be careful of and why there is ‘state’ (= patient body state) in the Observation and History structures. To create a clinically valid graph of data points (or do any valid CDS calcs), the state values have to match or be comparable. Comparability is something like : you can only compare exercising HR with other exercising HR and resting HR with resting HR. HOWEVER: there are good reasons to compare running and resting HRs - much sport medicine does that.

Similar example of comparability when state is not identical: OGTT glucose values with state = fasting | challenge +1hr | challenge +2h. So here the body state is intentionally different (there is a 75g glucose challenge), but the OGTT protocol is designed to use that, so the comparison of glucose values is correct.

Whatever the queries are, they have to be consciously designed to take account of state according to the intention of the requesting agent (human or software).

I don’t think we have to be 100% religious on requiring that every recorded sample of a certain body signal (pulse, BP etc) use the standard archetype for that thing. There would be little expectation that pulse from the ankle would be treated as a normal (peripheral) HR measurement for general purposes - someone else will measure that separately, and they wouldn’t look at some specialist measurement for VO2max or whatever to find it.

All that we want to guard against is that standard data points that are taken in the context of some particular encounter (e.g. measure BMI) are not unavailable to queries looking for that kind of data point generally. The measurement of height and weight for BMI is no different than for any other purpose - it should turn up in query results for patient height and weight.

This seems like a lot of trouble to go to - and I don’t think it helps in these kinds of cases (maybe there is some other argument for doing that).

1 Like

This is getting a bit off-topic so I’ll create a new conversation.

Totally. These are measurements I’d prefer to have filtered out of any record of heart rate records by embedding the measurement within another archetype, much like other scores and scales. The context of measurement during this very specific activity means I can’t think of a use case where it could be useful to pull these as part of an EHR query for ‘all proper’ heart rates - these are very specific outliers and I’d be very happy to exclude these from any general heart rate query - cleaner data quicker :sunglasses:. Correct me if you can think of a sensible use case. Heart rates can/will exist in other Score/scale models for exactly the same reasons. Let’s be pragmatic and record clinical reality here, rather than modelling purely for pureness’s sake. In reality, not all heart rates are equal and sensible querying needs to be supported. [Usually I find myself arguing the other way but … :upside_down_face:!]
Conversely, in a fitness tracking scenario calculating VO2 max, you are likely want to record more instances of this pulse/distance combo within these test contexts so you can calculate changes in fitness from the algorithm over time. Let’s make it easier for new and non-technical modellers to model this in a consistent way. IMO a dedicated archetype warrants further investigation, even to exploring developing a generic pattern for fitness-related data as I suggested previously. @erik.sundvall has had some of his team/students/colleagues working towards this goal previously - not sure it was ever completed…


We have explored these use-cases where you have some standardised score. NEWS2 is one example where you certainly would like to either add a new vital signs parameter or reuse an existing one. The measurement/observation might have it source from some device and the data is transferred on the wire with any technology.

There are many such use-cases. What would be interesting was to have a non-contextual definition of the concept.

I.e. body weight will consist of a few standard parameters like the weight in kilograms and maybe some other attributes. These could be modelled as a information structure to be reused in other entries.

One example might be a patient with nutrition problems. Maybe the goal is to reach a specific weight. These could be modelled in some instruction or evaluation archetype/template.
Another use of the structure is in an BMI (body mass index) score and as part of a citation.
The fitness test @birger.haarbrandt provide does also use body weight as a number.

I think we could benefit from some modeling like this for the atomic building blocks in the EHR.


On this question of re-using already recorded data, some possible solution concepts here:

NEWS2 is made up of a series of categories assigned from real-life, raw data. There is actually no 1:1 duplication of vital signs measurements. Maybe you’re thinking of another score?

In any case, if we follow the idea of creating reusable CLUSTERs for every data element that might be represented in some way in multiple archetypes then we also have to ask where we stop. A CKM full of ELEMENT archetypes that can be configured in unlimited permutations and combinations? For example, we haven’t modelled a generic and reusable CLUSTER/SLOT pair for each instance of ‘Description’ or ‘Comment’, despite the fact that these data elements exist in almost every archetype. We need to avoid reuse for reuse’s sake, instead opting for utility, clarity and simplicity of data representation. Filling SLOTs to include a description or a comment in every archetype is adding zero value, only modelling and governance overheads. We need the capacity for a free text description and a comment in most archetypes - but I can assure you that there is also zero clinical value in querying ‘all descriptions’ or ‘all comments’.

In addition, if we start to create a multitude of single data element archetypes then we quickly end up with a governance and querying hell, where each measurement may have been recorded in a variety of ENTRY contexts - with the potential for weights to be recorded within non-OBSERVATION contexts.

Other modelling paradigms have previously gone down this ELEMENT modelling road to maximise the flexibility of reuse but have not been scaleable/governable outside the original system silo - we definitely don’t want to replicate this mistake. My discussions with them at the time were about the nightmare governance problem they had with their artefacts and their difficulty on how to train modellers about appropriate use and, more importantly, what was the wrong way to use the artefact. They agreed that openEHR ENTRY/CLUSTER groupings seemed to provide a sweet spot between reusability, flexibility and governance.

With that background for consideration, BMI is often calculated in isolation from the act of recording an actual weight measurement, so the system will need to reference a pre-existing one as part of its’ calculation and presumably record some kind of traceability to the source measurement. If the BMI/score/scale is calculated at the time of recording of body weight, I think the best utility comes from recording the measurement using the ubiquitous OBSERVATION.body_weight, so it can be queried as part of ‘all body weights’ (including state and event/math contexts), and apply a business/technical/system solution for inclusion of the weight value within other archetype/template contexts - either as a ‘citation’, ‘reference’, copy or whatever technical magic you want to utilise to access the original, single source OBSERVATION. This should not be a design issue within a coherent data ecosystem, but one solved by business logic or technical/engineering artistry.

While not all heart rates are equal due to the dynamic (minute-to-minute) changes in the context of exercise or fear etc, I think the opposite almost universally applies to body weight. I’m firmly in the camp that most weights should be recorded and queried in a simple, ubiquitous way. But I’ll also acknowledge that clearly recording weight measurements during episodes (weeks/months/years) of pregnancy or heart failure may add some complexity, and I’d suggest that these scenarios need to be dealt with slightly differently & definitely not solved by a CLUSTERed representation of body weight.

1 Like

I agree that dropping the modelling down to CLUSTER and ELEMENT level archetypes would rapidly become unsustainable.

However, my suggestion around OBSERVABLE ELEMENTSm was not really to suggest that there be modelled indepentently of their parent OBSERVATIONS, but that their constraint pattern could be re-used , and that they could be potentially queried (probably by SNOMED or LOIC codes), and I can see the same applying to some clusters.

I think the GOAL archetype has a some sort of attempt at this by allowing the Target Path to point to a fragment of ADL to identify eg. the units and range constraints for a body weight.

So these are more like virtual ELEMENT or CLUSTER archetypes but modelled and maintained within normal OBSERVATIONS.

One good example, I recently discussed with a client was Inspired Oxygen, which in most case sits nicely as a CLUSTER within the content of pulse oximetry or other ENTRY archetypes but occasionally needs to be a stand-alone OBSERVATION. We can use a generic OBSERVATION container for this but that does feel a little hacky to me - perhaps better if it was built as an OBSERVATION with the ability to ‘reuse’ (and query) fragments of the content in the context of other ENTRY archetypes.?

1 Like

Right. One thing for all of us to remember is that the balance of what is in the RM and what needs to be archetyped is not fixed over time. The background rule for what can go in an RM is: elements that are invariant in the domain, i.e. essentially common to this or that type of information, not matter the clinical specificity. We didn’t get everything right in the RM (of course not), so we rely on experience in the domain modelling space to give us new insight on what data items could be considered ubiquitous. It may well be that some kind of generic ‘comment’ field (optional) is needed in all Entries or whatever. We need to think together (clinical + technical groups) on what these additions might be.

I mostly agree with this as well, but it’s not completely black and white: lab panels are pretty much loose groups of single analytes, which can have their own models - but done generically (i.e. with LOINC coding); but other data complexes are tightly bound and make no sense on their own. No-one measures a diastolic BP only, and data points from Problem/Dx like ‘date of last exacerbation’ make no sense on their own.

BMI does make sense on its own, but is in a category of calculated data points for which we’d like to be able to make a model that shows the input as well as result value in a little group. Apgar on the other hand has input variables that are only measured for the purpose of Apgar (that’s not quite true of course - fetal HR is measured constantly during birth, but the 0/1/2 scoring is Apgar-specific). There is an underlying question always to be asked: are the constituent data elements ever created as a clinical act independent of the specific content I am considering right now? If so, they belong in their own archetypes.

The lesson here in my view is that we need a meta-classification of clinical statement types that indicates the modelling style to be used, i.e. things like:

  • native data group (molecular style): BP, Apgar, Problem/Dx etc
  • virtual data group (molecule with citations of other elements): BMI and some other scores/scales;
  • common data collection - typical lab panels e.g. CHEM7, thyroid, LFT etc
  • standalone element (atomic style) - height, weight, HR, most lab analytes
  • … maybe more

And appropriate technical tricks to make these work.

Yep - exactly the purpose of the proposals I posted above - to do this citing of existing measurements.

Agree 100%

Exactly right in my view.

1 Like

Yes. This is what I tried to describe. There will be groups of data attributes which defines the core dataset. It would be beneficial to be able to reuse those definitions. One simple example is to define a goal of reaching a specified body weight within 3 weeks and then be able to store the body weight when measured.

And the BMI is a similar use case where the weight for an adult will change more often than the height.

There might be several technical ways to achieve this. One could be to have reusable ITEM_STRUCTURES .

No. I was talking about the NEWS2 score. The primary data could be some integration with a medical device and then reused immediately in the calculated score. Or if there are no integration, but still the primary data is recorded in another system, then you might want to to enter the actual value for reference.

These are not the most common use-cases, but they exist.

I agree on this. And in addition it would be nice to explore the capability to reuse ITEM_STRUCTURE definitions which wont put any constraint to a specific ENTRY or CLUSTER class.

We use reusable CLUSTER definitions a lot in our modelling since they provide a great combination of modelling formalism (being real archetypes) and flexibility (might be used in different ENTRY contexts)

1 Like