Hey folks,
Following on from the discussion about adl path / xpath, XSDs, and so forth. Here's something semi-random that I've been thinking about for a while and I thought I might share. I figured now might be a good time for that, with the work ongoing on openehr 2.0.
Status
Hi Leo,
I think simplifying openEHR is not a good strategy. The problem is that most programmers are not implementing against openEHR specs, they are implementing against other people’s implementations. So they have the learning curve of the specs + the learning curve of using provider XWZ tools.
We as developers/providers should make things easy for non-openEHR developers. E.g. creating tools that allow to work with openEHR without knowing that openEHR is even there (that’s the main design principle of EHRServer). We should deal with complexity so they don’t have to know what an archetype id is, or a path or a node_id, etc.
If they can create an XML and invoke REST services to commit and query data, and process the returned XML or JSON, that’s all they need to do/know. But we’re not making things easy for them, and we’re pushing complexity to other layers the system like the UI (and we shouldn’t).
All of this is my motivation to do research and create tools that generates UI from archetypes or allow to commit and query data using REST services (e.g. anyone can create an app to query and chart data from EHRServer in 1 hour of work, I did the experiment: https://github.com/ppazos/EHRClientPHP).
It would be great if all of us, openEHR developers, could share the experiences of developing with other non openEHR programmers, and the pitfalls & problems they had through the process.
Hi Pablo, you are talking about tooling, which is one way to approach the complexity-problem. A good way too. Hide the complexity, behind GUI-based tooling. Strong points in your attitude towards OpenEHR is that you recognized the complexity of the RM, and second, that you are making easier the way to work with it. But there can be also more fundamentally ways to handle the complexity and make the learning curve less Hi Leo, You advertises a simplification to make the AOM better to work with. This is also an approach, but, simplification means, lost of functionality. And technical arguments like indexing should not weight in innovation. Because when you consider current technical arguments in defining something new, you are not innovating, but you are consolidating. Henry Ford said: If I asked the people what they want, they would say: A faster horse. So think beyond the current boundaries. Do not think of AOM making simpler to remove a learning curve, or solve technical problems, because that is conforming to the present, which is already the past one second later. 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 in, the short path notation (which makes it in fact more complicated). Bert
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.
Hi Bert,
Map and List are ok as container built-ins, although I don’t think anyone has any problem with the Set type either. Interval is a type you don’t want to throw out in health, it’s so heavily used, not having it just makes life unnecessarily hard. In ADL, Interval looks like |0.0..<1000.0|; in ODIN (the openEHR JSON equivalent) it’s the same; in JSON, it is: “list”: [ { “lower”: 0.0, “upper”: 1000.0, “upper_included”: false } ] And in XML: 0.0 1000.0 <upper_included>False</upper_included> This is not to say don’t use JSON or XML, just that having a native syntax, and a native AOM type that goes with it vastly simplifies things. Note that all cardinality and optionality constraints are intervals! Personally I am a fan of nested maps. In ODIN, the main term_definition structure looks like: term_definitions = < [“en”] = < [“at0000”] = < text = <“Blood Pressure”> description = <“The local measurement of arterial blood pressure which is a surrogate for arterial. pressure in the systemic circulation. Most commonly, use of the term ‘blood pressure’ refers to measurement of brachial artery pressure in the upper arm.”> > [“at0001”] = < text = <“history”> description = <“history Structural node”> > which is, as you can see, a nested map. And in an archetype serialised from AOM objects to ODIN and JSON you get: definition = < rm_type_name = <“OBSERVATION”> node_id = <“at0000”> attributes = < [“1”] = < rm_attribute_name = <“data”> children = < [“1”] = (P_C_COMPLEX_OBJECT) < rm_type_name = <“HISTORY”> node_id = <“at0001”> and “definition”: { “rm_type_name”: “OBSERVATION”, “node_id”: “at0000”, “attributes”: [ { “rm_attribute_name”: “data”, “children”: [ { “rm_type_name”: “HISTORY”, “node_id”: “at0001”, i.e. nested maps. The native types of these are something like Hash <Hash <ValueType, KeyType>, OtherKeyType>. Unfortunately, nearly everyone who hits this in the AOM specification (e.g. in the ONTOLOGY classes) complains about it, and in fact, there were more Hashes and nested Hashes in the RM previously that we changed to other types because of complaints. I have never understood the complaints really, and maybe it’s ok now, because we did the initial modelling before Java had proper generic types, and way before JSON ever existed. Note that we used Cluster / Element mainly to have a base data structure in common with EN13606 (as it was at the time). Whether it is a good idea to throw that out is an interesting question. I think the date/time types need to work as logical primitives, so does a basic ‘coded term’ type. Although they are often modelled as subtypes of String, I don’t really agree with this, because that’s subtyping on the basis of representation not interface. But I suppose if one considered their true nature as syntactical objects, then that’s acceptable. I don’t care about it that much, and it’s possible that String substitutability would sometimes help. well it can already, and often is, but of course the proper types like Interval and some others are serialised out into dumb JSON structures. I have been thinking for some years about {1,10} 
what you have below is something like the translation that already exists from Operational Template (fully resolved and substituted templated archetype) to ‘Template Data Schema’, which is an XML schema whose tag set matches exactly what you have in the square brackets below. I have to admit, I had never though of doing that transform in ADL syntax and post-processing that (mainly because some people continually complain about ADL and only want XML, so we tried to make them happy). I would not be looking to replace existing archetypes, but to the below from existing archetypes - it’s just a different TDS transform. Just to show this, consider this ADL Workbench serialised archetype (pregnancy summary from CKM) - note how the comments are serialised on the right: EVALUATION[at0000] matches { – Pregnancy summary data matches { ITEM_TREE[at0001] matches { – Tree items cardinality matches {1..; unordered} matches { ELEMENT[at0002] matches { – Maternity states value matches { DV_CODED_TEXT matches { defining_code matches { [local:: at0003, – Active - viable at0004, – Active - non-viable at0005, – Breast feeding at0006] – Completed } } } } CLUSTER[at0007] occurrences matches {0..1} matches { – Conception items matches { ELEMENT[at0008] occurrences matches {0..1} matches { – Date of LMP value matches { DV_DATE matches {} } } Now imagine it is serialised as follows: EVALUATION matches { data matches { ITEM_TREE matches { items cardinality matches {1..; unordered} matches { ELEMENT[] matches { value matches { DV_CODED_TEXT matches { defining_code matches { [local:: at0003, – Active - viable at0004, – Active - non-viable at0005, – Breast feeding at0006] – Completed } } } } CLUSTER[] occurrences matches {0..1} matches { items matches { ELEMENT[] occurrences matches {0..1} matches { value matches { DV_DATE matches {} } } Then, remove the attribute lines (what to do with cardinality and existence constraints?) EVALUATION matches { ITEM_TREE matches { ELEMENT matches { DV_CODED_TEXT matches { [local:: at0003, – Active - viable at0004, – Active - non-viable at0005, – Breast feeding at0006] – Completed } } CLUSTER occurrences matches {0..1} matches { ELEMENT occurrences matches {0..1} matches { DV_DATE matches {*} } It’s not hard to imagine further steps to get what you have done. Now, the above isn’t legal ADL, but it’s not hard to imagine it as a new hybrid syntax, a sort of ADL-schema or so. However, today it isn’t, and there aren’t any tools for the above (unless you have built one). you might want to have a look at the TDS transform in the - it does exactly this kind of thing. Here’s an example XSD from generated from one of its sample templates, as seen in Oxygen: you can see the highlighted tags are from the archetypes in the template (you can even see one with what is probably a bug in the converter, where the ‘(’ character has been converted to the text ‘openBrkt’. The non-highlighted tags retain their reference model values, since an archetype doesn’t archetype everything, but a content XSD like the above has to include a full definition of all the data, not just the archetyped bits. I’m not saying that this particular transform is the best possible, or even that good, but I think it is qualitatively the same transform as you are talking about; I think you are doing the same thing by a different route. so the real question is whether we want to lose semantic power in the source models - the RM and the archetypes, in order to have an easier transform path to the end target, which is some ‘easy to use’ XSD or other ‘friendly’ artefact. Some of the RM simplifications should be done, and I expect in the next few months, they will appear in a new openEHR release. I don’t think that we should throw out useful constructs that prevent modellers expressing what they need to express, just to achieve a particular mapping to a ‘dumb target’. On the other hand, I think we should try not to make the transformation path too difficult either. There are some other things we are doing to simplify AOM/ADL, which I have been working on with Harold Solbrig at Mayo, who has provided some in-depth review and suggestions on AOM. I’ll post about this in the next few days. So my feeling is that with simplifications, and more work on the downstream transformers (which after all, you only need one of, for each transform target), we can have rich models and ‘friendly’ final outputs as well. I don’t think it’s a very interesting option, given that most things that are in the RM and the AOM / ADL were put there to make clinical modelling as it is today possible! But some things can be removed, and improvements remain to be made… the current type of archetypes are all trees, and you are right, at the gross structure level, they are not complicated. But there is a whole ‘second order’ level of models on the horizon for describing shared care plans, and other structures, which are more complex… But the real richness is in two places: see the above TDS transform. Note that it is performed on the OPT transform which comes from the flattened template. You can see how this is done in the ADL 1.5 workbench - there are ADL, ODIN, JSON, XML and YAML ‘OPT’ outputs. One of these would be a basis for the TDS generator. You might think that this transform can be greatly improved, and I think many of us would agree; in fact there should probably be a number of alternative transforms available for generating different flavours of schema. Other related transforms generate source code APIs and WSDLs, as well as form definitions. many people have had similar thoughts I guess. We can throw out all the power, but then we can’t express anything much. It seems kind of pointless. Most computing and software done today based on ‘simple this and easy that’ produce just what you’d expect - simplistic results that never scale, can’t deal with edge cases, and are basically not useful in a serious way. Personally, I think we need to get the level of complexity in the source side (ie. RM, AOM, archeytpes) a bit cleaner, and then we need to do a lot better on downstream transformations from the OPT. ANd then publish that. If we get that right, it completely replaces all manually built message schemas, ‘document’ models and other XML structures. Others may think differently, and I guess the community as a whole will decide. Personally I want to make sure the next few months are used to clean up the annoying parts of the RM and AOM, and I am sure you would have a lot to contribute to that. It would be very helpful if you were to play with the and consider whether the XML and JSON it is outputting now is right for the next stage transforms in the way you are thinking of them. - thomas
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
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
Hi Bert,