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 <openehr-clinical-boun...@lists.openehr.org> On Behalf Of Paul Miller Sent: Tuesday, May 28, 2019 12:40 PM To: For openEHR clinical discussions <openehr-clinical@lists.openehr.org> 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 <i...@freshehr.com<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 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<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Director, freshEHR Clinical Informatics Ltd. CCIO inidus Ltd. i...@inidus.com<mailto:i...@inidus.com> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto: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<mailto: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 <openehr-clinical-boun...@lists.openehr.org<mailto:openehr-clinical-boun...@lists.openehr.org>> On Behalf Of Ian McNicoll Sent: Tuesday, May 28, 2019 10:15 AM To: For openEHR clinical discussions <openehr-clinical@lists.openehr.org<mailto:openehr-clinical@lists.openehr.org>> 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<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Director, freshEHR Clinical Informatics Ltd. CCIO inidus Ltd. i...@inidus.com<mailto:i...@inidus.com> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org> Hon. Senior Research Associate, CHIME, UCL On Tue, 28 May 2019 at 07:18, Sebastian Garde <sebastian.ga...@oceaninformatics.com<mailto: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 <openehr-clinical-boun...@lists.openehr.org<mailto:openehr-clinical-boun...@lists.openehr.org>> Im Auftrag von Dileep V S Gesendet: Dienstag, 28. Mai 2019 07:11 An: For openEHR clinical discussions <openehr-clinical@lists.openehr.org<mailto:openehr-clinical@lists.openehr.org>> 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 [https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8] Dileep V S Founder HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: ehr.network, <http://ehr.network> ayushehr.com<http://ayushehr.com> e: dil...@healthelife.in<mailto:dil...@healthelife.in> On Tue, May 28, 2019 at 2:15 AM Sebastian Garde <sebastian.ga...@oceaninformatics.com<mailto:sebastian.ga...@oceaninformatics.com>> wrote: Hi The v1 to v0 migration was a once off thing that was decided to be the best for never before published archetypes. I’ve never been a big fan of v0 because of the all the complications it has, but at least it tells you clearly that all bets are off regarding this archetype because it is under development and anything goes, including changes to its archetype id, if required. V0 is also consistent with SemVer (although you could do it differently as well, e.g. 1.0.0-alpha). After publication to v1, the governance is more formal and follows semantic versioning of patch, minor and major versions. It may not always be nice, but unless someone can provide a comprehensive, clean and perfect set of archetypes, that’s what life will be for a while. CKM aims to support the processes around the development, review and publication of the archetypes etc. as much as possible. In CKM, the revision history of an archetype links back to any previous (or next) major version of the archetype. See e.g. the Blood pressure v2 archetype. You can get any (trunk) revision of the archetype that was ever uploaded to CKM from there and compare any two revisions. Archetypes that were updated in the last couple of years will have the SemVer version in it as well, and there is always the canonical hash (the one used in the template) you can use to determine the right version of the archetype if required. I hope this answer your questions below and provides a bit of context in between. Regards, Sebastian From: openEHR-clinical <openehr-clinical-boun...@lists.openehr.org<mailto:openehr-clinical-boun...@lists.openehr.org>> On Behalf Of Pablo Pazos Sent: Montag, 27. Mai 2019 20:37 To: For openEHR clinical discussions <openehr-clinical@lists.openehr.org<mailto:openehr-clinical@lists.openehr.org>> Subject: Re: Downloading previous versions of archetypes from CKM You might also have problems with some archetypes that went from .v1 to .v0 In the archetype history you can see the previous versions, but some will have a broken history, for instance some archetypes changed name and archetype id but serve the same purpose as the old archetypes, which broke any implementation of the previous archetype. Also there is no clear history of archetypes changing ID or merging archetypes. Because of those issues is difficult to trust what is on the CKM in the long term. I decided to work with older archetypes to keep my baseline clean and stable, do modifications on those if required, and create our own archetypes when required. I'm not sure if this is because how the CKM manages archetypes, or because the modeling process have flaws in the version management. On Mon, May 27, 2019 at 5:01 AM Dileep V S <dil...@healthelife.in<mailto:dil...@healthelife.in>> wrote: Hi, I had used some archetypes from CKM in my templates some time back. Now when I am revising & reviewing them I notice that some of the archetypes have newer versions an so my templates give error as they are unable to locate the older versions that they use. So I have a few questions on the best practices for using CMK resources 1. Can I access older versions of archetypes from CKM? and how? 2. Should I maintain a copy of the archetype versions that are used in my templates separately? 3. Are archetype versions incremental improvements? If yes should the AQL not support multiple versions to maintain backward compatibility as the templates evolve? regards [https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8] Dileep V S Founder HealtheLife Ventures LLP m: +91 9632888113 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100 w: ehr.network, <http://ehr.network> ayushehr.com<http://ayushehr.com> e: dil...@healthelife.in<mailto:dil...@healthelife.in> _______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- Ing. Pablo Pazos Gutiérrez pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com> +598 99 043 145 skype: cabolabs Subscribe to our newsletter<http://eepurl.com/b_w_tj> [https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc&export=download]<https://cabolabs.com/> http://www.cabolabs.com<http://www.cabolabs.com/> https://cloudehrserver.com<https://cloudehrserver.com/> _______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org _______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org _______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org _______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org<mailto:openEHR-clinical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
