Re: Announcing Archie version 0.4
Great work! A very good contribution both as code (with widely usable licence) and in practice as a specification debugging effort! //Erik Sundvall P.s. Regarding Javascript I’d recommend looking at the related Typescript superset instead for anybody wanting to do implement openEHR RM or AM on client side in browsers. It will likely feel more familiar for Java (and Eiffel) people and others wanting to do generics, type checking etc. Is anybody out there working on or planning a Typescript (or possibly JavaScript) based openEHR library implementation with a permissive open source licence (like Apache 2)? I guess many thoughts and design patterns from Archie could be reused... Such a library could be used for e.g. https://angular.io/ and/or https://nodejs.org/en/ based projects. lör 3 feb. 2018 kl. 22:12 skrev Peter Gummer <peter.gum...@gmail.com>: > Interaction with a JavaScript front-end could be done with any back-end > programming language — it doesn’t have to be Java. > > So your point is that Archie's serialisation and deserialisation to JSON > will will assist this? I believe Thomas’s Eiffel implementation already has > JSON serialisation, since about 5 years ago. > > Peter > > > > On 3 Feb 2018, at 23:03, Pieter Bos <pieter@nedap.com> wrote: > > > > Or a Java app with rest api and a JavaScript frontend. Let the java > application take care of parsing, validating, flattening, operational > template creation etc and send json to your front end. Archie has built-in > json serialization and deserialization support. > > > > Pieter > > > > Op 3 feb. 2018 om 12:05 heeft Seref Arikan < > serefari...@kurumsalteknoloji.com<mailto:serefari...@kurumsalteknoloji.com>> > het volgende geschreven: > > > > Hi Peter, > > > > Presumably via use of a transpiler or a bytecode to js/webassembly > compiler. > > > > On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer <peter.gum...@gmail.com > <mailto:peter.gum...@gmail.com>> wrote: > > On 1 Feb 2018, at 05:13, Thomas Beale <thomas.be...@openehr.org thomas.be...@openehr.org>> wrote: > > > > ... But the main interest is that we will be able to build new tools > such as a Java/JS replacement for the ADL Workbench, and of course things > like a high-quality, BMM-driven runtime archetype validating kernel for EHR > systems, workflow implementations and many other components. > > > > Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how > Archie (written in Java, disappointingly) would enable JavaScript > implementations. JavaScript has nothing in common with Java (apart from the > name). > > > > Peter > > > ___ > openEHR-technical mailing list > openehr-techni...@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Sent from mobile. ___ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
Re: Versioning implementations
Hi! Shared care-plans, medication lists and allergy lists often need to be updated by several care providers that have different EHR-systms separated by both legal and practical/technical barirers; for example regional vs municipal care in Sweden or private vs public care providers. Today in (usually non-openEHR contexts) that is often done by either: 1. using a separate shared system just for shared care plans etc (which means a degree of double data entry and manual transfer/reentry of things from/to different EHR systems that the patient has records in at different care providers) or 2. forcing everybody to use the EHR system of the "biggest" care provider in the (or that systems shared care planning module). Pretty convenient for the big actor but a mess for the other smaller ones, especially those that have a patient mix from several different "big" providers using the "use my system" attitude... So yes the multi-provider shared records with branch/merge capabilities are certainly needed if we want to avoid #1 and #2 above. And yes merge will be a headache for users when it occurs, but likely less of a headache in total than #1 and #2 above. I believe enough of the subgroup of clinicians dealing often with shared care will become proficient enough to handle merging. The "lock" approach (only allowing one party to change at a time) would only work if things were entered and synced fast and at once after the care event had happened. In reality a doctor may read version 12 of the medication list when seeing the patient on Friday and audio-record an update (that should become version 13), that gets transcribed and recorded in the EHR after the weekend. During the weekend the patient needs to go to another care provider (e.g. emergency) that also looks at version 12 (since that is the latest recorded one) and immediately after the consultation records a version 13. See the merge conflict? In this case it might need to be resolved by the care takers contacting each other to agree on possibly conflicting persciptions. What happens today without openEHRs ability to at least detect a merge conflict is not always good for patient safety. Many openEHR implementations today are single-care provider systems and then you don't handle/detect the conflicts using the system, but hopefully some other way. I agree that a distributed versioning could be specified as optional in some openEHR conformance profile for single-care provider systems, but it should certainly not be taken away from the openEHR specifications! This also means that the version identifiers used in the specs (e.g. 8849182c-82ad-4088-a07f-48ead4180515::ehr.examplecareprovider .org::12) should still contain the system id (e.g. ehr.examplecareprovider .org) even in single-care provider systems so that they can later be upgraded (or their possibly signed data can be moved) to a system capable of full distributed versioning. Best regards, Erik Sundvall Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in Sweden) Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se) http://www.regionostergotland.se/cmit/ Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/ On Mon, Aug 21, 2017 at 10:58 PM, Pablo Pazos <pablo.pa...@cabolabs.com> wrote: > I agree. The singleton is not one persistent compo, but the instance > associated with an OPT of a persistent compo. When talking about singleton > instances we should define what is considered the "class" :) My mistake. > > In the case of care plans, different care plans will be defined by > different OPTs, same for medication lists if needed and modeled that way > (some systems might only need one medication list, one problem list, etc. > by EHR). > > But again, these are all clinical modeling decisions. A bad model might > represent different care plans with the same OPT, and of course this breaks > the singleton concept, but we are talking about subjectiveness here, so > there are no hard rules (call it probabilistic singleton). > > > Best, > Pablo. > > > On Mon, Aug 21, 2017 at 5:40 PM, Bert Verhees <bert.verh...@rosa.nl> > wrote: > >> Pablo, one small remark, a persistent composition is not really a >> singleton. Not conceptually. A patient can have more care - plans, for >> example, at different care - institutions or multiple care - takers at a >> single institution, or have multiple medication-lists. >> >> Bert >> >> On ma 21 aug. 2017 19:24 Pablo Pazos <pablo.pa...@cabolabs.com> wrote: >> >>> Hi Bert, excellent questions! >>> >>> >>> On Aug 21, 2017 5:55 AM, "Thomas Beale" <thomas.be...@openehr.org> >>> wrote: >>> >>> >>> On 21/08/2017 09:09, Bert Ver
Re: New open source ADL2-Library
Great news! Apache 2 is a good licensing choice, that is what we recommend for openEHR open source projects, although some contributors have felt reasons to use other licences. Apache 2 for example makes it easier for some companies to allow staff to spend paid working time on improving industry/community-shared open source components that they use in their closed or open platforms. Nowadays I'd guess more openEHR software implementation work is done by business employees during paid time than by volunteers using their spare time. Having more ADL2 parsers does bring some extra benefits: - compatibility tests and discussions can clarify the specification if needed - more of the possible design space is explored by more teams that can learn from each other However having a dozen of open source ADL2 parsers would probably be a waste of developer effort. I think the same goes for archetype/template editing tools, having a handful of tools explores more options and brings up more good discussions than having a single one, but having too many would potentially be a waste of developer effort. If you want to, then please to tell us a little bit more about the context/product that you will be using the parser in. Best regards, Erik Sundvall Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in Sweden) Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se) http://www.regionostergotland.se/cmit/ Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/ On Wed, Oct 28, 2015 at 7:34 PM, Bert Verhees <bert.verh...@rosa.nl> wrote: > Thanks very much, Pieter, great job! > > Bert > Op 28 okt. 2015 18:20 schreef "Pieter Bos" <pieter@nedap.com>: > > I would like to announce a new open source ADL2 library, written in Java. >> It is based on the ANTLR-grammar released very recently by Thomas Beale. >> >> You can find it at https://github.com/nedap/archie >> >> It is still very much in development, but it is now at a state where it >> could be of use to people. It currently features: >> >> - an ADL2-parser that parses the full definition, specialises, >> terminology, value sets and (a subset of) rules sections >> - an archetype object model implementation >> - a flattener that can also make operational templates - still needs >> testing and work! >> - basic path queries with node ids and node meanings. >> - an experimental Archetype treewalker for openEHR reference models it >> can save you many instanceof calls. >> >> It parses most valid ADL2 files i¹ve tested it with into an archetype >> object model. That includes most of the content of the clinical knowledge >> manager. We¹re currently using this same library for an openEHR >> implementation and we will add features, fixes and tests to it as we >> progress. >> >> You might ask, why a new library? Don¹t we have adl2-core already? The >> answer is quite simple: licensing. >> We could not use the adl2-core library for our projects, because it would >> require us to release the entire project under the (A)GPL. So we ignored >> the existing library and built our own. And now we release Archie under >> the Apache license. This means you should be able to use it in any project >> you like. >> >> Want to help? Great! There¹s a list of missing functionality on the github >> page. Just fork and create a pull request. Or just report any issues you >> find on the github issue tracker. >> >> Regards, >> >> Pieter Bos >> Nedap Healthcare >> >> >> ___ >> openEHR-implementers mailing list >> openEHR-implementers@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >> > > ___ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org > ___ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
