RE: Archetype modelling pattern for Physical examination findings

Very important, I see as major advantage that gives predictability for archetypepaths which is necessary for wild carding AQL queries on unknown archetypes or groups of archetypes on different observations. In the field of observations this is part of a major step forwards. Researchers and

Re: serialization syntax of openEHR instance data

On 22-02-19 12:27, Georg Fette wrote: Hello, Thank you all. The .xsds are already very useful. And the Toolkit also looks beneficial for what I want to do. The toolkit is great, very impressive work. Also, I found the API-exporer from Marand in which you can test and look at API's

Re: serialization syntax of openEHR instance data

to experiment with the API and thus also see the JSON datasets. Best regard Bert Sent from my Xperia™ by Sony smartphone Bert Verhees wrote >The question asked by George Fette is that he wants to see an example of an >OpenEhr dataset in XML or JSON containing demogr

Re: serialization syntax of openEHR instance data

The question asked by George Fette is that he wants to see an example of an OpenEhr dataset in XML or JSON containing demographics and commonly used archetypes. Best regards Bert Sent from my Xperia™ by Sony smartphone Pablo Pazos wrote >Adding to Thomas comments, > >1. Yes, XML

Re: FW: Re: JSON for definitions-notation

was overseeing it all. Now I am, and I understand that there are no technical objections, so that makes me glad. have a nice day Bert On 16-02-19 15:10, Thomas Beale wrote: On 16/02/2019 14:00, Bert Verhees wrote: On 16-02-19 13:20, Thomas Beale wrote: Have a look at the Archie project <ht

Re: FW: Re: JSON for definitions-notation

On 16-02-19 13:20, Thomas Beale wrote: On 16/02/2019 01:38, Bert Verhees wrote: A few last words on this. It is easy for JSON based archetype repository to cooperate with an ADL based repository. Serializing of an AOM structure to ADL is very easy to do, this counts for the DADL and CADL

Re: FW: Re: JSON for definitions-notation

On 16-02-19 13:16, Thomas Beale wrote: Bert, if you serialise a AOM archetype to any object dump format, you need typing information for the simple reason that there is polymorphism in the model, mainly places where the static type is C_OBJECT, C_DEFINED_OBJECT or C_PRIMITIVE_OBJECT but the

Re: FW: Re: JSON for definitions-notation

how damn limiting pure json* is. Any attempt >to introduce long-ints or annotation take you to vertical-specific json+. > > >* json is javascript, so has type and other limitations. > >On Fri, Feb 15, 2019, 7:39 PM Bert Verhees >> A few last words on this. >> >&

Re: JSON for definitions-notation

> The folks doing CIMI use at least the JSON mode. It also generates XML, via > custom serialiser. > One of the jobs I never completed is a deserialiser for the 3 regular > formats, but it is nearly trivial. Exactly my point, I completely agree with this. Bert > > Venkat Subramaniam, who

RE: FW: Re: JSON for definitions-notation

your opinions. Best regards Bert Sent from my Xperia™ by Sony smartphone Bert Verhees wrote > > >Sent from my Xperia™ by Sony smartphone > > Original Message >Subject: Re: JSON for definitions-notation >Sent: 15 Feb 2019 22:46 >From: Bert Verhe

FW: Re: JSON for definitions-notation

Sent from my Xperia™ by Sony smartphone Original Message Subject: Re: JSON for definitions-notation Sent: 15 Feb 2019 22:46 From: Bert Verhees To: Pieter Bos Cc: Not many people find archetypes readable. I can read them and I have done that many times, but most modelers I know

Fwd: JSON for definitions-notation

egular formats, but it is nearly trivial. I am not sure if Archie or Marand's ADL-designer tools do the same but I think it should be trivial for them to implement as well. I will look into this again... - thomas On 15/02/2019 18:51, Bert Verhees wrote: I always admired OpenEhr for its ability to

JSON for definitions-notation

-guru, said: "Don't walk away from complexity, RUN!!!" But Einstein said: "Everything Should Be Made as Simple as Possible, But Not Simpler" So the question is: Are there any technical objections to express archetypes and reference-models in JSON? Best r

Re: Error in website

Thanks :-) Sent from my Xperia™ by Sony smartphone Thomas Beale wrote >Ths XSD and JSON repo folders did not have index files - we have added >some simple ones to display everything. We'll improve these over time. > >- thomas > >On 04/01/2019 14:20, Bert Verhees wr

Error in website

Don't know where to tell this, but there is something not okay on: https://specifications.openehr.org/releases/ITS/latest/index Many links don't work Bert ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: openEHR on FHIR and vice versa

will create space to create these mappings. I wonder, would templates be a good way to arrange this? I am very interested in opinions about this Best regards Bert Verhees Op ma 17 dec. 2018 19:27 schreef Pablo Pazos I also did some mapping work FHIR -> openEHR using Mirth, but this is >

Re: Use of LinkEHR to create OPTs like we do with Template designer

On 13-12-18 16:13, Thomas Beale wrote: They are already working on a local install version for that. Good to hear, I think, that should be announced better, and with roadmap. Bert ___ openEHR-technical mailing list

Re: Use of LinkEHR to create OPTs like we do with Template designer

that commercial companies do not want to do this. Their data-structures are often regarded as their crown-jewels. Best regard Bert Verhees ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr

Re: Reference Model as Archetypes ?

On 12-12-18 15:44, Diego Boscá wrote: When I say official I refer to AOM. If AOM/ADL let's you say something we try to support it. We always 'eat' what others tools produce, and have implemented export mechanisms to be compatible with the things other tools can handle. In this particular case

Re: Reference Model as Archetypes ?

On 12-12-18 14:49, Diego Boscá wrote: These are modifications on the parser, which parses more things than your standard parser. In fact, the editor supports legal things in ADL that other parsers don't (e.g. explicit node identifiers or existence). The generated ADL is completely fine ADL.

Re: Reference Model as Archetypes ?

On 12-12-18 13:48, Diego Boscá wrote: The official one, these are 'hacks' that allow you to handle requirements and edge cases only present in these RM archetypes Diego, I don't want to be harsh about LinkEhr, which is a very strong product. But this situation raises questions. I already had

Re: Reference Model as Archetypes ?

On 12-12-18 12:53, Diego Boscá wrote: We used that one as a basis and generalized mostly to allow the special RM 'at' codes we created. I can send you the modified grammar or the parser if you want. Wouldn't that disturb interoperability processes? One could wonder: Which one is the right

Re: Parsing of Archetypes/Templates

On 12-11-18 18:40, Bert Verhees wrote: >> Another very important restriction for using XML Schema, in my opinion, >> is that you cannot have two or more elements with the same name but a >> different data type. This data type must be in detail the same. XML Schema >

Re: Parsing of Archetypes/Templates

On 12-11-18 17:59, Thomas Beale wrote: On 12/11/2018 16:04, Bert Verhees wrote: On 12-11-18 16:13, Thomas Beale wrote: you can, it's called a Template Data Schema (TDS), and is generated from the Template Designer and I think the new Marand ADL-designer. Its intended exactly for checking

Re: Parsing of Archetypes/Templates

On 12-11-18 16:13, Thomas Beale wrote: On 12/11/2018 09:44, Bert Verhees wrote: Sorry, I first replied to Pieter Bos only, now to the list. Pieter already replied to me that the question was not about XSD to check datasets was . So, read my reply, for those interested in easy validating

Re: Parsing of Archetypes/Templates

-- *Bert Verhees* Software developer, architect Profile: https://www.bertverhees.nl/ Twitter: https://twitter.com/VerheesBert LinkedIn: https://www.linkedin.com/in/bertverhees/ Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl> Mobile: +31 06 28

Re: e-health services landscape - initial proposal, open forum

ervice, just as for any other > kind of data - it's just different archetypes. It may be that special > services for e.g. performance tracking or whatever are needed, but for now > I'm assuming all that stuff is done by applications, not services. > > - thomas > > On 23/

Re: e-health services landscape - initial proposal, open forum

nd, though. I think getting > these archetypes into good shape would be useful to many app developers. > > > > Would that be helpful to you? > > > > Cheers > > > > Heather > > > > *From:* openEHR-technical *On > Behalf Of *Bert Verhees > *Sent:* Thu

Re: e-health services landscape - initial proposal, open forum

r covering all potential concepts, but there are a considerable number > that are applicable for use by consumers and are not a bad starting point. > > > > Kind regards > > > > Heather > > > > *From:* openEHR-technical *On > Behalf Of *Bert Verhees >

Re: e-health services landscape - initial proposal, open forum

ailman/listinfo/openehr-technical_lists.openehr.org -- *Bert Verhees* Software developer, architect Profile: https://www.bertverhees.nl/ Twitter: https://twitter.com/VerheesBert LinkedIn: https://www.linkedin.com/in/bertverhees/ Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl> Mo

Re: e-health services landscape - initial proposal, open forum

penEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Bert Verhees* Software developer, architect Profile: https://www.bertverhees.nl/ Twitter: https://twitter.com/VerheesBert LinkedIn: https://www.linkedin.com/in/bertverhees/ Email: ber

Re: GDPR and OpenEhr.

ailman/listinfo/openehr-technical_lists.openehr.org -- *Bert Verhees* Software developer, architect Twitter: https://twitter.com/VerheesBert LinkedIn: https://www.linkedin.com/in/bertverhees/ Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl> Mo

Re: GDPR and OpenEhr.

513 622,* Fax: +351 *225 513 623* Rua Dr. Plácido da Costa, s/n | 4200-450 Porto | *Portugal* On Mon, Sep 3, 2018 at 2:26 PM Bert Verhees <mailto:bert.verh...@rosa.nl>> wrote: In all other contexts the patient can never be forgotten or deleted. Any legal transaction is

Re: GDPR and OpenEhr.

In all other contexts the patient can never be forgotten or deleted. Any > legal transaction is subject to archiving laws. For tax purposes the time > period is 5 years in the Netherlands, I think. Only after these periods as > defined by law the transactions can/must be deleted. > It is true

Re: GDPR and OpenEhr.

: > On Mon, Sep 03, 2018 at 01:08:41PM +0200, Bert Verhees wrote: > > > So, on medico-legal purposes as Ian and Karsten and maybe others referred > > to, a patient, if he maintains his own PHR, and he likes to delete it, he > > can never sue a clinician, because, he, hims

Re: GDPR and OpenEhr.

It would be a bad thing to let all patients be restricted in their rights because one patient, suffering in the past from depression and having a recurring cancer can get into problems. Some people are emotionally unstable, they need protection. I don't know the best way, but I would think of

Re: GDPR and OpenEhr.

4994> > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > &g

Holistic view, was :AQL on specific list of compositions

Contsys will update some definitions. They are now the base of their thinking, but I am sure that will change soon. Thanks, Gérard, for giving me the opportunity to make my point again. :-) We don't call war a peace problem. So why do we call illness a health problem? Normally I would not

Re: GDPR and OpenEhr.

There are good arguments in the discussion. I take this message to reply to because it is the last for this subject at the moment. I am thinking of following situation. This week, Microsoft, Google, Amazon and IBM agreed that there must be a health data platform which exposes itself in FHIR

GDPR and OpenEhr.

OpenEhr does not really allow to delete data, only logical deletion (mark as deleted), but GDPR demands the right of the patient to be forgotten. Is there some change expected in the specs for compliance to GDPR, or was this already implemented? We had this discussion, slightly different,

Re: AQL on specific list of compositions

___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Bert Verhees* Software developer, architect Twitter: https://twitter.com/VerheesBert LinkedIn: https://www.linkedin.com

Re: AQL on specific list of compositions

As far as I understand, and I also implemented it like that, there should never be functionality to delete data. Accidental deletion can only occur when you pass the software and hack on the database directly. That should never occur and if it does, the database should be restored to a safe

Re: AQL on specific list of compositions

I cannot imagine how a folder structure can get lost except by data corruption. In that case anything is lost anyway and a rollback from a backup is needed. In fact there should not be a folderstructure in the database. There are folder objects which contain a list of references (data) to

Re: Empty COMPOSITION.content is valid?

On 26-07-18 09:57, Thomas Beale wrote: Does it make sense to have an empty COMPOSITION.content? Imagine a visit to a GP, and nothing clinical comes out of it. Nothing worth mentioning, but still having had a composition and a consult to pay for.

Re: UCUM/SNOMED/custom units

On 23-07-18 13:45, Diego Boscá wrote: Units need to be (and will be) revamped, we also need other things already discussed in other posts like rubric, long descriptions (which could be language dependent), etc. This could be very useful for better describing custom UCUM units too. Several

UCUM/SNOMED/custom units

://wiki.hl7.org/index.php?title=Representation_of_Units Best regards Bert Verhees ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Meaningful API's

On 17-07-18 12:15, Thomas Beale wrote: One general thing to remember is that there will normally be multiple levels of API, from data to domain to business to application. Agree, good to list the levels. Bert ___ openEHR-technical mailing list

Re: Meaningful API's

On 17-07-18 12:05, Ian McNicoll wrote: This is harder for newbies to understand but We don't write API's as learning material for newbies, but for professional communication, so that is no problem. Also for the rest I agree. There is need for API's for interaction between two OpenEhr

Re: Meaningful API's

On 16-07-18 16:59, Thomas Beale wrote: well whether it is 'so good' is in the eye of the beholder, but it is 'good enough' for quite a lot of things, things for which we would once have expected to be able to use XMI. Anyway, the BMM introduction

Re: Meaningful API's

her side is an OpenEhr machine. Between two OpenEhr systems, OpenEhr is the center of the universe. Best regard Bert Verhees Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com <mailto:i...@freshehr.com> twitter: @i

Re: Meaningful API's

On 16-07-18 16:54, Ian McNicoll wrote: Hi Bert, Have a look at what Ripple is doing in terms of 'meaningful APIs'. See http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2018-February/014799.html I check it, thanks for the info Bert

Re: Meaningful API's

On 16-07-18 16:59, Thomas Beale wrote: well whether it is 'so good' is in the eye of the beholder, but it is 'good enough' for quite a lot of things, things for which we would once have expected to be able to use XMI. Anyway, the BMM introduction

Re: Meaningful API's

On 16-07-18 15:56, Bert Verhees wrote: But again, the starting point must be the API's defined, maybe in a transformerable language like swagger, which seems to connect well to the OpenAPI initiative.(I never liked swagger much, but my last experience with it was from years ago, maybe

Re: Meaningful API's

On 16-07-18 14:55, Thomas Beale wrote: On 16/07/2018 13:35, Bert Verhees wrote: On 16-07-18 13:49, Thomas Beale wrote: It seems to be a competitor to FHIR in some way, since it is not using FHIR. Aren't we all? ;-) But serious, I don't think so, they don't use FHIR because their target

Re: Machine Learning , some thoughts

On 30-06-18 10:46, Thomas Beale wrote: I would have thought the easiest way would be to machine convert the RM BMM and the Abstract Platform UML model

Re: Machine Learning , some thoughts

definitions. So archetypes will then be compiled for the sake of network traffic. This compiled code could have standard API calls to ask which archetype it represents. I don't know how the feelings are about this. Bert - thomas On 28/06/2018 16:25, Bert Verhees wrote: On 28-06-18 17:19, Bert Verhees

Re: Machine Learning , some thoughts

On 28-06-18 17:19, Bert Verhees wrote: Never use REST/JSON/HTTP1.1 for stable models, it is throwing away a lot of performance. How about creating a protocol-buffer generation tool for archetypes, or as a matter of fact, for the reference model would be sufficient. Good idea, to remember

Re: SMART on FHIR integration

sorry for the sloppy text, a bit in a hurry ;-) On 24-04-18 10:34, Bert Verhees wrote: Maybe it is interesting to facilitate a SMART API for OpenEhr (now there is an API-definition effort in process for OpenEhr)? Or is that to market specific and is it something more suitable for vendors

Re: SMART on FHIR integration

Maybe it is interesting to facilitate a SMART API for OpenEhr (now there is an API-definition effort in process for OpenEhr)? Or is that to market specific and is it something more suitable for vendors or other third parties to develop? That reminds me of an other discussion which runs for

Re: [Troll] Terminology bindings ... again

...@luna.nl <mailto:gf...@luna.nl> Kattensingel  20 2801 CA Gouda the Netherlands On 31 Mar 2018, at 11:04, Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote: Maybe we should relate this thinking to CEN13606 because that Reference Model allows mor

Re: [Troll] Terminology bindings ... again

Maybe we should relate this thinking to CEN13606 because that Reference Model allows more generic thinking. (Thinking this because GF was the convenor of this CEN standard) But even then some more explanation would be welcome. Bert On 31-03-18 10:37, GF wrote: Dear Thomas, There are two

Re: openEHR Toolkit

On 29-03-18 13:59, Pablo Pazos wrote: this is a simple app, Java only. Still very nice and useful and inspiring ;-) It is just, I am working on micro-services, also for OpenEhr, which makes it easy to have a cloud of modularity which can also interact. But of course, it is work to create a

Re: [Troll] Terminology bindings ... again

it more manageable. See for > example NHS in England > https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40 . > > > >  Regards > >      Mikael > > > > > > *Fr?n:* openEHR-technical [

Re: SV: [Troll] Terminology bindings ... again

Diego, this is a wise thought!!! It seems logical, but that is often in good ideas, they seem like: why did no one ever think about this. No clinician handles the complete medical science/SNOMED repository in his profession. Some even use a very small sub-part, think about a dentist, a

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

of an event somewhere in 2015, or a duration of one month, or Gerard   Freriks +31 620347088 gf...@luna.nl <mailto:gf...@luna.nl> Kattensingel  20 2801 CA Gouda the Netherlands On 21 Mar 2018, at 15:02, Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote: I

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

libraries make a different split between the concepts than what you call 'calendar' and 'duration'. Also every library and standard has its own term for those concepts. Regards, Pieter Bos On 21/03/2018, 14:42, "openEHR-technical on behalf of Bert Verhees" <openehr-t

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

On 21-03-18 15:02, Bert Verhees wrote: I don't mind how you call it, programmers call it Duration and Calendar, both are well known datatypes, but they have other semantics. Sorry for my unpleasant tone, I guess we are talking about the same things. Bert

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

r 2018, at 12:25, Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote: On 21-03-18 10:50, GF wrote: Does including Duration in the RM fit with the scope for the RM? Why do we have archetypes? Why not include every thing in the RM? Do we want the HL7v3 Reference Model

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

On 21-03-18 13:57, Thomas Beale wrote: although 'month' is not a scientific notion (it's not constant), we do treat it as a data type or unit in /social date time types/, which is what we are mostly dealing with, and what the types DvDuration, DvDate etc correspond to. For scientific

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

On 21-03-18 13:51, Thomas Beale wrote: On 20/03/2018 23:33, A Verhees wrote: One last remark. There is in medical context need of a datatypes to express: "do this one time a month, for example on a specific date". But technically seen, this is not a duration, the maybe a need for another

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

using it right away. Regards, Pieter Bos Nedap Healthcare On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees" <openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> wrote: On 21-03-18 10:50, GF wrote: > Does including

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

On 19-03-18 16:16, Thomas Beale wrote: On 19/03/2018 08:57, GF wrote: Again my thoughts Duration is not a Data Type in many computer languages. So we need to model it in an Archetype (Chairos) that's true, but in databases and XML it is, and it is mostly treated like a primitive data type

Re: [Troll] Terminology bindings ... again

On 13-03-18 17:45, Philippe Ameline wrote: in my own terms, it means that it is not the proper component for modern applications. Wasn't it Voltaire who said that the best is the enemy of the good? ___ openEHR-technical mailing list

Re: Templates for application form development

that it will be a big step forwards for OpenEhr. Best regards Bert Verhees On 13-03-18 00:04, Erik Sundvall wrote: 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

Re: Setting thresholds

On 01-03-18 12:12, Diego Boscá wrote: Assuming there is a service that provides the given value for a given identified range (based on the parameters you provide like sex, age, race... ) it would be allowing kind of namespaces that have defined operations. This would also allow easy querying

Re: Setting thresholds

On 01-03-18 12:01, Diego Boscá wrote: I believe that we need a way in standard AQL to call to arbitrary external services, this seems like another use case for that \ I agree! ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: Announcing Archie version 0.4

On 23-02-18 17:17, Thomas Beale wrote: On 23/02/2018 15:36, Pieter Bos wrote: For microservices with enough traffic, or for devices with limited processing power or limited bandwidth, a binary encoding makes sense. However, GRPC would not be my first choice for OpenEHR - you would have to

Re: Announcing Archie version 0.4

On 23-02-18 16:36, Pieter Bos wrote: you would have to find a way to map all the inheritance in the OpenEHR model to protocol buffers. For Java I found this web-page which explains how to do it. It is about a class with one nested class

Re: Announcing Archie version 0.4

will, in a few weeks in a project I am working on. https://github.com/improbable-eng/grpc-web Bert Regards, Pieter Bos Op 23 feb. 2018 om 14:21 heeft Bert Verhees <bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> het volgende geschreven: The problem with Ice is that it is not open source l

Re: Announcing Archie version 0.4

The problem with Ice is that it is not open source licensed when used in a non GPLv2 product. Another problem is that they do not publish the price of a commercial license. That are restrictions that cause many programmers not to use it. https://zeroc.com/licensing On 23-02-18 13:59, Thomas

Re: Templates for application form development

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

Re: Templates for application form development

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

Re: Templates for application form development

Often Spanish is not always a big problem, let us try drag through Google translate to make it al readable Bert On 19-02-18 17:37, David Moner wrote: We also have a Final Degree Project where a student made a proposal for a Visual Template Model. It's from 2012, for ISO 13606, and also in

Re: Templates for application form development

l likely give enough to start with. A (not so very thought through yet) possible example of annotation use for application building is available in picture 40 (and supported by picture 36 in https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing //Erik mån 19 feb. 201

Re: Templates for application form development

sloppy English in my previous message, this time changing the meaning, I changed the quote below, I am awake now, will not happen again, excuse me) 2018-02-19 10:15 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>>: On 18-02-18 23:

Re: Templates for application form development

On 18-02-18 23:09, GF wrote: Is it an idea to annotate nodes with instructions for display. Personally I think having special templates/archetypes for display is better. Templates are create per purpose, and mixing purposes in a single template does  seem good idea to me

Re: Templates for application form development

Best regards Bert And sorry for the sloppy English (when reading back), on Sundays it is worse then on weekdays when I am in working mode. But I think my message is still understandable, so, have a nice Sunday-evening. ;-) Bert ___

Re: Templates for application form development

On 18-02-18 16:55, Thomas Beale wrote: On 18/02/2018 11:16, Erik Sundvall wrote: When designing this, perhaps some (2-5) existing currently popular GUI frameworks could be initial targets for output from the process, and the selection could be updated over time. Perhaps for example

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

On 17-02-18 16:33, Pablo Pazos wrote: I think that is the expected behavior, also what is returned depends on the operators in the SNOMED expression, like << will return all descendants. The expression can be tuned to return just what you want, and the process of the result should work

Re: Optmizing AQL

On 17-02-18 16:22, Pablo Pazos wrote: Just thinking out loud! But I'm working towards this with Diego :) Ah, I didn't know that. I must read the mailing-lists more often. Good luck with that. I am very interested to hear about proceedings and plans Bert

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

On 17-02-18 16:39, Pablo Pazos wrote: That is why SNOMED alone can't be used for querying. I agree with that, else, you would not need OpenEhr at all ;-) ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

On 17-02-18 11:21, GF wrote: That context/epistemology is defined by meta-data in COMPOSITION that as committed to databases and documents. That is why OpenEhr and SNOMED can be a strong combination. ___ openEHR-technical mailing list

Re: Optmizing AQL

On 17-02-18 15:47, Diego Boscá wrote: https://bioportal.bioontology.org/ It has tons of knowledge exposed as queriable web services. All services have an RDF output, so is perfect to demonstrate linked data Thanks, very interesting ___

Re: Optmizing AQL

On 17-02-18 13:11, Diego Boscá wrote: Maybe it is possible to generalize it in a way that it could be external calls that return a value or list of values. Maybe this is enough for SNOMED, CDSS, but also for queries to linked data such as drug-drug interaction and other services availabe in

Re: Archetype pattern

fferent types of data structures but both are necessary, we are not trying to waste each other's time. I too need to know what the domain looks like to understand the objectives that the models are trying to satisfy. I am not saying that the clinicians are "lacking", I am "lac

Re: openEHR REST APIs - Release 0.9.0 / invitation for comments

I think, it would be good if the community who did this fantastic job, should also divide a kernel in micro-services and having interfaces between them, and let there be one entry-service to have the micro-services expose themselve to the outside world over REST, for now. There is knowledge

Re: Archetype pattern

On 16-02-18 12:41, Thomas Beale wrote: in openEHR terms... On 16/02/2018 05:38, GF wrote: Hi all, In my opinion there are several types of ‘patterns’: - Specific Local Templates/patterns used in a defined community for specific purposes specialisations of any archetype for local usage.

Re: Archetype pattern

can only be better for everyone. Regards Heather -Original Message- From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Bert Verhees Sent: Friday, 16 February 2018 2:41 AM To: For openEHR technical discussions <openehr-technical@lists.openehr.

Archetype pattern

An interesting wiki from Heather Leslie https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns She concludes that pattern are necessary, I agree with that, and she also concludes that clinicians are better modelers then technicians. Well, that depends,

Re: openEHR-technical Digest, Vol 72, Issue 4

Best regards Bert Verhees On 06-02-18 18:42, Ricardo Gonçalves wrote: On the "putting together a web frontend and a Java backend" topic, it may be interesting to look at Vaadin, which is an open source framework to build web applications using Java (you code everything in Java, an

  1   2   3   4   5   6   7   8   9   >