Re: Stackoverflow tag: openehr
On 11/11/2017 18:28, Bert Verhees wrote: Well done, Gavin, I hope there will be the needed activity. It may, for some people, being more ad hoc possible to ask questions on Stackoverflow, instead of on one of the mailing lists. We already had once a discussion about OpenEhr on StackOverflow, but it was not tagged right. Hi Bert I've tagged quite a few existing questions now: https://stackoverflow.com/questions/tagged/openehr hope that helps \Gavin ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Stackoverflow tag: openehr
Hi all, Today I created a tag on Stackoverflow for openEHR https://stackoverflow.com/questions/tagged/openehr For it to persist over time there needs to be sufficent level of activity involving openehr tagged questions. enjoy! Gavin Brelstaff CRS4 Sardinia https://stackoverflow.com/users/3507061/gavinbrelstaff ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Re: SNOMED
On 29/04/2016 18:02, Ian McNicoll wrote: Hi Bert, "I think that every leaf-node in an Archetype can be encoded in SNOMED, don't you think?" I'm afraid not even close, especially when you take into account the changes in the meaning of datapoints that apply when used in differing contexts. When doing modelling for histopathologym I was not even close to getting 50% binding of SNOMED to archetype leaf-nodes, ands histopath is one of the better covered parts. A sidenote: 20C Philosophy might help here. Wittgenstein's Tractatus (1921) was failed attempt to pin-down a logical structure on to what can be expressed. Wittgenstein's Philosophical Investigations (1953) especially his language games - accounted for different contexts. /Gavin ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
openEHR-technical Digest, Vol 18, Issue 38
Re: Ontology archetype codes aren't we, here, in the realms of Descriptive v. Prescriptive Grammar? http://grammar.about.com/od/basicsentencegrammar/f/descpresgrammar.htm *Descriptive* obliges you to change whenever the language seems to. *Prescriptive* obliges you to try to hold the language static. The hard bit is gauging the utility of responding to any given change. Gavin Brelstaff CRS4 in Sardinia
Trying to understand the openEHR Information Model
On 15/04/2013 16:15, Bert Verhees wrote: On 04/15/2013 03:37 PM, Grahame Grieve wrote: big risk - it's a combination of how likely it is, and how bad it is if they are. Generally, current location, current medication lists, summary lists are things where contention can happen. Quite often, I've seen, a cascade of things will happen on a patient simultaneously as multiple people focus on the patient The other place where contention is a problem I've experience has been pathology reports that are not complete - in a busy lab doing 2000 reports/day, I observed editing contention 10-20x a day on average. That's pretty low, but the consequences of a clash bad. In the lab, are that updates, or new records? How do you deal with long time transactions? Suppose a lab edits a dataset, saves it in an archetype-model which will be used to store more items. Then lab employee does the following test and saves it. Should it be saved in the same data-set, or in a new version? I don't think you should have long lasting transactions, lasting longer then one millisecond. Maybe in a lab, there should be a client/GUI which stores/caches local until the results are complete. So it depends on the EHR-system and archetypes. And in the current medicationlist, how big is the chance that two edits are done simultaneously? And is it also a GUI question, to refresh the screen, once in a while, so that the chance of a care-professionalist to be looking at the really current medications increases from 99,99% to 99,999%? There can always be a late update from a pharmacy, mostly they update the system at moment of providing medication, but it can always go wrong, electricity fall out, etc. Those screen refreshes are also a GUI-thing. But, of course, it must be prevented. But I think you will agree that there is no need of fancy isolation-schemas. The most basic one will do. And transactions should never take longer then a minimum of time. Say one millisecond. Not everything needs to be resolved by a OpenEHR-kernel. Some things are really a GUI matter. I thought about this a few years ago and came to the conclusion that the GUI/Client would need quite a bit of savvy HCI. The person working on the data need to be kept informed of how/when the system maybe changing under him. Google documents has now come along and does something like that. You're busy editing one section of an article then a networked colleague begins to edit the same thing. GDocs tells you who it is and how to communicate with them by a secondary channel (EHR would be the primary channel). You can both still keep editing but at least you know you are going to have double check the result afterwards. Conflict resolution is best avoided by timely human intervention rather than automated attempts afterwards. And GDocs does well even when clients go offline for a short time. my 2cents Gavin Brelstaff - CRS4
Python / Django experience??
On 01/02/2012 09:13, Erik Sundvall wrote: Hi! On Wed, Jan 11, 2012 at 12:10, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. One of the most interesting things about GIT-like systems is their distributed/decentralized nature where there is not necessarily a single main master repository. (This category of versioning systems are often called DVCS, see http://en.wikipedia.org/wiki/Distributed_Version_Control_System, GIT is just an example from that category Mercurialhttp://en.wikipedia.org/wiki/Mercurialis another example.) Instead of centralization there is very good support for merging multiple branches/forks/origins. I think this mode of operation will suit future archetype development where we might expect considerable activity in many regional archetyping centres and then multi-source merges and good multi-branch change tracking will be useful. The git command-line interface itself would be quite a horrible experience to most archetype authors though so the DVCS needs to be wrapped in something better (CKM-like) for end users. Something like GIT (or Mercurial) itself might work well as a service layer for communication between regional archetyping repositories though, we probably won't need to add much there except some sensible rules for directory structures, file naming etc. Communication protocols etc for GIT are already defined - exposing the repository via a regular webserverhttp://book.git-scm.com/4_setting_up_a_public_repository.html directory is one option. Every regional site will via GIT or Mercurial automatically get a complete history of any other repository it wishes to mirror. Yes Erik, and GIT does it's best (unlike SVN) to help you merge even after a lot of branching: see: http://progit.org/book/ch3-2.html for a nice explanation
Tools for collaborative working
On 16/09/2011 01:09, Timothy Cook wrote: Well, maybe you should consider real open source tools. does git http://git-scm.com/ have any place in the discussion? As a version control/repository system it has the advantage that it's designed to combat bi-trot - while being nicely distributive. github - https://github.com/plans The git repository service for many open-source project (including linux) is _not_ free (as in beer) though.
future ADL-versions
On 23/03/2011 11:54, Diego Bosc? wrote: I was saying that because some of the conditions Thomas said are really clinical knowledge. I want to be able to express that one value should be always greater than another, or that a score value of a scale (norton, barthel...) is the addition of other parts of the archetype. That's what I think should be put on the archetype. I agree with you that GUI should not be on the archetype For me an avenue of clinical knowledge discovery should also be the ideas arriving from UI design - constraints revealed at the UI level may sometimes generalise in unseen ways and so should be able to inform the archetype at some time or another. I share Diego's disappointment in that openEHR seems to discourage the activity that many programmers adhere to: looking for generalization in your code and treating them as discovered knowledge about the domain. In practice, there is a natural barrier between archetype and code since ADL is a declarative language unlike most C, Python, Java etc. Trying to express complex co-occurence constraints in ADL is always going to look ugly and be difficult for non-programmer humans to parse/deal with. Nevertheless, for me, this meeting point between archetype and GUI constraint asks to be a fertile area of research - HCI at its most profound IMHO - not to be left to terminology services. [just my 2 cents] Gavin Brelstaff - CRS4 2011/3/23 Seref Arikanserefarikan at kurumsalteknoloji.com: Hi Diego, Ignoring a section of an archetype/template does not mean that the formalism is now extending its scope beyond data. It does not matter that I ignore it. If it is there, someone will use it, and send that to my system, saying that I've used this feature, so you need to do the same if you want to achieve the intended result. Every change, every addition in ADL space is reflected to multiple dimensions. I'll repeat it again, if someone is interested in developing a formalism using constraint based expressions of ADL, to model GUI/behaviour/etc, there is nothing wrong with that. Just do it out of the archetype, link that artefact to an archetype, and share/use it with the archetype. This way, everything stays clean, and everyone gets what they want. Regards Seref On Wed, Mar 23, 2011 at 1:30 AM, Diego Bosc?yampeku at gmail.com wrote: I will suggest a new optional section on the ADL, if those conditions end in the archetype tree structure it could really be a mess. So if you just want to look for the structure you only have to ignore that section 2011/3/23 Heath Frankelheath.frankel at oceaninformatics.com: Hi Seref, I agree with you sediments regarding Archetypes. However, the AOM still needs to support something like this for templates, in my view this is the level where we will want to start making conditional statements about data constraints (and this is still before we get to the GUI, as I may have the same conditional constraint requirement in an integration scenario). Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Seref Arikan Sent: Wednesday, 23 March 2011 10:03 AM To: For openEHR technical discussions Subject: Re: future ADL-versions Greetings, I have a single question about this particular requirement/idea: why? Archetypes are model artefacts. That is it. They are supposed to describe domain models in a certain way. Behaviour or software that uses those models is a completely different thing. I can understand a constraint which references another one for defining a valid interval etc, but how on earth something like forcing a user for another entry is going to be handled during implementation? How would one express this in common formalisms like XML? I could understand a suggestion to use ADL to express rules regarding the archetypes, but that should be a formalism leaving in a separate space, which may be linked to archetypes, which only-contain-constraints-on-RM-types. Please keep behaviour our of models in ADL specifications. Regards Seref On Fri, Mar 18, 2011 at 8:10 PM, Bert Verheesbert.verhees at rosa.nl wrote: Thanks, Thomas, for your reply. There is more to it then I initially thought of. I am not very familiar with XPath. Best is to wait for more information on the specs. This is enough for now, to let customers give something to think about. Bert On 16-03-11 19:32, Thomas Beale wrote: Hi Bert, I hope to get back on the spec in the next couple of weeks. With respect to your specific question below, can you be a bit more precise? There are ways to express this kind of thing, but we need to be clear on distinguishing references to: * elements in the same archetype - as in a rule like: o /path/to/systolic/pressure/value /path/to/diastolic/pressure/value * elements in data elsewhere in the same EHR like:
Thoughts after 7 Years of Being a Web-based Patient Registry Architect
The blog entry by Ogbujis linked below may be of solace to some of us - it includes this conclusion.. I also think much of the risk aversion associated with the atmosphere I found myself ... in large institutions contributes to why the very evident opportunities in leveraging rich web application (?web 2.0?) and semantic web infrastructure (?web 3.0?) have not had as much penetration in healthcare information technology as one would expect. http://copia.posterous.com/desiderata-and-architectural-constraints-of-w
REST Based Services and Storage Interfaces for openEHR Implementations
On 26/11/2010 16:48, Erik Sundvall wrote: Hi all! We had a poster titled REST Based Services and Storage Interfaces for openEHR Implementations at a Swedish conference in September. I have now finally gotten around to reformatting it to be readable when read on screen or printed as a three-page booklet on normally sized (A4) paper. It is available at: http://www.imt.liu.se/~erisu/2010/EEE-Poster-multipage.pdf Some of you have already heard these ideas at Medinfo in Capetown. Questions and discussions are very welcome (preferably on the technical list, not the clinical one that I am cross posting this announcement to). We are now in the process of writing a proper paper about this and will of course release our implementation as open source. Erik I've been experimenting with the eXist.org DB that lets you GET and PUT (and version) hierarchical records (XML) RESTfully to from the browser without any intervening layer (unlike PHP etc). It works well for my non EHR web-app - that uses jQuery to tame my in-browser code. It probably not industrial-strength but the eXist way has plenty of standards based ways of getting things done - including xQuery pipelines incorporating user specified Java modules. could be something to consider. BTW I doubt there's much usage for HTTP DELETE for audited EHR. Gavin Brelstaff
[openEHR-announce] Message from the Board - openEHR Intellectual Property
On 03/06/2010 00:18, Tim Cook wrote: Thanks for that research and organization work Erik. Whether Sam (as a Board member) or anyone else has presented any 'strong arguments' to the other Board members is an unknown and frankly, I think, is irrelevant. Over the past decade, we can probably count on our fingers the number of threads that a Board member other than Sam has participated in on any of the open mailing lists. They have participated on the ARB list and in private group mails where the audience is controlled. IMHO, this speaks loudly as to the desire of (or lack of desire) those members have to demonstrate any community building leadership. Neither has there been any move towards true open democracy in Board membership. Tim, Despite any such obscurity of boards, licenses and standards - perceived and actual - and I too am slightly skeptical - ... I think we cannot but applaud the openEHR in its putting online of the CKM system - which democratizes the process of specifying archetypes - in a way previously unheard in healthcare standards collaboration. Okay if archetype specs are wrong then this collaboration is undermined, but the CKM is quite a leap forward after a decade or two - don't you think? \Gavin Brelstaff CRS4
Latest ADL / AOM 1.5 template specification drafts
On 08-Mar-10 11:25, Thomas Beale wrote: A new draft is now up of the AOM 1.5 at http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf . This draft adds in group construct, providing the same capability as XML schema choice/sequence/group for ordering elements within container attributes. The AOM constraint model with this added in looks as follows: http://www.openehr.org/wiki/download/attachments/196633/AOM_with_group.png Hi Thomas, Thanks for the new draft: adl_1.5. I imagine that openEHR is the art-of-the-possible so I really value your latest updates: In Section 6 - Assertions I note the the advent (in standard cADL syntax) of Rules involving QUERY RESULTS from a data or knowledge context - for example (from Section 6.5.5): $has_diabetes:Boolean ::= query(ehr, has_diagnosis, snomed_ct:1234567) $is_female:Boolean ::= query(ehr, is_female) Does this kind of rule provide some sort of basis for implementing generalized methods (I'm thinking of OOD association relationships) at the archetype level? Archetyped objects - with their hermetically sealed inner states - probably need to share some state info in order to do useful EHR-related work. And the way in which that state needs to be shared may reflect semantic order of the modeled EHR beyond that established by the containment/inheritance constraints envisaged by openEHR at the RM and CKM level. Are we sure that this semantic order is best left to a set of external queries and, or, relegated to details of local template modeling? My pet ruse with openEHR has been that when we get down to the perspective of the data entry GUI - the validity of the data-input may depend on knowledge hermetically hidden way in another archetyped object - and I'd like a principled way of generalizing the validation rule (for reuse) - who knows: it might even be important semantic element of the pattern of system of archetypes. And informal semi-structured querying such as query(ehr, is_female) still seems a bit of an abdication of responsibility to me. Gavin Brelstaff CRS4 Sardinia Italy.
Term bindings in archetypes and templates
On 11-Mar-10 12:59, Stef Verlinden wrote: For those of you interested in the 'problems' within Snomed as an ontology, here (http://precedings.nature.com/documents/3465/version/1) you can find a good and recent article describing them. This doesn't mean we shouldn't use Snomed, but knowing where the problems are is helpful to find solutions as Thomas already stated. Nice work!
Where can I download the OpenEHR terminology?
Hi Ron Rong Chen an all: The URL to the terminology xml file is: http://www.openehr.org/svn/ref_impl_java/TRUNK/mini-termserv/src/main/resources/openehr_terminology_en.xml Possible import bugs in this file appear beneath line 580: group name=participation mode Everywhere the the attribute rubric contains a hyphen - the text seems to be unduly truncated. E.g. line 584: concept id=217 rubric=signing (face-to-/ hope that helps Gavin Brelstaff CRS4.
ADL - syntax highlight for Notepad++
I wonder if anyone has created themselves a syntax highlight file for use with Notepad++ http://notepad-plus.sourceforge.net/uk/site.htm and would be willing to share it? Gavin Brelstaff CRS4
Issues around UI technologies and bindings to back end
Thomas Beale wrote: To clarify one thing: UI structures have to be based on templates, which are essentially specific 'data set' definitions, not archetypes, which standardise all content irrespective of any particular use. But I agree with the point that any such artefact cannot be assumed to be a direct basis for automated GUI building. I don't think it is impossible, merely difficult (which reminds me of the Galen motto: making the impossible very difficult). Re: ADL files; the reason ADL exists is because an ADL archetype is definitive - there is only one possible expression. With XML on the other hand, we have the current published schema; in the near future, I suspect it will be upgraded to be more efficient (seems everyone hates innefficient XML), and that could easily happen a few more times into the future. Practically speaking, you are right, most normal system / product developers/vendors don't need to care about the ADL if they don't like it, they can just use the XML, and everything will work fine. If ADL is 'hampering adoption' then we need to improve how we communicate the notion of archetypes, how to use them etc. Suggestions in this area are welcome. - thomas beale Hi Thomas May be I can frame the question in a different way: Is what we have now (including imminent Template Spec) an advantageous starting point for building EHR data entry / GUI interfaces or is it perhaps an impediment: requiring a compliance which might pragmatically only be obtained by retro-fitting software to the published archetypes/templates ? My doubts arise from the fact that in traditional Object-Oriented Design (OOD) the overall architecture is informed _simultaneously_ by two independent formative factors: structure and behaviour. The structural factor appear to be dominant in the formation of openEHR archetypes - even in the CKM - with any behaviour / methods / operation being left as technical afterthoughts. This might not matter if programming a GUI interface can simply be made a question of implementing any required behaviours in the objects of the classes derived (via templates and slots etc) from the openEHR archetypes. But if the nature of these behaviours do not conform to the containment model specified by the openEHR archetype hierarchy then the implementer is right to ask the question: should I refactor the archetypes (as normal OOD requires) or should I accepted reduced behaviours to avoid their impacting those archetypes? Personally I like the ADL specification - it is human-readable in a way that neither XML nor any programming language like Java, or even Python, is. But the very fact that it omits behaviour implies that is declarative and is actually Declaring Documents and not Modelling Information per se. I would have thought the openEHR would have become more document-centric than it is now. I know there are archetypes for document Sections - but that marginalises the fact a document-based interface is what most non-techie humans are capable of comprehending and not to follow this venerable tradition leads to information disorientation. So why facilitate the freedom to diverge from it? An analogous approach to openEHR would be simply to specify constraints on the legal content of particular Health Record documents. Commonalities between the document sections might be marked up - in the same spirit of inheriting reuse as is adopted for discovering archetypes in openEHR . Of course today's web-fed technologies attempt to do all this in ugly unreadable XML which gets transformed into humanised GUI pages/screens. As I commented else where recent advance in server and browser implementations mean that xForms armed with well designed schema specifications might be up for this job. Yet I am still not sure what to make of MS-CUI - its demos seem particularly disorientating and techie-targeted. My problem here is that any data-entry objects get instantiated when they arrive in browser's document object model and (to me at least) it seems that they may be completely different objects to those archetyped at the highest level of the design and so - even with an excellent template specification - it may be unprofitable to think about adding methods to classes based on archetypes as OOD is usually progressed. I am interested in ways of reconciling openEHR archetype/templates with browser mediated documents ? based on open-standards. I'd be pleased if anyone else might care to comment on this could be achieved. Gavin Brelstaff CRS4 Sardinia Pula (CA) Italy
CKM - 250th registered user
Heather Leslie wrote: Hi everyone, We just had our 250th user register in the Clinical Knowledge Manager today! Seems like a pretty good milestone to share and celebrate to me! Seem more user stats http://openehr.org/knowledge/#userstatistics here: 95 reviewers, 24 translators, 42 countries www.openehr.org/knowledge Regards Heather I must say the advent of CKM seems to me to be a great breakthrough and a very good example to the world of how collaborative semantic specification can be done online. Congratulation to all involved and especially the Sebastian who seems to be the technical lead with a human understanding. Cheers Gavin Brelstaff CRS4
Issues around UI technologies and bindings to back end
Hi Seref, Seref Arikan wrote: I've written an initial set of things here : http://www.openehr.org/wiki/display/projects/Technology+and+architecture+challenges+in+UI+implementation. based on Opereffa, but I'd really like to hear how others are tackling UI layer. I'm a little bit worried since I can see MS CUI ... I had a look at these Silverlight controls - such as http://www.mscui.net/Components/SingleConceptMatching.aspx etc - perhaps I missed something, but I can't see anything greatly different from what a Luddite like me might achieve with XHTML-like select, check-boxes etc. Complexity grows, in any case, when one considers screens where one data-value (e.g. drop-down list) should vary in accordance with another control's value (e.g. another list's item). I am not even sure how openEHR archetypes fully allow such co-occurrence constraints to be defined - I guess I'd try using invariant rules. This isn't just a case of panels/containers being present/visible or not - as archetype-slot toggling ought to be able to handle. If we assume that detailed co-occurrence variations can be declared as ASL invariant rules then - IMHO - it makes sense to take that declarative approach down to the GUI level and interpret such rules at data entry. This is what xForms was supposed to be designed to do (using it's bind declarations) - but the majority opinion of openEHR developer is that xForms are dead in the water - and we should instead instantiate object-oriented widgets to implement our GUIs. I am not so convinced - I've played with the Orbeon xForms server http://www.orbeon.com/ which embeds the eXist xml-db an I am quite impressed just how far you can get in modern browsers without writing javascript or requiring plugins. XML in XML out. It's nice to be web-based/RESTful since it gives you so much for free. It would be nice to implement a demo that compiles-down ADL to a form Orbeon can serve - but, as I noted earlier, this is not a main-line idea here: for one thing it mostly throws out the O from the AOM. Good work with Opereffa Gavin Brelstaff CRS4 Sardinia Italy.
cADL assertion, invariant, validity - any practical examples of use?
Hi I'm considering how I might constrain layout in an EHR GUI depending on constraint made in an adl file. cADL assertions look a plausible way to go. But I don't see anyone using the invariant keyword in their ADL files - has anyone got any practical examples of doing so? Any help gratefully accepted. Gavin Brelstaff Sardinia
Layers of interoperability, OWL and openEHR
Hugh Leslie wrote: Who would ever have thought that a technician would have such poetry in their soul - perhaps there is hope for semantic interoperability after all... :) Who does understand semantic interoperability? The beauty of human interaction is that we can get along even without understanding each other. And we?ll never get computers to understand each other. So we shouldn?t aim for semantic interoperability, we should aim for unsemantic interoperability This is where openEHR gets even more interesting: where Shannon-Weaver meets Jakobson's six communication functions: http://en.wikipedia.org/wiki/Roman_Jakobson/The_communication_functions poetry is the hardest thing to translate but often worth the while. Discuss!
Layers of interoperability, OWL and openEHR
Hugh Leslie wrote: Who would ever have thought that a technician would have such poetry in their soul - perhaps there is hope for semantic interoperability after all... :) Who does understand semantic interoperability? The beauty of human interaction is that we can get along even without understanding each other. And we?ll never get computers to understand each other. So we shouldn?t aim for semantic interoperability, we should aim for unsemantic interoperability Oops that WikiP url was wrong - the one below works This is where openEHR gets even more interesting: where Shannon-Weaver meets Jakobson's six communication functions: http://en.wikipedia.org/wiki/Roman_Jakobson#The_communication_functions
