Musings about a more web-friendly openehr
The dwarf sitting on the shoulder of a giant, moves forward faster, but sees things the giant cannot see. They cooperate. http://upload.wikimedia.org/wikipedia/commons/4/4a/Library_of_Congress%2C_Rosenwald_4%2C_Bl._5r.jpg On 11/28/2013 02:24 PM, Ingram, David wrote: > > Dear Bert, > > On behalf of the founding fathers of openEHR, with the longest memory > and record of its evolution from the early nineties, this is just to > say thank you for your Thanksgiving Day Hallelujah -- best Leonard > Cohen style, no doubt! I have to say, slightly ruefully, that if, as > you suggest, we were entrepreneurially driven, then we were somewhat > mad to be so -- a 20 year start up is not seen as good business in the > modern era, I fear! > > Not for nothing did we describe the three top priorities of openEHR as > implementation, implementation and implementation, mindful of its very > steep learning curve as it was always very steep for us, too. The > implementers, and we should include the clinical data modellers as > well as the software developers in that term, are the heroes of the > transformation that is coming in health care IT, as a modular and > interoperable architecture gains currency, as it inevitably will. It's > with great pride that we see different and independent foci of openEHR > implementation growing apace in Western Europe, where it all started, > Central and Eastern Europe, Asia and the Far East, Australasia, South > America, and no doubt elsewhere as well, since most hits to the web > site historically have come from North America. In my new parallel > world in OpenEyes, we are seeing its open source applications > beginning to spread and take root, similarly widely. > > It was one of the privileges of my career to meet and correspond with > Octo Barnett when he was transforming health care IT and I was a PhD > student travelling the world to meet the founders of the field. In > MUMPS he created a new database paradigm for its time, informed by the > practical needs of medicine and inspired too by his concern for > medical education. In the New Pathways programme at Harvard, as well, > which was one of the early initiatives exploring how innovation was > changing the nature and craft of medicine, and therefore how new > students needed to be taught and learn differently, he showed the > talents of visionary, doughty pioneer and craftsman that are needed to > turn the world upside down. It's a good tradition and example for the > implementers of today to seek to follow. > > I'm confident that openEHR is in safe new hands and is not going away. > As always, it's there to play and support whatever roles seem most > fitting, as the modular ecosystem of digital care records, that health > care sorely needs, comes into being. > > Thanks again for your kind words and best wishes, > > David (Ingram) > > > So think beyond that. That is one of the good things of the designers > of OpenEHR, and more, the designers of the side effects, like AOM, > which are important beyond the boundary of OpenEHR. > > Today is thanksgiving? Let us thank those people for their wonderful > work which started about in the beginning of this millennium, or even > in the end of the previous millennium. > > They designed an eco-system without having a technical reference to > build it. They showed the courage of Henry Ford. They were inventing > technical solutions, instead of conforming to technical solutions of > the that time current which is now the past. > I know, through the years, people struggled a lot with how to > implement it. And I know, most of them do not admit that. Every > implementor has to solve his own secret problems. OpenEHR is not an > open developer-community, but it is a community of entrepreneurs which > all want to be the number one. > > What would have happened if OpenEHR was designed conforming the > technical possibilities of 1999, would we still have been talking > about it right now? > > OK, enough of hallelujah. > > What's next > > - Tooling is good, but tooling is always situation/platform depending. > It is not a fundamental solution. > - Simplification in order to solve technical problems is conforming to > the past and is not a good way. > > We need to think deeper about this. > I did not get in this any further then the path/value combinations, > and insuccession, the short path notation (which makes it in fact more > complicated). > > Bert > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/20acd24c/attachment.html>
Musings about a more web-friendly openehr
On 11/28/2013 02:43 PM, pablo pazos wrote: > One is, the most important, but not in our hands, make the AOM > important, create RM's above the AOM, use it for other purposes than > OpenEHR only. The more the AOM is used, the less developers will > complain about complexity. > > IMO end system developers should not even know about AOM. We can > create stuff that hides that from them and they can just consume APIs > the way they are familiar with, e.g. like they consume Twitter or > Google Maps APIs. I think you misunderstood. What I wanted to say, if the AOM is used in a wider/broader field then OpenEHR, it is something developers get used to, and because of the broad use they are motivated to get on the learning curve. In my opinion there are several levels of API-possible. One level is semantic rich, like createObservation, then there can be, a bit more generic: createEntry, but it can also be completely generic, like createObject. Depending on the reference model the object can be a Locatable, if it is an OpenEHR or 13606 Reference Model, but as far the AOM concerns, Locatables do not exists. The AOM only knows archetypes, an AOM-instance-structure is created by the ADL-parser, and as the parser eats it, you have a valid AOM-structure. This is a powerful concept, which can be served by a generic API, but what that will look like, I don't know. To overcome acting in the wild, and creating data without predefined structure, archetypes need to conform to a Reference Model. So there is a two way validation needed: One, is the archetype conform the Reference Model? This only is needed at creating time of the archetype. The other is are the data conform the archetype? Many other fine features are also available on base of AOM, like AQL and templates. Anyway, that was what I am thinking about when developers know the AOM. When you have these things organized, you have a generic database-engine on base of the AOM. I think, very powerful concept. But there are some black holes, and one of them is the communication between client and server. As you know, I do it on base of path/value combinations, but many others do it on base of a kind of object-instance-natation, DADL or XML or JSON, or whatever. Bert -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/0170ea53/attachment.html>
Exception messages on TemplateDesigner 2.7.60.2
Your are my hero!!! Thanks -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: k...@dips.no To: openehr-technical at lists.openehr.org Date: Thu, 28 Nov 2013 15:11:14 +0100 Subject: RE: Exception messages on TemplateDesigner 2.7.60.2 Go to Tools -> Knowlegde Repository -> Edit repository list. Verify that you have set the template files directory. Had a similar problem and the solution was to set a default directory for template files. With regards, Kjetil J?rgensenDeveloperDIPS ASA Telephone +47 75 59 21 18Mobile +47 90 50 15 65 From: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of pablo pazos Sent: 28. november 2013 15:03 To: openeh technical; openehr implementers Subject: Exception messages on TemplateDesigner 2.7.60.2 Hi all, I'm creating a template from scratch with my own archetypes created using Archetype Editor (attached). When I try to save the template I get weird messages: - Cannot access a disposed object. Object name: 'FileSystemWatcher'.- Object reference not set to an instance of an object. Any ideas? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/6130318f/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38335 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/6130318f/attachment-0002.png> -- next part -- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 38939 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/6130318f/attachment-0003.png>
Musings about a more web-friendly openehr
Hi Bert, -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Fri, 29 Nov 2013 08:47:34 +0100 From: bert.verh...@rosa.nl To: openehr-technical at lists.openehr.org Subject: Re: Musings about a more web-friendly openehr On 11/28/2013 02:43 PM, pablo pazos wrote: One is, the most important, but not in our hands, make the AOM important, create RM's above the AOM, use it for other purposes than OpenEHR only. The more the AOM is used, the less developers will complain about complexity. IMO end system developers should not even know about AOM. We can create stuff that hides that from them and they can just consume APIs the way they are familiar with, e.g. like they consume Twitter or Google Maps APIs. I think you misunderstood. What I wanted to say, if the AOM is used in a wider/broader field then OpenEHR, it is something developers get used to, and because of the broad use they are motivated to get on the learning curve. I understood. My opinion is they don't even need to have that learning curve (in most cases there is not enough time and they have to show working results in a month or so). In my opinion there are several levels of API-possible. One level is semantic rich, like createObservation, then there can be, a bit more generic: createEntry, but it can also be completely generic, like createObject. In that approach the API is forcing developers to know what is an ENTRY or an EHR OBJECT. If we use just an XML, we need to tell them how to create it, and that's specified on XSDs. Creating an XML is simple and they just need to know where to put their data, e.g. in an ELEMENT.value tag.Then if we have only one commit service on our API, they just need to send the XML without knowing much about the meaning of each RM class, or AOM paths and node_id. We just need to tell them to copy the right values in the right places of the XML. Of course this is not the best approach conceptually speaking, but is a pragmatic one, just to get things done. But is just my opinion. Time will tell if I'm right or terribly wrong :) Depending on the reference model the object can be a Locatable, if it is an OpenEHR or 13606 Reference Model, but as far the AOM concerns, Locatables do not exists. The AOM only knows archetypes, an AOM-instance-structure is created by the ADL-parser, and as the parser eats it, you have a valid AOM-structure. This is a powerful concept, which can be served by a generic API, but what that will look like, I don't know. To overcome acting in the wild, and creating data without predefined structure, archetypes need to conform to a Reference Model. So there is a two way validation needed: One, is the archetype conform the Reference Model? This only is needed at creating time of the archetype. The other is are the data conform the archetype? Many other fine features are also available on base of AOM, like AQL and templates. Anyway, that was what I am thinking about when developers know the AOM. When you have these things organized, you have a generic database-engine on base of the AOM. I think, very powerful concept. I understand, but this process you mention seems to be closer to an ontological approach than to implementation. IMO formal ontologies for validating models and then validate data are good for research, but this approach is very far from real world implementation. Yes I know there are exceptions, but those exceptions came from research. What I mean is when you need to develop a software that should be used by doctors and you have 4 months to do it. I'm focusing on this kind of projects when I mention to simplify things for app developers so they can use openEHR without even knowing it. What do you think? Cheers! But there are some black holes, and one of them is the communication between client and server. As you know, I do it on base of path/value combinations, but many others do it on base of a kind of object-instance-natation, DADL or XML or JSON, or whatever. Bert ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20131129/df2e67a0/attachment.html>
