Re: Downloading previous versions of archetypes from CKM

[Dileep V S]

Hi Ian/Marcus,

Thanks everybody for a healthy discussion that I am sure will help many
implementors.

My idea was not to belittle what the community has achieved with the
limited resources. That would be unkind on my part to all the community
members who have(and continue to) invested their time and knowledge to get
to where we are today. But as more an more real world implementors are
beginning to commit to the OpenEHR philosophy, it is important for them to
be aware of it's limitations and hedge adequately against them. So if we
are able to evolve some best practice recommendations out of this
discussion, we would have taken one more step forward.

My two bits after reading through the discussions. This is a complex
problem that may not have a full solution immediately. It is going to be a
combination of tools, people & processes for some more time till the tools
mature. CKM does some bits and the implementors need to take over from
there and evolve local processes. Sharing of such local processes will help
others and mature the community tooling over time.

Thanks once again

regards
Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: ehr.network, ayushehr.com
 e: dil...@healthelife.in


On Tue, May 28, 2019 at 4:59 PM Ian McNicoll  wrote:

> Hi Marcus,
>
> Thanks for your support.
>
> I would love to see NHSX support something like this, especially as I know
> the FHIR folks are going down that road and we need something that goes
> well beyond just openEHR artefacts and into termsets, valuesets, rules etc.
> Every community working on health semantics will need something like this,
> and we will all need to be able to reference artefacts from other standards
> groups.
>
> I have been looking at NPM but Bit https://bit.dev/ might be interesting
> and fit better with our paradigm which is more about components than code
> per-se.
>
> Ian
>
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
>
> Director, freshEHR Clinical Informatics Ltd.
> CCIO inidus Ltd. i...@inidus.com
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Tue, 28 May 2019 at 12:22, Marcus Baw  wrote:
>
>> Interesting discussion and I agree with Ian that the openEHR community
>> should remember to give itself credit for what HAS been done, with very
>> little resource, rather than beating themselves up about what tooling is
>> missing from the ecosystem.
>>
>> An automated archetype package and dependency manager, as well as
>> archetype version migration tools, would be great to have. It should work
>> like package managers in other language ecosystems such as NPM, RubyGems,
>> PyPi etc. We need to get some resources behind this idea, maybe we could
>> collectively encourage the new NHSx to think in this direction?
>>
>> Marcus
>>
>> On Tue, 28 May 2019 at 12:12, Ian McNicoll  wrote:
>>
>>> Hi Paul,
>>>
>>> Nicely summed up.
>>>
>>> You definitely need to manage your CDR artefacts in just the same way as
>>> any other software libraries. This is currently more manually intensive
>>> than it should be but one can see how it could be largely automated
>>>
>>> However, maintaining coherent semantics is much more challenging as you
>>> need to consider how each new app or datastream fits into both some sort of
>>> attempt to keep a longitudinal record, with the need to preserve condition/
>>> episode or pathway data quality. That is hard and will require human beings
>>> to design and continually adapt. For LHCRE purposes and beyond I have made
>>> a start at a baseline architecture of templates that should be applicable
>>> to a broad set of communities but it will require customisation, depending
>>> on local circumstances. e.g can we apply the rule that there should only be
>>> a single allergies list for the whole community? Do we have sufficient
>>> vendor buy-in, and clinical buy-in, and the governance structures to
>>> resolve any differences of opinion or to challenge poor data quality. As
>>> GPs we have been used to this sort of challenge within our own practices -
>>> are we able to scale up to a wider community of practice.
>>>
>>> Ian
>>> Dr Ian McNicoll
>>> mobile +44 (0)775 209 7859
>>> office +44 (0)1536 414994
>>> skype: ianmcnicoll
>>> email: i...@freshehr.com
>>> twitter: @ianmcnicoll
>>>
>>>
>>>
>>> Director, freshEHR Clinical Informatics Ltd.
>>> CCIO inidus Ltd. i...@inidus.com
>>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>>> Hon. Senior Research Associate, CHIME, UCL
>>>
>>>
>>> On Tue, 28 May 2019 at 11:40, Paul Miller 
>>> wrote:
>>>
 Very timely discussion as we are hitting this issue right now in
 Scotland, and meeting together tomorrow to agree an approach - hopefully
 Silje and Ian 

Re: Downloading previous versions of archetypes from CKM

[Ian McNicoll]

Hi Marcus,

Thanks for your support.

I would love to see NHSX support something like this, especially as I know
the FHIR folks are going down that road and we need something that goes
well beyond just openEHR artefacts and into termsets, valuesets, rules etc.
Every community working on health semantics will need something like this,
and we will all need to be able to reference artefacts from other standards
groups.

I have been looking at NPM but Bit https://bit.dev/ might be interesting
and fit better with our paradigm which is more about components than code
per-se.

Ian

Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll



Director, freshEHR Clinical Informatics Ltd.
CCIO inidus Ltd. i...@inidus.com
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Hon. Senior Research Associate, CHIME, UCL


On Tue, 28 May 2019 at 12:22, Marcus Baw  wrote:

> Interesting discussion and I agree with Ian that the openEHR community
> should remember to give itself credit for what HAS been done, with very
> little resource, rather than beating themselves up about what tooling is
> missing from the ecosystem.
>
> An automated archetype package and dependency manager, as well as
> archetype version migration tools, would be great to have. It should work
> like package managers in other language ecosystems such as NPM, RubyGems,
> PyPi etc. We need to get some resources behind this idea, maybe we could
> collectively encourage the new NHSx to think in this direction?
>
> Marcus
>
> On Tue, 28 May 2019 at 12:12, Ian McNicoll  wrote:
>
>> Hi Paul,
>>
>> Nicely summed up.
>>
>> You definitely need to manage your CDR artefacts in just the same way as
>> any other software libraries. This is currently more manually intensive
>> than it should be but one can see how it could be largely automated
>>
>> However, maintaining coherent semantics is much more challenging as you
>> need to consider how each new app or datastream fits into both some sort of
>> attempt to keep a longitudinal record, with the need to preserve condition/
>> episode or pathway data quality. That is hard and will require human beings
>> to design and continually adapt. For LHCRE purposes and beyond I have made
>> a start at a baseline architecture of templates that should be applicable
>> to a broad set of communities but it will require customisation, depending
>> on local circumstances. e.g can we apply the rule that there should only be
>> a single allergies list for the whole community? Do we have sufficient
>> vendor buy-in, and clinical buy-in, and the governance structures to
>> resolve any differences of opinion or to challenge poor data quality. As
>> GPs we have been used to this sort of challenge within our own practices -
>> are we able to scale up to a wider community of practice.
>>
>> Ian
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>>
>> Director, freshEHR Clinical Informatics Ltd.
>> CCIO inidus Ltd. i...@inidus.com
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Tue, 28 May 2019 at 11:40, Paul Miller  wrote:
>>
>>> Very timely discussion as we are hitting this issue right now in
>>> Scotland, and meeting together tomorrow to agree an approach - hopefully
>>> Silje and Ian joining us for that.
>>>
>>> We need not just versioning management of the content but also a way to
>>> agree a coherent set of archetypes and templates for our national CDR.
>>>
>>> So these are two things: #1 models versioning and management and #2
>>> content management.
>>>
>>> CKM it seems will let us handle some of the versioning and it definitely
>>> will help us with the review processes / editorial / reaching consensus but
>>> we need other things for handling which version of which model is actually
>>> deployed in our CDR, and then we need something else for handling 'here is
>>> all the content for your EHR' to establish gaps and avoid duplication.
>>>
>>> All these things need to be joined up so that it can make sense to
>>> clinical and developer teams using it. That joining up process seems likely
>>> to be fairly bespoke - combination of tools like CKM  /GitHub / others? and
>>> also needing a human being or two being in charge, or at least having
>>> oversight of the whole process.
>>>
>>> If and as we evolve our processes I will update the list.
>>>
>>> Paul
>>>
>>>
>>> --
>>>
>>> Dr Paul Miller
>>>
>>> MBCHB MRCGP FFCI DRCOG DMI
>>> Glenburn Medical Practice
>>> Fairway Avenue
>>> Paisley
>>> PA2 8DX
>>> Tel: 0141 884 7788
>>>
>>> http://www.glenburnsurgery.scot.nhs.uk/
>>>
>>>
>>>
>>> Clinical Lead
>>>
>>> NES Digital Service
>>>
>>> https://nds.nes.digital/
>>>
>>>
>>>
>>> Mobile: +44 7711 346 928
>>>
>>> Twitter: @docpaulmiller
>>>
>>>
>>> On Tue, 28 May 2019 at 11:00, Ian McNicoll  

RE: Downloading previous versions of archetypes from CKM

[Bakke, Silje Ljosland via openEHR-clinical]

Hi Paul,

We recently challenged our regional health authorities about the governance of 
a structured EHR that you’re describing:
“In all four regions, the procurement and/or introduction of structured EHR 
solutions is imminent. Three of the regions will use a common information 
standard in the form of archetypes, and all four will use common terminologies. 
For all regions, this will require the management of the local structured EHR 
content that may be similar in shape, but in scope and complexity by far will 
surpass today's management of free text templates and letters.

In free text records, the information the record may contain is not limited by 
system designers, and is limited to the scope of specific  documents. All 
responsibility for the content therefore lies with the healthcare professionals 
who use the records for documentation. In a structured record, on the other 
hand, the content is to a larger degree predefined and can be reused 
independently of the "documents", ie the context in which the information is 
recorded. This will require the governance of the record information, for 
example at the hospital trust or regional health authority level.

The three regions that use the common information standard must manage at an 
operational level where and how national archetypes are used, and whether, 
where and how local or regional archetypes are used. The remaining region must 
also manage how information structures are put into use, but depends on their 
vendor's information models and not the common information standard.

Other clinical information components, such as rules for decision support and 
process models, will also have to be managed both at the overall and 
operational level.

This new governance will require a high level of competence in clinical 
informatics in hospital trusts and/or regional health authorities.”

I think a combination of tools like you describe is necessary, as well as 
knowledgeable people with time to run it.

Regards,
Silje

From: openEHR-clinical  On Behalf 
Of Paul Miller
Sent: Tuesday, May 28, 2019 12:40 PM
To: For openEHR clinical discussions 
Subject: Re: Downloading previous versions of archetypes from CKM

Very timely discussion as we are hitting this issue right now in Scotland, and 
meeting together tomorrow to agree an approach - hopefully Silje and Ian 
joining us for that.

We need not just versioning management of the content but also a way to agree a 
coherent set of archetypes and templates for our national CDR.

So these are two things: #1 models versioning and management and #2 content 
management.

CKM it seems will let us handle some of the versioning and it definitely will 
help us with the review processes / editorial / reaching consensus but we need 
other things for handling which version of which model is actually deployed in 
our CDR, and then we need something else for handling 'here is all the content 
for your EHR' to establish gaps and avoid duplication.

All these things need to be joined up so that it can make sense to clinical and 
developer teams using it. That joining up process seems likely to be fairly 
bespoke - combination of tools like CKM  /GitHub / others? and also needing a 
human being or two being in charge, or at least having oversight of the whole 
process.

If and as we evolve our processes I will update the list.

Paul


--
Dr Paul Miller
MBCHB MRCGP FFCI DRCOG DMI
Glenburn Medical Practice
Fairway Avenue
Paisley
PA2 8DX
Tel: 0141 884 7788
http://www.glenburnsurgery.scot.nhs.uk/

Clinical Lead
NES Digital Service
https://nds.nes.digital/

Mobile: +44 7711 346 928
Twitter: @docpaulmiller


On Tue, 28 May 2019 at 11:00, Ian McNicoll 
mailto:i...@freshehr.com>> wrote:
Thanks both,

Very helpful. Just in case folks get too negative about what we have achieved, 
I am currently working on 4 different regional/national EHR projects. On all 4 
projects, 80% of the content is covered by published (or at least very stable) 
international CKM archetypes. Once you get to local, detailed applications 
coverage drops but it is here where the ability to develop and deploy local or 
vendor level archetypes really shines. In my view the ability to rapidly deploy 
local or evolving archetypes is at least as useful as broad interoperability 
per-se. The latter is also always going to be dependent on the alignment of 
clinical practice, legislative change, terminology use etc,etc none of which 
are directly within our control. We have a set of medication archetypes that 
are being used right now in multiple systems to deliver full hospital and 
comunity prescribing systems, supporting structured dosage and timing - that 
alone is a very significant achievement

Given the minimal resource we have had to work with, nearly all coming from 
supportive commercial organisations,  I think we should be pretty proud of what 
has been achieved, and it is getting better all the time.

We do need to have better dependency management 

Re: Downloading previous versions of archetypes from CKM

[Marcus Baw]

Interesting discussion and I agree with Ian that the openEHR community
should remember to give itself credit for what HAS been done, with very
little resource, rather than beating themselves up about what tooling is
missing from the ecosystem.

An automated archetype package and dependency manager, as well as archetype
version migration tools, would be great to have. It should work like
package managers in other language ecosystems such as NPM, RubyGems, PyPi
etc. We need to get some resources behind this idea, maybe we could
collectively encourage the new NHSx to think in this direction?

Marcus

On Tue, 28 May 2019 at 12:12, Ian McNicoll  wrote:

> Hi Paul,
>
> Nicely summed up.
>
> You definitely need to manage your CDR artefacts in just the same way as
> any other software libraries. This is currently more manually intensive
> than it should be but one can see how it could be largely automated
>
> However, maintaining coherent semantics is much more challenging as you
> need to consider how each new app or datastream fits into both some sort of
> attempt to keep a longitudinal record, with the need to preserve condition/
> episode or pathway data quality. That is hard and will require human beings
> to design and continually adapt. For LHCRE purposes and beyond I have made
> a start at a baseline architecture of templates that should be applicable
> to a broad set of communities but it will require customisation, depending
> on local circumstances. e.g can we apply the rule that there should only be
> a single allergies list for the whole community? Do we have sufficient
> vendor buy-in, and clinical buy-in, and the governance structures to
> resolve any differences of opinion or to challenge poor data quality. As
> GPs we have been used to this sort of challenge within our own practices -
> are we able to scale up to a wider community of practice.
>
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
>
> Director, freshEHR Clinical Informatics Ltd.
> CCIO inidus Ltd. i...@inidus.com
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Tue, 28 May 2019 at 11:40, Paul Miller  wrote:
>
>> Very timely discussion as we are hitting this issue right now in
>> Scotland, and meeting together tomorrow to agree an approach - hopefully
>> Silje and Ian joining us for that.
>>
>> We need not just versioning management of the content but also a way to
>> agree a coherent set of archetypes and templates for our national CDR.
>>
>> So these are two things: #1 models versioning and management and #2
>> content management.
>>
>> CKM it seems will let us handle some of the versioning and it definitely
>> will help us with the review processes / editorial / reaching consensus but
>> we need other things for handling which version of which model is actually
>> deployed in our CDR, and then we need something else for handling 'here is
>> all the content for your EHR' to establish gaps and avoid duplication.
>>
>> All these things need to be joined up so that it can make sense to
>> clinical and developer teams using it. That joining up process seems likely
>> to be fairly bespoke - combination of tools like CKM  /GitHub / others? and
>> also needing a human being or two being in charge, or at least having
>> oversight of the whole process.
>>
>> If and as we evolve our processes I will update the list.
>>
>> Paul
>>
>>
>> --
>>
>> Dr Paul Miller
>>
>> MBCHB MRCGP FFCI DRCOG DMI
>> Glenburn Medical Practice
>> Fairway Avenue
>> Paisley
>> PA2 8DX
>> Tel: 0141 884 7788
>>
>> http://www.glenburnsurgery.scot.nhs.uk/
>>
>>
>>
>> Clinical Lead
>>
>> NES Digital Service
>>
>> https://nds.nes.digital/
>>
>>
>>
>> Mobile: +44 7711 346 928
>>
>> Twitter: @docpaulmiller
>>
>>
>> On Tue, 28 May 2019 at 11:00, Ian McNicoll  wrote:
>>
>>> Thanks both,
>>>
>>> Very helpful. Just in case folks get too negative about what we have
>>> achieved, I am currently working on 4 different regional/national EHR
>>> projects. On all 4 projects, 80% of the content is covered by published (or
>>> at least very stable) international CKM archetypes. Once you get to local,
>>> detailed applications coverage drops but it is here where the ability to
>>> develop and deploy local or vendor level archetypes really shines. In my
>>> view the ability to rapidly deploy local or evolving archetypes is at least
>>> as useful as broad interoperability per-se. The latter is also always going
>>> to be dependent on the alignment of clinical practice, legislative change,
>>> terminology use etc,etc none of which are directly within our control. We
>>> have a set of medication archetypes that are being used right now in
>>> multiple systems to deliver full hospital and comunity prescribing systems,
>>> supporting structured dosage and timing - that alone is a very significant
>>> achievement
>>>
>>> Given the

Re: Downloading previous versions of archetypes from CKM

[Ian McNicoll]

Hi Paul,

Nicely summed up.

You definitely need to manage your CDR artefacts in just the same way as
any other software libraries. This is currently more manually intensive
than it should be but one can see how it could be largely automated

However, maintaining coherent semantics is much more challenging as you
need to consider how each new app or datastream fits into both some sort of
attempt to keep a longitudinal record, with the need to preserve condition/
episode or pathway data quality. That is hard and will require human beings
to design and continually adapt. For LHCRE purposes and beyond I have made
a start at a baseline architecture of templates that should be applicable
to a broad set of communities but it will require customisation, depending
on local circumstances. e.g can we apply the rule that there should only be
a single allergies list for the whole community? Do we have sufficient
vendor buy-in, and clinical buy-in, and the governance structures to
resolve any differences of opinion or to challenge poor data quality. As
GPs we have been used to this sort of challenge within our own practices -
are we able to scale up to a wider community of practice.

Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll



Director, freshEHR Clinical Informatics Ltd.
CCIO inidus Ltd. i...@inidus.com
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Hon. Senior Research Associate, CHIME, UCL


On Tue, 28 May 2019 at 11:40, Paul Miller  wrote:

> Very timely discussion as we are hitting this issue right now in Scotland,
> and meeting together tomorrow to agree an approach - hopefully Silje and
> Ian joining us for that.
>
> We need not just versioning management of the content but also a way to
> agree a coherent set of archetypes and templates for our national CDR.
>
> So these are two things: #1 models versioning and management and #2
> content management.
>
> CKM it seems will let us handle some of the versioning and it definitely
> will help us with the review processes / editorial / reaching consensus but
> we need other things for handling which version of which model is actually
> deployed in our CDR, and then we need something else for handling 'here is
> all the content for your EHR' to establish gaps and avoid duplication.
>
> All these things need to be joined up so that it can make sense to
> clinical and developer teams using it. That joining up process seems likely
> to be fairly bespoke - combination of tools like CKM  /GitHub / others? and
> also needing a human being or two being in charge, or at least having
> oversight of the whole process.
>
> If and as we evolve our processes I will update the list.
>
> Paul
>
>
> --
>
> Dr Paul Miller
>
> MBCHB MRCGP FFCI DRCOG DMI
> Glenburn Medical Practice
> Fairway Avenue
> Paisley
> PA2 8DX
> Tel: 0141 884 7788
>
> http://www.glenburnsurgery.scot.nhs.uk/
>
>
>
> Clinical Lead
>
> NES Digital Service
>
> https://nds.nes.digital/
>
>
>
> Mobile: +44 7711 346 928
>
> Twitter: @docpaulmiller
>
>
> On Tue, 28 May 2019 at 11:00, Ian McNicoll  wrote:
>
>> Thanks both,
>>
>> Very helpful. Just in case folks get too negative about what we have
>> achieved, I am currently working on 4 different regional/national EHR
>> projects. On all 4 projects, 80% of the content is covered by published (or
>> at least very stable) international CKM archetypes. Once you get to local,
>> detailed applications coverage drops but it is here where the ability to
>> develop and deploy local or vendor level archetypes really shines. In my
>> view the ability to rapidly deploy local or evolving archetypes is at least
>> as useful as broad interoperability per-se. The latter is also always going
>> to be dependent on the alignment of clinical practice, legislative change,
>> terminology use etc,etc none of which are directly within our control. We
>> have a set of medication archetypes that are being used right now in
>> multiple systems to deliver full hospital and comunity prescribing systems,
>> supporting structured dosage and timing - that alone is a very significant
>> achievement
>>
>> Given the minimal resource we have had to work with, nearly all coming
>> from supportive commercial organisations,  I think we should be pretty
>> proud of what has been achieved, and it is getting better all the time.
>>
>> We do need to have better dependency management and better tools for
>> local deployment but ultimately this is a community effort, so if you have
>> ideas or software resource, please pitch in.
>>
>> Ian
>>
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>>
>> Director, freshEHR Clinical Informatics Ltd.
>> CCIO inidus Ltd. i...@inidus.com
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Tue, 28 May 2019

Re: Downloading previous versions of archetypes from CKM

[Paul Miller]

Very timely discussion as we are hitting this issue right now in Scotland,
and meeting together tomorrow to agree an approach - hopefully Silje and
Ian joining us for that.

We need not just versioning management of the content but also a way to
agree a coherent set of archetypes and templates for our national CDR.

So these are two things: #1 models versioning and management and #2 content
management.

CKM it seems will let us handle some of the versioning and it definitely
will help us with the review processes / editorial / reaching consensus but
we need other things for handling which version of which model is actually
deployed in our CDR, and then we need something else for handling 'here is
all the content for your EHR' to establish gaps and avoid duplication.

All these things need to be joined up so that it can make sense to clinical
and developer teams using it. That joining up process seems likely to be
fairly bespoke - combination of tools like CKM  /GitHub / others? and also
needing a human being or two being in charge, or at least having oversight
of the whole process.

If and as we evolve our processes I will update the list.

Paul


--

Dr Paul Miller

MBCHB MRCGP FFCI DRCOG DMI
Glenburn Medical Practice
Fairway Avenue
Paisley
PA2 8DX
Tel: 0141 884 7788

http://www.glenburnsurgery.scot.nhs.uk/



Clinical Lead

NES Digital Service

https://nds.nes.digital/



Mobile: +44 7711 346 928

Twitter: @docpaulmiller


On Tue, 28 May 2019 at 11:00, Ian McNicoll  wrote:

> Thanks both,
>
> Very helpful. Just in case folks get too negative about what we have
> achieved, I am currently working on 4 different regional/national EHR
> projects. On all 4 projects, 80% of the content is covered by published (or
> at least very stable) international CKM archetypes. Once you get to local,
> detailed applications coverage drops but it is here where the ability to
> develop and deploy local or vendor level archetypes really shines. In my
> view the ability to rapidly deploy local or evolving archetypes is at least
> as useful as broad interoperability per-se. The latter is also always going
> to be dependent on the alignment of clinical practice, legislative change,
> terminology use etc,etc none of which are directly within our control. We
> have a set of medication archetypes that are being used right now in
> multiple systems to deliver full hospital and comunity prescribing systems,
> supporting structured dosage and timing - that alone is a very significant
> achievement
>
> Given the minimal resource we have had to work with, nearly all coming
> from supportive commercial organisations,  I think we should be pretty
> proud of what has been achieved, and it is getting better all the time.
>
> We do need to have better dependency management and better tools for local
> deployment but ultimately this is a community effort, so if you have ideas
> or software resource, please pitch in.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
>
> Director, freshEHR Clinical Informatics Ltd.
> CCIO inidus Ltd. i...@inidus.com
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Tue, 28 May 2019 at 10:43, Bakke, Silje Ljosland via openEHR-clinical <
> openehr-clinical@lists.openehr.org> wrote:
>
>> Hi everyone,
>>
>>
>>
>> It seems like Dileep’s original questions have been largely answered by
>> other members of the community, thank you! 😊
>>
>>
>>
>> There’s been some added discussion about the effects of changing archetypes 
>> on implementations and implementers. Heather wrote an email about this four 
>> years ago 
>> (https://www.mail-archive.com/openehr-clinical@lists.openehr.org/msg03786.html),
>>  concluding that “Implementers need strategies to align the mismatches that 
>> will occur. Publication per se is a very coarse way to manage 
>> interoperability and will not solve our problems. The alignment needs to be 
>> done at a finer level of control. This is not a new problem. It is one we 
>> are just realising as we implement and start to share - we were always going 
>> to have to have this conversation and solve this problem.“.
>>
>>
>>
>> We as CKAs can only control the governance at the “best practice” CKM
>> level, but we know that there’ll be downstream effects on implementers for
>> every change. The CKM changes are governed in a way conforming to this
>> spec:
>> https://specifications.openehr.org/releases/AM/latest/Identification.html#_version_numbering,
>> but we can’t control which versions everyone have in their systems, or what
>> impact changes made in the CKM will have. There’s definitely a need for
>> implementers to have another level of local governance. It’s completely
>> optional for implementers to update to newer versions of archetypes, but
>> making an informed decision about this requires good tooling for comparing
>> th

Re: Downloading previous versions of archetypes from CKM

[Ian McNicoll]

Thanks both,

Very helpful. Just in case folks get too negative about what we have
achieved, I am currently working on 4 different regional/national EHR
projects. On all 4 projects, 80% of the content is covered by published (or
at least very stable) international CKM archetypes. Once you get to local,
detailed applications coverage drops but it is here where the ability to
develop and deploy local or vendor level archetypes really shines. In my
view the ability to rapidly deploy local or evolving archetypes is at least
as useful as broad interoperability per-se. The latter is also always going
to be dependent on the alignment of clinical practice, legislative change,
terminology use etc,etc none of which are directly within our control. We
have a set of medication archetypes that are being used right now in
multiple systems to deliver full hospital and comunity prescribing systems,
supporting structured dosage and timing - that alone is a very significant
achievement

Given the minimal resource we have had to work with, nearly all coming from
supportive commercial organisations,  I think we should be pretty proud of
what has been achieved, and it is getting better all the time.

We do need to have better dependency management and better tools for local
deployment but ultimately this is a community effort, so if you have ideas
or software resource, please pitch in.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll



Director, freshEHR Clinical Informatics Ltd.
CCIO inidus Ltd. i...@inidus.com
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Hon. Senior Research Associate, CHIME, UCL


On Tue, 28 May 2019 at 10:43, Bakke, Silje Ljosland via openEHR-clinical <
openehr-clinical@lists.openehr.org> wrote:

> Hi everyone,
>
>
>
> It seems like Dileep’s original questions have been largely answered by
> other members of the community, thank you! 😊
>
>
>
> There’s been some added discussion about the effects of changing archetypes 
> on implementations and implementers. Heather wrote an email about this four 
> years ago 
> (https://www.mail-archive.com/openehr-clinical@lists.openehr.org/msg03786.html),
>  concluding that “Implementers need strategies to align the mismatches that 
> will occur. Publication per se is a very coarse way to manage 
> interoperability and will not solve our problems. The alignment needs to be 
> done at a finer level of control. This is not a new problem. It is one we are 
> just realising as we implement and start to share - we were always going to 
> have to have this conversation and solve this problem.“.
>
>
>
> We as CKAs can only control the governance at the “best practice” CKM
> level, but we know that there’ll be downstream effects on implementers for
> every change. The CKM changes are governed in a way conforming to this
> spec:
> https://specifications.openehr.org/releases/AM/latest/Identification.html#_version_numbering,
> but we can’t control which versions everyone have in their systems, or what
> impact changes made in the CKM will have. There’s definitely a need for
> implementers to have another level of local governance. It’s completely
> optional for implementers to update to newer versions of archetypes, but
> making an informed decision about this requires good tooling for comparing
> their existing single implementations, or specific modules within an
> implementation, with the current CKM versions of the same archetypes. I
> know that several vendors have been talking about this issue of keeping
> track of the archetypes that they’re using themselves in their
> implementations, compared to what are the latest versions in a CKM. I
> believe DIPS has made some tools for simplifying this process internally.
>
>
>
> If there are archetypes that completely changed names and which are now
> not searchable using their old names, we’d really like to be notified so
> that we can make sure the old names are in the search keywords. We’ve just
> been testing, and have seen that there may also be a problem with CKM
> search for archetype IDs which have been superseded within the version
> history of that same archetype.
>
>
>
> The reality is that we have nearly 100 archetypes published, and the
> majority of those are core to any EHR. There’s no doubt that we’ve been in
> a state of flux to get to this point and every change has potentially
> impacted every implementation, but these are now stable and provide a solid
> foundation for EHR development. Now we will be focussing on more
> specialised archetypes which won’t be as universally used and hence not as
> universally disruptive when they go through change. We know we’re through
> the worst, but clinical knowledge will continue to change and this work
> will never be finished.
>
>
>
> Regards,
>
> *Silje and Heather*
>
>
>
> *From:* openEHR-clinical  *On
> Behalf Of *Ian McNicoll
> *Sent:* Tuesday, May 28, 2019 10:15 AM
> *T

RE: Downloading previous versions of archetypes from CKM

[Bakke, Silje Ljosland via openEHR-clinical]

Hi everyone,

It seems like Dileep’s original questions have been largely answered by other 
members of the community, thank you! 😊


There’s been some added discussion about the effects of changing archetypes on 
implementations and implementers. Heather wrote an email about this four years 
ago 
(https://www.mail-archive.com/openehr-clinical@lists.openehr.org/msg03786.html),
 concluding that “Implementers need strategies to align the mismatches that 
will occur. Publication per se is a very coarse way to manage interoperability 
and will not solve our problems. The alignment needs to be done at a finer 
level of control. This is not a new problem. It is one we are just realising as 
we implement and start to share - we were always going to have to have this 
conversation and solve this problem.“.

We as CKAs can only control the governance at the “best practice” CKM level, 
but we know that there’ll be downstream effects on implementers for every 
change. The CKM changes are governed in a way conforming to this spec: 
https://specifications.openehr.org/releases/AM/latest/Identification.html#_version_numbering,
 but we can’t control which versions everyone have in their systems, or what 
impact changes made in the CKM will have. There’s definitely a need for 
implementers to have another level of local governance. It’s completely 
optional for implementers to update to newer versions of archetypes, but making 
an informed decision about this requires good tooling for comparing their 
existing single implementations, or specific modules within an implementation, 
with the current CKM versions of the same archetypes. I know that several 
vendors have been talking about this issue of keeping track of the archetypes 
that they’re using themselves in their implementations, compared to what are 
the latest versions in a CKM. I believe DIPS has made some tools for 
simplifying this process internally.

If there are archetypes that completely changed names and which are now not 
searchable using their old names, we’d really like to be notified so that we 
can make sure the old names are in the search keywords. We’ve just been 
testing, and have seen that there may also be a problem with CKM search for 
archetype IDs which have been superseded within the version history of that 
same archetype.

The reality is that we have nearly 100 archetypes published, and the majority 
of those are core to any EHR. There’s no doubt that we’ve been in a state of 
flux to get to this point and every change has potentially impacted every 
implementation, but these are now stable and provide a solid foundation for EHR 
development. Now we will be focussing on more specialised archetypes which 
won’t be as universally used and hence not as universally disruptive when they 
go through change. We know we’re through the worst, but clinical knowledge will 
continue to change and this work will never be finished.

Regards,
Silje and Heather

From: openEHR-clinical  On Behalf 
Of Ian McNicoll
Sent: Tuesday, May 28, 2019 10:15 AM
To: For openEHR clinical discussions 
Subject: Re: Downloading previous versions of archetypes from CKM

I'll let Silje and Heather talk more about overall progress with the 
publication [process but we all have ot recognise that this is a huge job which 
just takes time. As Sebastian has said most of the work done, even at an 
editorial level is done by volunteers, in particular, the Norwegian CKM team 
are giving a lot of their time for joint development. The Foundation has been 
able to fund particular work that Heather is picking up right now and broadly 
speaking the Clinical and Specification sides have a similar budget.  This is 
all down to vendors, organisations recognising the huge value that we all gain 
from this collaborative effort. Yes it takes time, and yes we can always do 
more but I do see steady and useful progress.

I would say that no developer should be relying on any CKM or indeed any remote 
repository as their source of truth. These artefacts should all be regarded in 
exactly the same way as a third-party software library. Download and maintain 
local copies, in whatever environment you prefer (I use git). There is 
definitely a gap in having some developer-tooling to support this, and as 
Sebastian says, we do need something more akin to Maven or NPM to manage the 
increasingly complex dependencies.

I am more confident than Sebastian that we will reach a high degree of 
alignment of versions of archetypes as these mature in CKM and in vendor 
systems but it will take time and effort. This is a vastly complex world. The 
openEHR process my seem slow and a bit chaotic but I still believe it has shown 
itself, so far to be the only means of tackling this complexity at any sort of 
scale.

So sign up, get involved.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https:/

Re: Downloading previous versions of archetypes from CKM

[Ian McNicoll]

I'll let Silje and Heather talk more about overall progress with the
publication [process but we all have ot recognise that this is a huge job
which just takes time. As Sebastian has said most of the work done, even at
an editorial level is done by volunteers, in particular, the Norwegian CKM
team are giving a lot of their time for joint development. The Foundation
has been able to fund particular work that Heather is picking up right now
and broadly speaking the Clinical and Specification sides have a similar
budget.  This is all down to vendors, organisations recognising the huge
value that we all gain from this collaborative effort. Yes it takes time,
and yes we can always do more but I do see steady and useful progress.

I would say that no developer should be relying on any CKM or indeed any
remote repository as their source of truth. These artefacts should all be
regarded in exactly the same way as a third-party software library.
Download and maintain local copies, in whatever environment you prefer (I
use git). There is definitely a gap in having some developer-tooling to
support this, and as Sebastian says, we do need something more akin to
Maven or NPM to manage the increasingly complex dependencies.

I am more confident than Sebastian that we will reach a high degree of
alignment of versions of archetypes as these mature in CKM and in vendor
systems but it will take time and effort. This is a vastly complex world.
The openEHR process my seem slow and a bit chaotic but I still believe it
has shown itself, so far to be the only means of tackling this complexity
at any sort of scale.

So sign up, get involved.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll



Director, freshEHR Clinical Informatics Ltd.
CCIO inidus Ltd. i...@inidus.com
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Hon. Senior Research Associate, CHIME, UCL


On Tue, 28 May 2019 at 07:18, Sebastian Garde <
sebastian.ga...@oceaninformatics.com> wrote:

> To download, for example click on the Details Button underneath each
> archetype revision in the revision history.
>
> You can also keep track of all the changes in the git repository at
> https://github.com/openEHR/CKM-mirror
>
> While I obviously agree with the aim of everybody using the same
> archetypes, it is probably still a bit of a lofty aim.
>
> Nonetheless a lot of progress has actually been made and it is my
> understanding at least that many of the more commonly required archetypes
> are published. Even so, I would see the RM as the core schema, and that
> doesn’t change if you use different archetypes.
>
>
>
> Pablo, yes, agree with funding, but it always seems that everybody wants
> something.
>
> Re automating comparisons, maybe we should look into exposing this via the
> api as well somehow.
>
> Nonetheless, the semantic version and also the log message should at least
> give an indication of the type of change and impact.
>
> I think Ian and Bjorn have some packaging ideas to better support
> implementers – this is somewhat the other side of the modelling coin, but
> important of course as well.
>
> Sebastian
>
>
>
> *Von:* openEHR-clinical  *Im
> Auftrag von *Dileep V S
> *Gesendet:* Dienstag, 28. Mai 2019 07:11
> *An:* For openEHR clinical discussions  >
> *Betreff:* Re: Downloading previous versions of archetypes from CKM
>
>
>
> Hi,
>
>
>
> Thank you for all the responses.  It has helped me clear a couple of of
> things that need to be keep in mind while using resources from OpenEHR CKM.
> Just to summarize,
>
>1. Archetypes in v0 are to be treated as initial suggestions and can
>change anytime and without any pattern. Published ones from v1 are more
>stable and the changes managed better.
>2. Using V0 is at one's own risk and so keeping a local copy would be
>advisable
>3. CKM allows viewing and comparing version history using archetype
>history
>
> The above raises some additional questions
>
>1. What are the specific steps/links to download older version of
>archetypes from the CKM. The archetype history allows comparison between
>versions. But I could not find any link to view/download older versions.
>2. Majority of the archetypes in CKM are unpublished v0 versions. So
>it is difficult to build any meaningful CDR currently using only published
>archetypes. What will be the best strategy to keep moving forward with
>creating real solutions while keeping the spirit of OpenEHR relevant.
>3. Managing copies of the archetypes that are used separately by
>different users is bound to create fragmented schema across openEHR
>compliant CDRs, thereby defeating the fundamental premise of interoperable
>schema among OpenEHR CDRs.
>
> regards
>
> [image: https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8]
>
> Dileep V S
>
> *Founder*
>
> *HealtheLife Ventures LLP*
>
> m:
>
> +91 9632888113
>