As of now we are just curious about what is happening. However along with EHRC (https://ehrc.iiitb.ac.in/) we are planning to pitch a monitoring/tracking solution to the karnataka government for use across the state public health system. If they show interest we may go further.
Just to build on my earlier mail openEHR-EHR-CLUSTER.symptom_sign-cvid.v0 seems to have been specialized from openEHR-EHR-CLUSTER.symptom_sign.v0 (not v1), in which this node is a boolean. Not sure how the marand designer picked this up as an error.
I downloaded the template set for Suspected Covid-19 risk assessment from ckm and used template designer to generate OPT and found a problem. the first instance of the cluster in openEHR-EHR-EVALUATION.health_risk-covid.v0 (Contact with confirmed case) did not show up in the example file generated by Ethercis. So tried exporting the HTML tree from template designer and found that it is missing there also. Not sure what the problem is.
Also while running aql to get the risk assessment data, only the first clone(Contact with suspected pneumonia) is returned. Not sure if these are connected.
Aql used
“select a/composer/name as author, a/context/start_time/value as date_created, a/uid/value as uid, e/ehr_id/value as ehrId,
f/data[at0001]/items[at0003.1]/value as riskAssessment,
f/data[at0001]/items[at0016]/items[at0013.1]/value as riskFactor,
f/data[at0001]/items[at0016]/name/value as nameValue,
f/data[at0001]/items[at0016]/items[at0017.1]/value as presence,
f_a/items[at0007]/value as outbreakLocation FROM EHR e CONTAINS COMPOSITION a CONTAINS EVALUATION f[openEHR-EHR-EVALUATION.health_risk-covid.v0] CONTAINS CLUSTER f_a[openEHR-EHR-CLUSTER.outbreak_exposure.v0]”
I was playing around with the openEHR-Suspected Covid-19 assessment.v0 template on Marand designer v2 and got the following error
“Errors executing action flattenTemplate: Constraint node at [openEHR-EHR-CLUSTER.ovl-symptom_sign-cvid-001.v0/items[at0186.0.1]/value] specializes a constraint which has an incompatible RM type according to the reference model. Parent RM type: DV_CODED_TEXT, specialized RM type: DV_BOOLEAN. The specialization will be removed and reverted to parent constraint.”
Looked at openEHR-EHR-CLUSTER.symptom_sign.v1, which I presume was specialized to create [openEHR-EHR-CLUSTER.symptom_sign-cvid.v0] and saw that the offending node is infact DV_CODED_TEXT in the parent and is DV_BOOLEAN in the specialized one.
I am not sure what is the impact of this, but thought to post it for reference.
Hi @Dileep - thx - I will look into this - did you download the fileset from CKM into your own repository? Are you considering using this in anger or just curious?
@pablo@birger can you check this aql issue ehrbase. It was a kown limitation in Ethercis. Might be able to workaround. The problem is not reliably picking up the name predicate on the node.
Akthough actually dileep the local node names are not critical.
Sorry too strung out too spend much time on it right now.
if I understand this correctly, this issue should have been resolved in EHRbase. It would be great if @Dileep_V_S can provide the example composition and I will check against the query.
It is a long and complex story but basically I suspect you had to download the V1 Symptom-sign archetype but in doing so you not unreasonably picked the most recent (which is being worked on(, when in fact we were using the latest published…
This is the correct version, at least it works for me
@sebastian.garde - the root cause is that AD requires the parent archetype of the specialisation to be sent in the fileset as it treats a specialisation as an ADLS - which will make Thomas happy - you then need to import the v1 archetype manually and the wrong one is easy to pick, by default. However by the magic of semver I could see exactly what was required!!
Thanks for the clarification. I can see that one of the 3 templates from the incubator has moved into the project, while the other 2 are remaining there. Are the ones left in incubator being considered for promotion to the project? what could be the possible timeframe for this?
The agreed plan right now is to regard the ‘Ninja Incubator’ and the ‘Project’ as parallel activities. Implementers are already deploying and updating against the original Incubator templates and we do not want to disturb these too much (especially breaking changes) but will continue to update them with new risk factors and additional screening criteria.
We will try to align this work as as we go on but I suspect it will be impossible to do so completely and I would have no expectation that any of the Incubator templates will end up in the Project directly. What I would hope will happen is that new content (e.g stuff around home circumstances) will be much more aligned from the outset and the archetypes will be directly shared between incubator and Project. Because of limitations in template translations we will also have to create some COVID-19 specialisations which are based on the Project archetypes but allow us to pin-down COVID-specific datapoints/terms in a way that can be easily translated.
At some point I would expect the ‘Project’ resources will have matured to a point where we should point new implementers there, rather than to the Incubator, and those who have already developed against Incubator will have to decide whether to switch (maybe not required).
Bear in mind we are all learning here, kinda fast, so expect some rapid course changes. What is heartening is that we have already made a huge amount of progress.
- you then need to import the v1 archetype manually and the wrong one is easy to pick, by default. However by the magic of semver I could see exactly what was required!!