Modelling of Swe-PEWS

Clinical
1

Hi,

We are currently modelling archetypes for our Swedish version of Pediatric Early Warning Score (Swe-PEWS). To get some early feedback on our archetypes, I want to share them here with you so you can comment. I have also added some background information to our archetypes below.

Archetypes
https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDUyMTVmMjk1YTRjNTRiY2M5YjQyMDgwOGYzOTVkNTNj
https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDZjZmM1NzdhYTdmZDRmNWJhMDE4MGU1YTFmMGYzYTY0
https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJDlmMWIwYzlhMmI1YjQ3ZjI4YjZjMDAxNjUyMTFmNmM0

Swe-PEWS design

  • The Swe-PEWS consists of seven quite simple score cards.
  • Each score card is used for a specific age interval.
  • Each score card consists of 5 respiration parameters, 3 circulation parameters and 3 neurology parameters.
  • All seven score cards are identical, except for the reference ranges for one of the respiration parameters and one of the circulation parameters. These reference ranges depends on the patient’s age.
  • Each parameter gives a score between 0 and 3.
  • The highest score among the respiration parameters, circulation parameters and neurology parameters are summarized to a total score between 0 and 9.

Archetype design considerations

  • The used original language in these archetypes are Swedish, since the Swe-PEWS specification is written in Swedish.

  • An English translation is provided to still keep the international interoperability.

  • Since Swe-PEWS is an adaption of the international PEWS system, the designed archetypes follows the international pattern proposed by the archetypes “Paediatric Early Warning Score (PEWS)”, https://ckm.openehr.org/ckm/archetypes/1013.1.5149 , and “PEWS - simple variables”, https://ckm.openehr.org/ckm/archetypes/1013.1.5167 .

  • The designed archetypes are therefore specializations of the “PEWS - simple variables” cluster archetype.

  • To follow the pattern for the international archetypes, the parameters are modelled using the data type DV_ORDINAL.

  • When the same value in the ordinal scale are used for more than one cases, like both for “≤24” and “≥76”, the same value is used together with two different symbols, like in this example both the symbol “≤24” and the symbol “≥76”. This seems to be in line with general recommendations.

  • The trickiest part of the design is to decide how to model the two parameters that have different reference ranges depending on the patient’s age.

  • A simple solution would have been to exclude the reference ranges from the archetypes and distribute them in some other way. However, the reference ranges needs to be distributed and excluding them from the archetypes would only make them someone else problem. After some considerations it was assumed that it is most appropriate to distribute the reference ranges in the archetypes, because there is already a built in mechanism for distribution of definitions inside the archetypes. This option was therefore rejected.

  • Another alternative had been to insert seven different versions of the two parameters with different reference ranges in the archetype and use the appropriate version depending on the patient’s age. Which version of the parameters to use had been possible to specify on the template level. However, the reference ranges are assumed to mainly be interesting when writing information using the archetype to be able to use the right score based on the patient’s age. When reading information using the archetype the recorded scores are probably assumed to be correct given the patient’s age and the reference ranges are probably of lesser interest. It would therefore be very inconvenient to read and/or query different parameters based on the patient’s age to find basically the same information, which would have been the result if seven different versions of the two parameters had been used in the archetype. This option was therefore rejected.

  • Another alternative is to create one archetype that model everything in Swe-PEWS, except for the reference ranges for the two parameters that have different reference ranges depending on the patient’s age. This archetype is then specialized into one specialized archetype for each of the patients’ age ranges where the reference ranges for the two age dependent parameters are added. This alternative would distribute all reference ranges inside the archetypes and simplify reading and querying stored information. The downside is the increased number of used archetypes than with other solutions. However, tools created to use archetypes are assumed to be designed to handle many archetypes, so this is assumed to be a small issue. This option was therefore selected.

Known issues

  • The Swe-PEWS specification states explicitly that the parameters always should be listed and used in the same order as in the specification. Unfortunately, I haven’t been able to specify that using the ordered ADL keyword in the Archetype Designer.
  • The Archetype Designer doesn’t seem to handle specializations of the data type DV_ORDINAL correct according to the specifications. The specializations of this data type has therefore been done partly manually in the ADL code. This imply that the specializations doesn’t show up in the Archetype Designer’s graphical user interface.

Tooling experience

  • The Archetype Designer gives the impression that the text in the other_details part of description are stored in both a Swedish and an English version. However, the tool only saves the latest entered version independent of language without any warning. This removes translations you have spent time to do.
  • In the Archetype Designer, when I do a small update of a term in Swedish or English, like removing an extra space character, the tool updates the term in the other language for the translation I already had spend time to do with my recently updated term with an addition of an asterisk in the beginning and an abbreviation of the updated language in the end. This is probably a desired behavior before the translation has been done, but not after the translation has been done. Sometimes this ends up in a loop, so it seems to be impossible to do the translation in the tool, because it always updates the term in the other language. When you fix the tool’s unwanted update in one language, the tool do an unwanted update in the other language. This removes translations you have spent time to do.
  • The Archetype Designer allows specialized archetypes to contain language translations that are not present in the unspecialized archetype. The Clinical Knowledge Manager seems to not allow this. I don’t know which is the correct behavior.

Regrads
Mikael

1 Like
2

The Swe-PEWS specification (in Swedish) can be found at PEWS alla kort (lof.se).

1 Like
3

I can help with this: It’s a setting, designed for when you’re governing an archetype over time, and need to make sure that translations aren’t misrepresenting the original language. You can turn it off here:
image

image
image629Ă—514 14 KB

2 Likes
4

Thank you @siljelb! That setting had probably saved me two - three hours! :slight_smile:

2 Likes
5

Hi Mikael,

Thanks for your detailed explanation.

I’d probably take a slightly different approach, albeit one discrete CLUSTER archetype for each Swedish/age specific group content, just as you have done.

I’d suggest that the 3 values related to the highest score are probably part of the process for filling in the paper forms and not required to store in EHR data. So I wouldn’t add them to the CLUSTER. And then the internal cluster headings become redundant as well. Something simpler and more like:

2021-02-17_11-52-33
2021-02-17_11-52-33684Ă—537 25.1 KB

The other thing I think we need to consider carefully about the question of using specialisations. I only use specialisations where it provides obvious semantic value in terms of querying. Otherwise, I avoid them as much as possible. In my experience, they are a maintenance and governance nightmare, far in excess of the theoretical value of replicating patterns. And to be honest, I am troubled by the idea of specialising content in an ordinal and implying semantic constraints through the content of the text.

My preferred approach would be to create a CLUSTER archetype that represents one age group, then clone/rename it and edit the two parameters where the values vary per age, with exactly the same effect as specialisation, but none of the heartache. Rinse, repeat for each age group.

I hope this suggestion is useful to you.

Kind regards

Heather

3 Likes
6

I have read through the discussion here and on openEHR CKM.

The requirements is to model a generic and common clinical concept of PEWS, and with specific logic/parameters for different populations (here qualified by age) .

Based on this I find a modelling pattern with a shared OBSERVATION archetype with specific cluster for each sub-group/sub-population good.

As @heather.leslie suggest I would also make a “stand-alone” CLUSTER for each of the sub-groups. I would not go with inheritance. Reason for this is that I find it confusing in long-term governance. I.e. if the grades for a sub-group is changed. Then it would be more maintainable to have specific models.

Can you provide some more description on why you choose inheritance as a pattern for the clusters?

2 Likes
7

Yes, of cause. I can try explain the details a little bit better.

The Swedish version of PEWS (Swe-PEWS) is designed in a little different way than what I understand that other countries’ PEWS are. Swe-PEWS is made up of 5 parameters related to respiration, 3 parameters related to circulation and 3 parameters related to neurology. Each parameter has a score between 0 and 3 and which score to set is dependent on the criterion for that specific parameter.

For 9 of the parameters, the criterion for each score is independent on the patient’s age (if the age is in the interval 0 – 18 years where Swe-PEWS is applicable). For example, the criteria for the oxygen saturation parameter score 3 is ≤91% and for score 0 is ≥96% independent of the patient’s age.

However, for the respiratory rate and pulse rate parameters, the criterion for each score is dependent on the patient’s age. For example, the criteria for the respiratory rate parameter score 1 is 56-64 for 0 – 3 months old patients and is 50-59 for 4 – 11 months patients. The parameters related to respiration and these parameters’ scores and score criterion are included as examples in the table below.

The criterion for the respiratory rate and pulse rate parameter scores are the only thing that differ depending on the patient’s age.

Parameter Score Critera
0-3 months 4-11 months 1-2 years 3-5 years 6-11 years 12-15 years 16-18 years
Respiratory
rate		 0 25-55 20-49 18-39 18-28 15-25 12-23 12-20
1 56-64 50-59 40-49 29 26 9-11
2 65-75 60-70 50-60 30-33 27-30 24-26 21-24
3 ≤24 or ≥76 ≤19 or ≥71 ≤17 or ≥61 ≤17 or ≥34 ≤14 or ≥31 ≤11 or ≥27 ≤8 or ≥25
Apneas 0 No
1
2
3 Yes
Respiratory
work		 0 Normal
1 Mildly elevated
2 Moderate elevated
3 Excessive elevated
Oxygen
saturation		 0 ≥96%
1 94-95%
2 92-93%
3 ≤91%
Oxygen
delivered		 0 No
1
2 Yes
3

(The total score is calculated by selecting the highest scored respiration parameter, the highest scored circulation parameter and the highest scored neurology parameter and add these three parameters. The total score is therefore an integer between 0 and 9. However, this is not something that is of importance in this discussion.)

To model Swe-PEWS in the best way I assumed it would be to use inheritance. I therefore modelled one general Swe-PEWS archetype that contain everything except for the criterion for the respiratory rate and pulse rate parameter scores since it is the only thing that differ depending on the patient’s age. I then created one new archetype for each age interval 0-3 months, 4-11 months, 1-2 years, 3-5 years, 6-11 years, 12-15 years, and 16-18 years that inherits the general Swe-PEWS archetype. In these age interval dependent archetypes I then only added the criterion for the respiratory rate and pulse rate parameter scores. I would say that this is a general modelling pattern in health informatics.

In my view this approach simplifies the modelling and governance since the main part of the definitions are only included in one archetype. It is then a lesser number of definitions to keep track of in the archetypes and it is known for sure that all age interval dependent archetypes follow the same structure. It is therefore a lesser risk to insert errors if the archetypes will be updated in the future.

This modelling approach also simplify querying since the structure of the stored information is known by only looking at the general Swe-PEWS archetype and the queries can be constructed in a similar way. It would also be even better if AQL supported inheritance questions and I believe that it is something that we need to add sooner than later to simplify the use of information stored according to openEHR. Why not be able insert INHERITED in the query like

FROM
   EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
      CONTAINS INHERITED OBSERVATION obs [openEHR-EHR-OBSERVATION.general_Swe-PEWS_archetype.v1]

and retrieve values that are stored according to any of the age interval dependent archetypes? It would work in a comparable way as for example how PostgreSQL handle inheritance among tables, PostgreSQL: Documentation: 14: 5.10. Inheritance.

1 Like