Project Covfefe

Implementation Covid-19
62

This came directly from the screening assessments that I have seen it just means when did you return ‘home’ and is part of a generic travel history archetype that I built quickly on the basis of a CDC web page. It is very much a generic history, so does have the capacity to take a full history of all places travelled (reagrdless of known risk)

However, I felt that this was not quite right for our current use-case where the travel questions are very much directed at known risk areas. Ideally that should be multi-occurence to capture what you describwed bu there is a tech problem between CKM and AD that meant I had to remove the cluster thast would have mde this possible. @Sebastian Garde is loking at the ieeu. If you want I can add the cluster back in to the verison on AD, as it was working fine other than the display on CKM.

The detailed travel history, will I think be used in the context of recording/reporting a positive test , where much more detailed open-end questions are needed.

With respect to your original question, perhaps we could add an element to the Travel history around something like - Status - "Recent travel’ : “No recent travel” - tricky because that will not just be foreign travel

63

I have updated the Screening template in AD - for comment (here for now).

  • Added Recent travel (boolean) to Travel trip history.

  • Added the Location exposure back into Risk assessment ( this is the thing that breaks in CKM)

  • Added the 'low rsik SNIOME code to the Risk assessment.

  • Moved Travel Histroy down to be neaer Risk assessment.

  • Add Story back into the Story archetype (Bjorn’s request)

  • Found a discrepancy between Risk assessment with has Present/Indeterminate/Absent and Symptom which as Present/Absent/Unknown

The actual requirement in the screening is ‘unknown’, rather than Indeterminate. These are (or should be different).

Unknown just means nothing, nada, no information - there is no information for me to observe/assess.
Indeterminate (or equivocal) - means I have the information but I just cannot make up my mind whether it is present / absent.

Slightly contentiously I have added ‘Unknown’ to the Risk assessment specialisation - (and constrained out the Indeterminate term fo this use-case - it would be good to have some discussion as to whether this makes sense.

It will, of course breakany existing forms or queries.

On that, I have started to add/ increment a sem_ver attribute in the template annotations - see Description.

This is also very experimental. Though we have good and positive experience with semver for archetypes the requirement is a little different for templates.

In particular, handling the V0 templates is more tricky because I’d like a way of notifying colleagues of potential path- breaking changes or any ‘clinically significant’ changes even if pre-production stages like this.

As an experiment, I am updating the semver string for V0 templates as

Major version: start at 0 but update this whenever I make a breaking change
Minor version: start at 0 but update this whenever I make a non-breaking but potentially clinically significant change
Patch: start at 0 but update this whenever I make non significant change

This is different from what we currently do, in that the major version would normally stay at 0, in line with the .v0 status, but I think it will be helpful in keeping track of potential major change during rapid dev cycles like this.

So many fault-lines uncovered!!

64

New Template for Covid-19 diagnosis record (for reporting)

I’v built a wee mindmap based on the WHO reporting guidance - some new stuff appeared at the weekend but this is close enough to make a start.

Anyone want to make a start? @johnmeredith ? Suggest do it in the AD COVID account and Covfefe repo - AD details above.

covfefe-R.xmind (183.8 KB)

There are actually 2 templates involved one for diagnosis, one for 'outcomes - but we can worry about that one later.

65

@siljelb @Tomazg

I suggest we approach Jane Millar and Ian Green at SNOMED, show them what we have done , and ask permission to allow SCT use for these terms in non-SNOMED countries.

Similarly when we get the reporting templates going - on their way!!

1 Like
66

Replied via e-mail but only now catching up with the thread here, so for others’ interest here are my words:

"I’ve had a quick dig around.

I doubt you would get ‘no risk of’ a thing, more likely to get ‘low risk’.

The specific concept you want I don’t think exists.

There is a similar one for Ebola:

707856007 |At low risk for Ebola virus disease (finding)|

With a parent of:

78648007 |At risk for infection (finding)|

So you might expect to see something like you require in there, as ‘Low risk of COVID19 infection’

I cannot find a more generic ‘At low risk of infection’ or ‘At low risk if communicable disease’ or whatever.

78648007 |At risk for infection (finding)|

Has a Parent of:

281694009 |Finding of at risk (finding)|

With 50 children but nothing suitable.

So I think from a SNOMED perspective your only hope would be to use a post-coordinated concept and that is beyond my ken to deliver."

67

Thanks Paul - completely agree finally decided to use a ‘low-risk’ qualifier code - wrong but best we can do right now.

1 Like
68

I made a start myself - just pulled in candidate archetypes really -

on AD -> openEHR-Confirmed Covid-19 infection report.v0 (openEHR-EHR-COMPOSITION.report.v1)

69

I really don’t like the use of

723505004 Low risk

in the value set. It’s a qualifier value, not something that should be recorded on it’s own in a record.

would it be better modeled as an ‘At risk’ section with the finding concepts and another 'Low risk / Not at risk section which would be boolean, I guess?

Appreciate that solution is a bit messy, but ‘At risk’ or ‘Not at risk’ is what people need to know, and if you bind SNOMED CT to the ‘at risk’ element then you can only use the ‘positive’ findings that are available in SNOMED CT.

Or maybe it is the openEHR-EHR-EVALUATION.health_risk-covid.v0 Risk Assessment element that needs changed?

70

I agree. I don’t like it either. If you look at the emis screenshot further up you will see where the positive risk iiens came from.

We reaaly need something similar to the ebola low risk code or as you suggest, change the risk assessment to low or high internal codes. And move the diagnostic positive codes possibly to a problem diagnosis archetype but that feels a bit dodgy too.

71

Sure

I think the EMIS form above is clearly mixing up its concepts of risk evaluation, diagnosis and plans. It’s not pretty.

I do think we would be better with an ‘At risk’ ’ Not at risk’ or ‘High / Medium / Low’ type selection but I can see why we might be being steered along the lines currently implemented.

It’s not easy and maybe needs the eye of a public health or screening professional

From a GP perspective I would want ‘Is at risk’ (according to current criteria) and thus do things, or ‘Not at risk’ and thus discharged.

Confirmed and Excluded can only be done if Testing has been done. These things would be after this assessment - Assess -> At risk -> Test -> confirmed

Or

Assess -> At risk -> Exposure -> Tested -> Need for isolation

Or

Assess-Low risk -> Discharged

So anyway, I am sure you know this. The modelling of the process in the EMIS form is shoehorning in SNOMED codes just to have them there, it is not well modeled with respect to how people are likely to want to work.

Everything else looks pretty groovy though - well done!

I agree with the comments about travel history, as while ‘Yes/No’ travelled is the important thing along with Date of return, risk grading will be dependent on Country / Geographical location so that is nice to have. OTOH soon it will be ‘Live on Earth? You are AT RISK’ :frowning:

1 Like
72

Thanks Paul,

I did discuss with @bna briefly whether we should use problem/daignosis for this but it seemed not quite right - too strong for what here is quick and dirty assessment.

How about using recommendation https://openehr.org/ckm/archetypes/1013.1.1380 and moving the SNOMED codes there, and reverting the risk assessment to low risk and high risk as internal codes?

An alternative would be to add a specific element to the Risk Assessment Covid specialisation archetype to carry something like ‘Risks identified’ - I guess a wee bit like a pathological diagnosis - or interpretation on an observation ??

Actually I think that might work quite well - saves adding another archetype, at least for now.

@bna @vanessap - I am conscious you are busy building forms around this - what’s your view here?

Ian

73

Give me a few hours to respond. Family dinner. Following the thread.

74

I have doubts here.

The archetype problem/diagnosis is defined as a way to record details about a single identified health condition, injury, disability or any other issue which impacts on the physical, mental and/or social well-being of an individual. Being infected with COVID-19 will surely affect both the psychical and social well-being of an individual.

In our initial design we added an entry of problem/diagnosis if the risk factors where present. To further qualify the problem we use openEHR-EHR-CLUSTER.problem_qualifier.v1 . But then we met some challenges.

First we add the problem 840533007::2019-nCOV as a working diagnosis. The healthcare provider do some diagnostic process which may end up with a positive or negative result. The positive will be established , but we didn’t find a good way to record a negative outcome. This is why we added a new term to the qualifier: Excluded .

We will use the last updated element to track the current status of the problem.

I think this is very close to the needs here.

75

I decided that best location for now is the Rationale element in the covid risk assessment archetype. It’s not a prefect match but it feels closer to what we need. The template has been updated in cofveve

76

What if we create a specialized Problem/diagnosis wit the following diagnostic criteria:

image
image1657×302 18.2 KB

?

77

I don’t have much time to reply right now, but this gets us into the “negation flag” issue. I think we should avoid this if at all possible.

2 Likes
78

I understand your opinion here.

We’ve tried to draw the process which we want to support. The yellow rectangles defines the state of the problem during the stay. This is IMHO the process and state of the health care issues the patient is evaluated for.

COVID-19-screening
COVID-19-screening1913×676 23.4 KB

How do you suggest to model this?

79

I wrote a note to re-think and explain my ideas about the design and guidelines for the models and the application. I hope you can access it here: https://365dips-my.sharepoint.com/:w:/g/personal/bna_dips_no/EecLBF96iGJCi3gfV-bARVIBI8z4kQmT8Ha2zBLlKEUuog?e=3HOvf9

Some content from the note:

The screening process has a set of steps and states as illustrated below:

covid-19-screening
covid-19-screening971×201 4.91 KB

The health risk assessment archetype is developed to cover assessment of the potential and likelihood of future adverse health effects as determined by identified risk factors.

The archetype may be used with the following definitions:

Element Values Comment
Health risk 2019-nCoV The purpose is to assess if the subject is infected by 2019-nCoV
Risk assessment Not suspected infection, Suspected infection, Probable infection, Confirmed infection, Disproved infection The possible outcomes of the assessment
Last updated Date/time when for the last assessment The assessment may be repeated several times as illustrated above
Assessment method Initial screening, Preliminary lab,Reference lab
80

The problem here is likely the export to OET mechanism in AD:

If you look at the (now outdated) oet at https://openehr.org/ckm/templates/1013.26.268/7/oet and then compare it with the branch I created at https://openehr.org/ckm/templates/1013.26.269/oet - the only difference to make it work is in l. 611 the added , 'Other’ in the path.

path="/data[at0001]/items[at0016, 'Other']/items[at0027.1]" xsi:type="tem:CLUSTER">

I may have picked the wrong clone (“Other”) of course…which clone this is for is simply not defined in the oet output, so I can no more than guess (which the OPT generator behind CKM refuses to do). If this is to be applied to more than one clone of at0016 (like “Potential locality exposure” and “Contact with severe resp disease”), then this would need to be done there as well.

1 Like