that should not be the case - that’s exactly what we are avoiding. If we missed something it is an error. But note - most of the RM ‘Support IM’ model moved to BASE. We think it will get used for Task Plans, and maybe GDL guides. Yes, there is a new class TERMINOLOGY_CODE that is used in BASE instead of CODE_PHRASE; eventually, the RM should just use that. If you found any use of CODE_PHRASE in BASE, please let us know. Not much admittedly, since OBJECT_ID is just an identifier with a concrete String representation, but it does mean that an OBJECT_REF can point to any kind of OBJECT_ID, including an ARCHETYPE_ID. yes, as I say, there should be absolutely none of these. Any you see need to be reported. We are not intending to make the RM any larger, not sure why you think we are. - thomas
I must have missed new developments, I am still working with RM 1.0.3 which, I was thinking, is the production version
My remarks were for that version, and for my idea, there were some inconveniences in it.
But I will study the new RM, and if I find some similar inconveniences, I report them.
This is a bit another subject, but I explain it anyway, because last weekend, I was not satisfied about my emails
Please let me explain why it is an important problem to me.
Maven (Java dependency tool) gets grumpy about circular library references, and the Golang compiler does accept circular package references and restricts using circular struct references.
C++ does not accept circular class references, but can be worked around in a tricky way.
Circular references
The Dependency Rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. That includes, functions, classes. variables, or any other named software entity. As you move inwards the level of abstraction increases. The outermost circle is low level concrete detail. As you move inwards the software grows more abstract, and encapsulates higher level policies.
Robert C Martin.
Terminologyservice needs codephrase, and codeprase is part of the datatypes, dvtext (also datatype) needs terminologyservice (in constructor). (circular reference)
Other datatypes, for example, dvtext also need a ready compiled terminologyservice and codephrase for checking the charset and language in the constructor
This situation makes it impossible to separate the terminologyservice from the datatypes, although they have no similar abstraction level
In OpenEhr this is solved by using an interface of terminologyService inside the support-part, and that would be a good solution if the interface did not have the codephrase also in its declarations.
So it did not solve it the violation of the dependency rule, but it makes it compilable.
So it is a problem, and causes dirty code to solve. The solution is simple. Make CodePhrase a part of TerminologyService and remove it from datatypes. Then all classes which need code-phrase have to link in terminologyservice, but terminology can be compiled independently from other classes
The most inner circle of the dependencies should be a group libraries/classes which do not need each other by the route of an outer circle. The most inner group should be AOM, TerminologyService, EHR-RM, around that should be the Support, and around that should be the datatypes. Then there would be no problem, the datatypes can be linked against every library and will never cause a circular reference.
Best regards
Bert
My problem description was good, the solution, is not really good. In fact the metaphore of circles does not work completely in openehr. I believe it is the other way around.
All higher level classes may use the datatypes, but datatypes may not use the higher level classes. So datatypes must be the most inner circle so that all classes around can use datatypes. This also has an inconvenience because of dvtext which has that dependency to higher level terminology.
So what do we do with on terminology depending datatypes? Make them part of the terminology related software of which terminology service also will become a part?
Or do we remove codephrase from terminology service so that terminology service can be an inner circle of datatypes? So codephrase will then be in the datatypes, and terminologyid should not be inherited from object_id which else causes a conflict with support, so terminologyId would be a part of terminology service.
Or support should be the inner most circle, then terminology and then datatypes?
Bert
So splitting up the RM instead of making it larger would be my idea. The first is not easy to do, but the second is, and helps us avoiding further problems and avoiding creating unnecessary large libraries.
We are not intending to make the RM any larger, not sure why you think we are.
In your first message about this proposal was something that made me think you were about to enlarge the RM and also to have all in a large pile of classes.
I quote: “Doing the above requires adding some new classes to the RM, or a Presentation Model part of openEHR.”
I think you changed your mind now, so that is not important.
Bert
I wrote this afternoon, and I see that it is not sufficient. It could work for archetypes, because the have clear and simple identifiers which could be used to connect the generated component-values and parameter-naming inside the generated rest-calls inside the javascripts, but it would not work in representing query results.
So I came to another idea
One could also create path-values in JSON, in that way there would be only very simple rest calls necessary with only a few, or maybe one parameter in the rest-calls, the JSON-structure and maybe one or two more which I have not thought of yet.
In this way, every archetype datavalue-set can be represented, and also every query result.
And the rest as described below remains in that case about the same.
But I am sure there are very good ideas of others, so I wait sometime to get a point of what is generally agreed about.
Best regards
Bert
I didn’t change my mind, I was just not precise when I said that 
- t
Jussara,
Here is a copy of the paper we presented on INFOLAC 2014
The presentation
http://www.sueiidiss.org/images/archivos2015/temasinfolac/22.pdf
That paper is referenced from my MEDINFO 2015 paper
All are also here
http://independent.academia.edu/pablopazos
Since then, I have updated the UITemplate model to use OPTs instead of archetypes directly, added improvements and features that are not in the initial model from the paper. The new model still needs work, but we proven we can use it as an abstract, generic, declarative openEHR UI definition focused on data entry and form-oriented visualization. And that technology specific UI generators can use it to output other declarative form UI specifications, that dev tools / IDEs can take in order to render UIs. E.g. from an UITemplate instance in XML, different generators can generate XAML (.NET UI definitions), SwiXML (Java Swing UI definitions), XHTML/HTML5 (for web), and there are XML UI definitions also for Android and iOS that can be generated. Basically generators are XML mappers, and knowing the destination schema is really easy to create the maping rules between input UITemplates and X technology UI definition.
A second level, of definition is also missing, about the rules for data input, like “if field X has a value, show field Y”. I don’t think we need to specify mandatory or cardinality constraints on the UITemplate since the OPT already has those and the UITemplate should just define UI stuff that is not on the referenced OPT.
I hope to have an updated & translated spec for next week.
Best,
Pablo.
This is of course a good thing.
But now the question, how do I know which definition to use.
I always looked at this URL: http://www.openehr.org/programs/specification/workingbaseline
There I found "Support", which brings me to:
http://www.openehr.org/releases/RM/latest/docs/support/support.html
In that, there is CODE_PHRASE still used in TERMINOLOGY_ACCESS.
Now I read that there is a new class in BASE, I found the link: http://www.openehr.org/releases/BASE/latest/docs/index
And I found Terminology_Code: http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_code_class
Which is a real improvement, exactly what I was hoping for, it did not only remove the CODE_PHRASE from datatypes, but also TERMINOLOGY_ID class from SUPPORT
It has a property/field which is named terminology_id and is of type string
Is this what is going to be the new standard?
And when will this be like that?
When looking further, I also see that there is still a TERMINOLOGY_ID class in that document which is the old support terminology which is derived from OBJECT_ID
http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_id_class
Is this confusing, or am I missing something stupid? Am I the only person asking this kind of questions? If yes, where do others get their information from?
Please help me, because, I think, this is very important.
Thanks
Bert
The terminology service also has dependencies to rm data types, only because of codephrase. Wouldn't it be possible to avoid that?
Yes, there is a new class TERMINOLOGY_CODE that is used in BASE instead of CODE_PHRASE; eventually, the RM should just use that. If you found any use of CODE_PHRASE in BASE, please let us know.
This is of course a good thing.
But now the question, how do I know which definition to use.
I always looked at this URL: http://www.openehr.org/programs/specification/workingbaseline
There I found "Support", which brings me to:
http://www.openehr.org/releases/RM/latest/docs/support/support.html
In that, there is CODE_PHRASE still used in TERMINOLOGY_ACCESS.
yes - we are still working on this - to find the cleanest way to separate it out without breaking current code.
Now I read that there is a new class in BASE, I found the link: http://www.openehr.org/releases/BASE/latest/docs/index
And I found Terminology_Code: http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_code_class
Which is a real improvement, exactly what I was hoping for, it did not only remove the CODE_PHRASE from datatypes, but also TERMINOLOGY_ID class from SUPPORT
It has a property/field which is named terminology_id and is of type string
Is this what is going to be the new standard?
And when will this be like that?
Well it will be the new standard for BASE classes very soon. Over time, we will start either replacing CODE_PHRASE in the upper models with TERMINOLOGY_CODE, or possibly adding some sort of mapping / conversion logic. But we'll only do that based on input from implementers - we need to find a way to update the models without breaking existing systems.
When looking further, I also see that there is still a TERMINOLOGY_ID class in that document which is the old support terminology which is derived from OBJECT_ID
http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_id_class
Is this confusing, or am I missing something stupid? Am I the only person asking this kind of questions? If yes, where do others get their information from?
Please help me, because, I think, this is very important.
you should consider the classes you see in BASE today as being what will be issued, unless anyone finds a problem with them. In the near future, we will continue the cleanup around terminology. One reason we have not cleaned it up yet is because noone in industry agrees on what standard or tools to use. Noone faithfully implements CTS2 for example, except a non-maintained server from Mayo (LexGrid from memory). IHTSDO did something different, and FHIR did something else. All have good and bad points, but there has been no clear specification.
I am inclined to think that the specification of the future is a kind of stripped down CTS2 that gets rid of XML/XSD, and can be used with multiple serialisation formats, and cleaner models, but semantically, more or less the same. But we have to be practical too. Maybe the FHIR terminology service will evolve in the most appropriate way; they already have the same URI representation of terms as our BASE classes now have.
All input on this welcome, as usual.
- thomas
Well, this sounds very good, so I can forget my babble about dependency circles, concerning this part of the specs
I hope this will be in stable release very soon, because I need to have a stable definition for a project
Thanks
Bert
Hi all,
I manage to translate / update part of the work we did some years ago in terms of UI definition and generation for the openEHR stack.
Here is the doc, feedback is very welcome!
https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing
Pablo,
Good work - I’ve included a reference to this doc in the original wiki page, and added a few ideas about how to use it. It is very close to what I was thinking of.
- thomas
Thanks Thomas, I added a paragraph about the UI generation modes at the end, I forgot to mention that yesterday.
Hi!
I have also updated the https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets wikipage to include
- references to some previous GUI discussions and
- Region Östergötlands current use case and initial Ethercis-OPT-introspector+Angular-based design plans (See heading “OPT form renderer needed for pilot testing of surgery process supporting system” near the end of the page.
Hi contributors on this,
I am sorry not contributing so much, it is not my piece of cake to work on defining standards, I like better using them.
So I like to express that I am very grateful for the work which is being done in this context and the way it is being done.
I think that it will be a big step forwards for OpenEhr.
Best regards
Bert Verhees