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

Freriks > +31 620347088 > gf...@luna.nl > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > > On 3 Apr 2018, at 09:35, A Verhees <bert.verh...@rosa.nl> wrote: > > > GF :"There are NO agreed standardised archetypes/patterns we all use to > def

Re: [Troll] Terminology bindings ... again

Netherlands > > On 3 Apr 2018, at 09:31, A Verhees <bert.verh...@rosa.nl> wrote: > > Can we specific define in about ten words which problem is talked about in > this discussion? > > Maybe we can then use that definition as a guideline to keep the > discussion focussed

Re: [Troll] Terminology bindings ... again

GF :"There are NO agreed standardised archetypes/patterns we all use to define the meta-data in order to document the full eppistemology > so data can be interpreted fully and safely. " > So what do you suggest as a solution? > > > > >> >> Gerard Freriks >> +31 620347088 >>

Re: [Troll] Terminology bindings ... again

Can we specific define in about ten words which problem is talked about in this discussion? Maybe we can then use that definition as a guideline to keep the discussion focussed. Best regards Bert Verhees Op di 3 apr. 2018 01:19 schreef Pablo Pazos <pablo.pa...@cabolabs.com>: > Please

Re: [Troll] Terminology bindings ... again

plexity. Op ma 2 apr. 2018 23:35 schreef A Verhees <bert.verh...@rosa.nl>: > GF: "When we add to all this that only part of the epistemology can be > pre-coordinated it means that part of the temporal aspects for instance can > NOT be dealt with in SNOMED, then we have the situ

Re: [Troll] Terminology bindings ... again

GF: "When we add to all this that only part of the epistemology can be pre-coordinated it means that part of the temporal aspects for instance can NOT be dealt with in SNOMED, then we have the situation that part of the epistemology is in SNOMED and part defined in the Archetype/Template." ---

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

Sorry, this was a reply to Philippe on his message on 14:07 Op ma 2 apr. 2018 15:16 schreef A Verhees <bert.verh...@rosa.nl>: > Mostly a patients history is regarded in a consultation. Mostly this is > history from after the start of the electronical era and being treated in >

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

> The "good all" SOAP is dead ; nowadays, the encounter stream is switching to (AP)SO(A'P'): > people now come with an existing set of Assessments and Procedures, > not "just" with "Subjective" issues. > Wasn't that always the case? ___

Re: [Troll] Terminology bindings ... again

t; 2801 CA Gouda > the Netherlands > > On 31 Mar 2018, at 13:04, A Verhees <bert.verh...@rosa.nl> wrote: > > Okay. Do you have a technical description of what you are talking about? > > Thanks > Bert > > >

Re: [Troll] Terminology bindings ... again

Sorry, I am reading on my phone and it seems I missed an email. I read further day after tomorrow when I have a descent email client. Best regards Bert Op za 31 mrt. 2018 13:06 schreef A Verhees <bert.verh...@rosa.nl>: > Okay. Do you have a technical description of what you are talk

Re: [Troll] Terminology bindings ... again

Okay. Do you have a technical description of what you are talking about? Thanks Bert Op za 31 mrt. 2018 12:31 schreef GF : > In my opinion there is something essential missing, so far. > What is missing is a collection of standard Cluster archetypes/Patterns > that can be used to

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

a base-environment, weeks, maybe months at least, I guess you have other priorities and we live only once ;-) good luck Bert On Thu, Mar 29, 2018, 04:04 A Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote: Op do 29 mrt. 2018 02:39 schreef Pablo Pazos <pabl

Re: openEHR Toolkit

va only? I was hoping for an open architecture. Is it an idea to refactor it in that way? > On Mar 28, 2018 3:58 AM, "A Verhees" <bert.verh...@rosa.nl> wrote: > > Very interesting initiative. Is it an idea to make it some kind an open > framework/platform infrastructure s

Re: openEHR Toolkit

Very interesting initiative. Is it an idea to make it some kind an open framework/platform infrastructure so that other developers can collaborate or hang their software in? Op wo 28 mrt. 2018 05:40 schreef Pablo Pazos : > Hi all, > > I have released a humble pack of

Re: [Troll] Terminology bindings ... again

-technical digest..." Today's Topics:    1. Re: SV: [Troll] Terminology bindings ... again (A Verhees) -- Message: 1 Date: Mon, 26 Mar 2018 06:25:19 + From: A Verhees <bert.verh...@rosa.nl> To: For o

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

; > *Från:* openEHR-technical [mailto: > openehr-technical-boun...@lists.openehr.org] *För *Bert Verhees > *Skickat:* den 23 mars 2018 20:01 > > > *Till:* openehr-technical@lists.openehr.org > *Ämne:* Re: SV: [Troll] Terminology bindings ... again > > > > Diego, this is a wise thoug

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: SV: [Troll] Terminology bindings ... again

Maybe a match-table which matches pre coordinated expressions to all possible post coordinated expressions which have the same meaning will be necessary. How can you else find data-entries of a specific meaning by filtering on SNOMED? Bert Op 23 mrt. 2018 10:35 schreef "Bakke, Silje Ljosland" <

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 fo

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?

uot; <yamp...@gmail.com>: > Nothing restricts you to create a "data type pattern"/specialized cluster > that has exactly this semantics > > El mar., 20 mar. 2018 23:34, A Verhees <bert.verh...@rosa.nl> escribió: > >> One last remark. >> >>

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

A Calendar datatype. Op 20 mrt. 2018 23:33 schreef "A Verhees" <bert.verh...@rosa.nl>: > 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 technic

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

ypes > will be used for medical data, and maybe we don't really need nanosecond > precision. > > El mar., 20 mar. 2018 23:09, A Verhees <bert.verh...@rosa.nl> escribió: > >> Now you say, you are right. >> >> The Java 8 duration is indeed diffrent, but you can still us

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

y shortcut in specs, but it is not right. It is in fact misusing a datatype which does not support this expression. The ISO string should also be changed accordingly. Bert Op 20 mrt. 2018 23:24 schreef "A Verhees" <bert.verh...@rosa.nl>: > Now I come to think about it,

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

the same, but that can be ignored, it is one second every few years. Op 20 mrt. 2018 23:08 schreef "A Verhees" <bert.verh...@rosa.nl>: > Now you say, you are right. > > The Java 8 duration is indeed diffrent, but you can still use the Joda > duration, or you can w

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

Now you say, you are right. The Java 8 duration is indeed diffrent, but you can still use the Joda duration, or you can write your own duration class. In Golang the duration class is also limited, it is build around nanoseconds, but I wrote my own which is conform the OpenEhr specs, which was not

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

13/03/2018 à 18:01, Bert Verhees a écrit : > 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? Bert, I get your

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

  1   2   3   4   5   6   7   8   9   >