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 On Wed, Feb 21, 2018 at 12:13 PM, A Verhees <[email protected]> wrote: > 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 > > Op 21 feb. 2018 3:21 p.m. schreef "Thomas Beale" <[email protected] > >: > > >> >> On 21/02/2018 13:00, Bert Verhees wrote: >> >>> On 20-02-18 20:09, Thomas Beale wrote: >>> >>>> >>>>> 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/program >>> s/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/release >>> s/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 >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_ >> lists.openehr.org > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > -- Ing. Pablo Pazos Gutiérrez [email protected] +598 99 043 145 skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
