Re: Trial of openEHR's own 'stackExchange' on the openEHR wiki

On 07-01-16 19:45, Thomas Beale wrote: do you mean the 'top expert' kind of stuff? It seems pre-computed as far as I can tell. Let's play with it for a few months and see how well it works. We can always try somtehing else later if it doesn't do the job. Yes, I consider it a bit harmful. It i

Re: New EHRServer v0.5 and roadmap

Very nice, Pablo, an understandable query-builder. Well done. I looked at the code, clean code, worth reading. Good thing about groovy is that it produces clean code, I should train myself more in it. ;-) I take a further look at it next week. Thanks for sharing Best regards Bert On 15-01-

Re: Archetype relational mapping - a practical openEHR persistence solution

Another problem is you have to convert your object oriented model (which RM is) to a relational model, which becomes complex in converting templates/aql to SQL. I have been that way. More then five years ago I left it. It is difficult doable, if you want a full featured openehr kernel. I would neve

Re: Archetype relational mapping - a practical openEHR persistence solution

I have some opinions on this My experience years ago was also with an ORM environment, I tried several. but then I looked at the generated queries. This has nothing to do with scalability or good performance. If you want a system with several hundred simultaneous connections working on it,

Re: Archetype relational mapping - a practical openEHR persistence solution

quick. I will now read it more carefully Thank you very much for sharing. Bert Best Regards Xudong 2016-01-26 1:42 GMT+08:00 Bert Verhees <mailto:bert.verh...@rosa.nl>>: Another problem is you have to convert your object oriented model (which RM is) to a relation

Re: Archetype relational mapping - a practical openEHR persistence solution

/values in the back of the mind. Both the GUI problem as the query problem can be solved. It should be worth the spent time and the price of the book ;-) best regards and good luck Bert Verhees ___ openEHR-technical mailing list openEHR-technical

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26-01-16 11:25, Jan-Marc Verlinden wrote: Oracle rdbms is indeed ACID. You have to convert the archetype (ADL or XML) to XSD, that will be used to store the XML in a relational DB (for better performance). One small correction, Jan-Marc, this is not possible. Not all constraints possible in

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26-01-16 11:35, Thomas Beale wrote: 50,000 such 'paths of interest'. That's a very small number. These paths can be mapped in smart ways to a 64-but number space so that finding out if a specific query term is in some EHR is very quick. When you include a coded list of archetype ids in the m

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26-01-16 12:39, Thomas Beale wrote: I have not performance tested my own implementation (although I did actually build one over a decade ago). But the Informix path system was real and performant (they used a hierachical number node code approach e.g. 1.2.3, 1.2.3.1.2 etc). There are other

RE: Archetype relational mapping - a practical openEHR persistence solution

Not sure if you ask me Birger, but I will announce the github link here, and will build a working prototype in open source. Maybe parallel I will do something else, I am not sure about that Bert Op 26 jan. 2016 17:26 schreef "Birger Haarbrandt" : > > Thanks! Would be nice to hear about the progre

Re: Representing microseconds in DateTime

Just for the record, which medical requirement makes measuring micro-seconds necessary? By the way, ISO allows one or more digits to represent a decimal fraction of a second. I don't have the original standard at hand, but Wikipedia says: https://en.wikipedia.org/wiki/ISO_8601 There is no lim

Re: [FORGED] Re: Representing microseconds in DateTime

On 02-02-16 11:07, Koray Atalag wrote: Hi Bert, I was saying ISO8601 do support this – it is openEHR that constrains to milliseconds. You are right, you do say that. I don't know if your code supports this, because the ISO-time-string will be converted to a Time-class and must have the sa

Re: Archetype relational mapping - a practical openEHR persistence solution

On 12-02-16 18:26, Erik Sundvall wrote: if you are experimenting with open source native XML DBs for openEHR, it preformed well for "clinical" patient-specific querying even though all xml databases we tested were not suitable for ad hoc epidemiological population queries (without query specifi

Re: Archetype relational mapping - a practical openEHR persistence solution

is ready, I will make an announcement. Best regards and enjoy the weekend. Bert Verhees On 12-02-16 20:49, Bert Verhees wrote: On 12-02-16 18:26, Erik Sundvall wrote: if you are experimenting with open source native XML DBs for openEHR, it preformed well for "clinical" patient-specifi

Re: Archetype relational mapping - a practical openEHR persistence solution

13.02.2016 um 16:24 schrieb Bert Verhees <mailto:bert.verh...@rosa.nl>>: No comments, on the other hand it is Saturday I had left out some necessary technical details. I will possible build it and then have possible the fastest two-level-modeling engine in the world, which will, of c

Re: Archetype relational mapping - a practical openEHR persistence solution

cians have) but certainly XML would not be my first choice for the analytics layer. Birger Von meinem iPad gesendet Am 13.02.2016 um 17:56 schrieb Bert Verhees <mailto:bert.verh...@rosa.nl>>: Thanks, I always forget it is weekend, as independent developer, there ain't no such thin

Re: Archetype relational mapping - a practical openEHR persistence solution

On 14-02-16 00:04, Birger Haarbrandt wrote: Hi Bert, I'm not arguing that you can represent most data in XML. I'm just concerned that mangling high volume or specialized data like for example sensor data, genom data and geo-spatial data into a document format might not work too well. Also, w

Re: Archetype relational mapping - a practical openEHR persistence solution

they occur thousand times. I would be really disappointed if they do. Bert Op 14 feb. 2016 17:39 schreef "Karsten Hilbert" : > On Sun, Feb 14, 2016 at 12:01:55PM +0100, Bert Verhees wrote: > > > I don't believe that XML-databases actually store XML. Oracle, for > example, &g

Re: Archetype relational mapping - a practical openEHR persistence solution

If a database has a field-type XML, then I expect it does something special with that field that justifies the fieldtypename. Especially I expect that from Postgres, because they mostly do good things. Bert On 16-02-16 11:47, Thomas Beale wrote: On 14/02/2016 23:25, Bert Verhees wrote

Re: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

Just a thought on the reading of the article Good article, until I found this sentence: "domain models are now separate from the software (but not the product), and they can be built by non-IT personnel, assuming a tool with a reasonable user interface." Making user-interfaces is a profession

Re: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

information. I should not have mixed up these two subjects, although they always mix up at my daily routines. I am sorry for the confusion I might have caused. Best regards Bert Verhees On 14-03-16 13:55, Ian McNicoll wrote: Many thanks Jan (and of course to the author), Clearly this paper

Re: SV: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

On 16-03-16 00:36, Bjørn Næss wrote: Yes – there must be some kind of misunderstanding. The intention have never been that end-user should do the important and challenging work on developing clinicial information models (archetypes). The idea have been that this gives the clinical community a

Re: Composition commit and change types

I guess you need to version it, if you want it to be according the specs. That means, when you use it for a medication-list, you will get many versions of the same compositions for a patient. But if you do not version it, that means that the concept of replaying the Past in case of legal inves

Re: AOM C_STRING - single regex, or a list of strings?

On 07-04-16 11:16, Diego Boscá wrote: I don't see the problem of having just a list of strings and a regex for C_String. That is also my position, I don't know if it was clear, because, when I explain too much, sometimes the message becomes unclear ;-) So resuming: There will, in my position,

Re: AOM C_STRING - single regex, or a list of strings?

ch can result in a String or in a List. This needs then to be explained in the description. I would not have a problem with this. Another solution is indeed to add a property for a single regexpr. Bert Are you saying you want another, separate string field? On 07/04/2016 11:05, Bert Verhees

Re: AOM C_STRING - single regex, or a list of strings?

Do we have an agreement on this, like proposed? If so, then I can propose the change of grammar according this agreement, which is not very much, and then the case can be closed. Please let me know, so that I can proceed thanks Bert On 07-04-16 14:01, Bert Verhees wrote: On 07-04-16 13:55

Re: AOM C_STRING - single regex, or a list of strings?

On 07-04-16 17:44, Thomas Beale wrote: well, we need to get this right for everyone. The current spec works, but you are suggesting that it be changed to make it 'regex-only'; Diego I think is suggesting something else; but if we were going to change it, we need to get input from openEHR too

Re: AOM C_STRING - single regex, or a list of strings?

On 07-04-16 21:33, Thomas Beale wrote: Don't worry, I am thinking more in terms of weeks not years. But we do have a spec that does what is needed, the debate is whether there is a clearer way, and whether it is worth changing it. But - to make a (possibly) breaking change, we need more than

Secure EPD

hospitals So, maybe it is an interesting document to read. If not, just forget about it. https://securityevaluators.com/hospitalhack/securing_hospitals.pdf Best regards Bert Verhees ___ openEHR-technical mailing list openEHR-technical@li

SNOMED

Hi, I got an idea when reading the nice story from Heather on LinkedIn. In fact it is hers idea, but in a opposing way. https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie I wonder in how f

Re: SNOMED

Part two is of course, generating templates, and we almost have the GUI's in place. It is the enormous collection of medical datastructures which can be the source of many generated EPD-software. Bert On 29-04-16 08:50, Bert Verhees wrote: Hi, I got an idea when reading the nice

Re: SNOMED

IHTSDO concludes it can be partly reused without license, thus not stopping global use of Snomed-inspired archetypes.) Others will surely add more to the discussion. //Erik Sundvall Sent from mobile... fredag 29 april 2016 skrev Bert Verhees <mailto:bert.verh...@rosa.nl>>: Part

Re: SNOMED

CHIME, UCL On 29 April 2016 at 15:45, Bert Verhees <mailto:bert.verh...@rosa.nl>> wrote: Thanks Erik, for your reply. I did some more thinking in the meantime. In SNOMED you have disorders, and they have attributes, and we all know there are thousands of them. Writing

Re: SNOMED

Hi Daniel, thanks, I posted the idea also to some Dutch groups, one argument was that there is no workflow in SNOMED. It is not a perfect solution. Therefore I am glad you mention the low hanging fruit, and maybe it is more then "some", maybe it is a lot. So let us concentrate on that, and

Re: SNOMED

m SNOMED CT, given its imperfect adherence to ontology would be even harder to understand or use. - thomas On 29/04/2016 07:50, Bert Verhees wrote: Hi, I got an idea when reading the nice story from Heather on LinkedIn. In fact it is hers idea, but in a opposing way. https://www.linkedin.com/pu

Re: SNOMED

I understand now, Daniel, thanks for explaining. Have a nice day. Bert On 29-04-16 17:55, Daniel Karlsson wrote: Hi Bert, comments below! On 2016-04-29 17:04, Bert Verhees wrote: Hi Daniel, thanks, I posted the idea also to some Dutch groups, one argument was that there is no workflow in

Re: SNOMED

On 29-04-16 18:02, Ian McNicoll wrote: Hi Bert, "I think that every leaf-node in an Archetype can be encoded in SNOMED, don't you think?" I'm afraid not even close, especially when you take into account the changes in the meaning of datapoints that apply when used in differing contexts. Whe

Re: SNOMED

Interesting, the idea that SNOMED-concepts could need some status-attributes. When thinking about that, there could be attributes to serve other purposes too. Maybe the enormous amount of knowledge collected in SNOMED is not used as extensively as possible. There may be much more potential

Re: SNOMED

. Of course, it is just an idea, maybe worth studying. maybe later, if no one does look at it, I will do it. But I am afraid, earning money has some priority. ;-) Best regards Bert Verhees Op 2-5-2016 om 01:40 schreef Koray Atalag: Hi, Just to add some historical context – SNOMED evolved f

Re: Archie version 0.1.0 released

rhees/archetyped_kernel I only work one hour a day on it, when time permits, so not every day, but still, it is already 75% complete. I hope to finish that work before August. Best regards Bert Verhees On 18-05-16 17:24, Thomas Beale wrote: I'm sure something can be worked out. N

Re: More generic reference model

On 02-09-16 14:28, Daniel Karlsson wrote: Bert, if I understand your issue correctly, I believe that some sort of "code index" is needed in openEHR persistence implementations. This "code index" would link all codes used with the (full) path to the node where the code is used. There are sever

Re: More generic reference model

Op 6-9-2016 om 19:01 schreef Erik Sundvall: Many of us think that a better integration of the openEHR and the Snomed CT modelling efforts would be great. But there are not enough resources (e.g. dedicated time of people with the right knowledge) being put into doing this, since this is hard (bu

Re: More generic reference model

Op 6-9-2016 om 21:05 schreef Bert Verhees: we should sit down and wait until something will happen. we should *NOT* sit down and wait until something will happen. (sorry) ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http

Re: More generic reference model

ents level *- clear and succinct as possible please - it will help a lot. Here is a wiki page for gathering this information <https://openehr.atlassian.net/wiki/display/spec/Terminology+Querying+for+AQL>. As usual, contributors should feel free to change it as required. - thomas On 06/09/

Re: SV: More generic reference model

Op 9-9-2016 om 8:37 schreef Bjørn Næss: But in addition to that we need to map terms from different other terminologies like SNOMED-CT, LOINC and also Disease Ontologies. There is a mapping effort by IHTSDO en Regenstrief, they started that a few years ago, and it will be finished, next year,

Re: SV: More generic reference model

-openehr-aql-part-2/ I am interested in what you think about that. Best regards Bert Verhees Op 10 sep. 2016 05:03 schreef "pablo pazos" : > Hi all, > > > Regarding the genericity of the openEHR IM, from the implementation point > of view we have at least 3 models: &

Re: How can I model multiple checkboxs options with terminology?

Hi Tiago, I don't think multiple selections in a dvcodedtext is possible because a dvcodedtext can contain only one code in data. So I think you need multiple elements with each a dvboolean, you can group them using a cluster. If I am wrong, I am sure someone will correct me. Best regards

Re: How can I model multiple checkboxs options with terminology?

Hi Pablo, good solution, I think it is a better solution then mine, the only problem is that it allows more times the same selection, isn't it? Because you can let occur a DvCodedText more then once in an Element, but you cannot define it more then once. Maybe more elements with all one DvCodedText

Re: SV: More generic reference model

path-based queries, but your idea is interesting. One problem though is that query creators need to be experts in SCT. What do you think? Sent from my LG Mobile -- Original message-- *From: *Bert Verhees *Date: *Sat, Sep 10, 2016 13:14 *To: *For openEHR technical discussions; *Subje

Re: SV: More generic reference model

Op 11-9-2016 om 16:56 schreef Diego Boscá: I'm not a real fan of having just codes instead of expressions. Expressions are far more readable and may help in the understanding of the archetype. Just a single code representing the subset won't be as clear. Diego, I think you are right, a go

Re: How can I model multiple checkboxs options with terminology?

Op 11-9-2016 om 17:51 schreef Ian McNicoll: This leaves the problem of how to exclude non-unique elements as Bert suggested. We have talked in the past about adding a 'unique' keyword to occurences to signfify that repeated identical elements are invalid, however I am struggling to think of any

Re: SV: More generic reference model

is interesting. One problem though is that query creators need to be experts in SCT. What do you think? Sent from my LG Mobile -- Original message-- *From: *Bert Verhees *Date: *Sat, Sep 10, 2016 13:14 *To: *For openEHR technical discussions; *Subject

Re: SV: More generic reference model

Op 11-9-2016 om 20:01 schreef Thomas Beale: On 11/09/2016 15:48, pablo pazos wrote: Hi Bert, I was thinking about integrating SCT with path-based queries (I'm not in AQL yet), but maintaining the complexity of the SCT relationships and expressions on the terminology service (TS) side, so

Re: SV: More generic reference model

Op 11-9-2016 om 20:10 schreef Diego Boscá: The problem I see with depending on a given terminology service is that the code you are defining may or may not be known by the terminology service. I don't see that happen easily. Validate your archetypes on content also before using them. _

Re: SV: More generic reference model

Op 11-9-2016 om 20:21 schreef Thomas Beale: Not an unreasonable point of view, but it sort of implies that there are / will be no well-known / reliable terminology value sets out there - only specific value sets inside specific terminology services. This problem hads been tackled by IHTSDO. Th

Re: SV: More generic reference model

Op 11-9-2016 om 20:32 schreef Diego Boscá: In practical terms however, you can't always expect to have all the access that you want to a given external service. e.g. I was banned from W3C once for launching a transformation (more like 10k...) that depended on a online schema. A hospital can run

Re: How can I model multiple checkboxs options with terminology?

Op 12-9-2016 om 8:27 schreef David Moner: Bert, what you propose is probably mixing things from the data structure definition and from the UI, which is not a good idea for future maintenance. If we want to render the different options as checkboxes, as a selection list or whatever other represe

Re: SV: More generic reference model

Exactly Michael, that is what I was pointing at in my blogs a few days ago, making a golden pair of SCT and OpenEHR by combining the full potential of both. Even go further then FHIR, because FHIR is a message system, while OpenEHR is so much more then that. OpenEHR is the base of an application

Re: SV: More generic reference model

eds better then OpenEHR does without SCT, I think. 2016-09-12 8:27 GMT+02:00 Bert Verhees : Op 11-9-2016 om 20:32 schreef Diego Boscá: In practical terms however, you can't always expect to have all the access that you want to a given external service. e.g. I was banned from W3C once

Re: SV: More generic reference model

Op 12-9-2016 om 10:30 schreef Thomas Beale: does the expansion preserve IS-A relationships (at least optionally)? That's crucial for making any value set of more than about 20 terms usable in a real system. I think you need to do that by additional refinements, f.e. < 19829001 |disorder of lu

Re: SV: More generic reference model

Op 12-9-2016 om 10:32 schreef Thomas Beale: we also still need a standard approach for non-SNOMED CT terminologies, such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of progress on this issue? There is a detailed answer, I googled on SNOMED to ICD10 https://www.nlm.nih.g

Re: SV: More generic reference model

Thomas, from my phone, short. The Sct integration as I propose is optional. No changes in openehr specs is needed. No software change is needed. It are only additions except for two minor issues. So if organization's do not want to use Sct, or are not allowed to use it, they still can keep on usin

Re: SV: More generic reference model

oach for non-SNOMED CT terminologies, such > as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of > progress on this issue?- thomasOn 12/09/2016 07:32, Diego Boscá wrote:> sure > thing, that's why we need standard expressions>> 2016-09-12 8:27 GMT+02:00

Re: SV: More generic reference model

e are just selectors; what I mean is that in the generated result - > the actual value set - that IS-A relationships are returned as well as > concept codes. Without IS-A relationships a user can't navigate a value set > larger than a few terms in a useful way in a real system. > > &

Re: SV: More generic reference model

in the near future, but some coherent material would be very helpful. thanks - thomas On 12/09/2016 22:42, Bert Verhees wrote: Even better, Pablo, it uses SCT, and does not stand in the way of other terminologies, it is a parallel process which fits inside the OpenEhr specs. I tried t

Re: SV: More generic reference model

peripheral questions that have been answered along the way. The Specifications Editorial Committee will look at these issues in the near future, but some coherent material would be very helpful. thanks - thomas On 12/09/2016 22:42, Bert Verhees wrote: Even better, Pablo, it uses SCT, and do

Re: Converting Archetype into Nosql Schemes

Sorry, I cannot help you, but it is a very interesting question, and I am very interested to hear about follow up. Bert Op 13 okt. 2016 18:32 schreef "Fadoua Khennou" : > Hello, > > I am a Phd student, working on the implementation of OpenEhr standard with > Nosql technologies in order to study

Re: Converting Archetype into Nosql Schemes

Very good presentation, Pablo. Very good for people studying the possibilities, good study, good evaluation of the databases. I was missing the MarkLogic database, which is expensive to use ($18.000 a year, or $0.99/hr on Amazon AWS), but can be downloaded for free for developers: http://de

Re: openEHR and terminology servers

can also used for these mappings which gives in this way a route to query other terminologies. good luck Bert Verhees On 04-12-16 01:53, Pablo Pazos wrote: Hi Daniel, Did your team publish any articles about the demonstration? I'm interested in the technical aspects of querying expansi

Re: openEHR and terminology servers

> e.g Give me any patients with a problem/diagnosis of diabetes mellitus type 2 or children. i.e is_a relationships If you are able to have a SNOMED expression in your archetype which represents the archetype, then you have a good query base to use the SNOMED model to full extend. >From this it i

Re: openEHR and terminology servers

As a matter of fact, I am building such an archetype editor as a hobby project, just for fun. Bert Op 4 dec. 2016 13:54 schreef "Bert Verhees" : > > e.g Give me any patients with a problem/diagnosis of diabetes mellitus > type 2 or children. i.e is_a relationships > >

Re: openEHR and terminology servers

Hi Diego, your link does not work. But I am replying for another reason. I think that subsumption testing in archetypes is not feasible when the archetypes are not covered by SNOMED. This is because SNOMED subsumption testing is only valid inside the SNOMED definitions. The system of special

Re: openEHR and terminology servers

On 04-12-16 19:25, Diego Boscá wrote: Oh, and if the above link fails you can try the mirror http://diebosto2.pc.upv.es:/SnomedQuery/ That doesn't work either, maybe it is a country thing? ___ openEHR-technical mailing list openEHR-technical@lis

Re: openEHR and terminology servers

On 04-12-16 19:18, Diego Boscá wrote: constraints in specialized archetypes must be included in the parent constraints. e.g. parent archetype contains the "any allergy" subset and the children archetype contains "all allergies caused by a drug", and for that specialization to be correct, the seco

Re: openEHR and terminology servers

a completa de la causa de este error se encuentra en los archivos de diario de Apache Tomcat/8.0.26. <http://8.0.26.>_ 2016-12-04 21:36 GMT+01:00 Diego Boscá mailto:yamp...@gmail.com>>: I believe there are no country restrictions El 4/12/2016 20:56, "Bert Verhees

Re: openEHR and terminology servers

By the way, looks like a very interesting software, but I must study it better. Is there some documentation also? Bert On 04-12-16 22:59, Bert Verhees wrote: Works fine in Firefox, does not work in Chrome, both in Linux. (maybe that helps analyzing the problem) On 04-12-16 22:15, Birger

Re: openEHR and terminology servers

Seems a problem with language settings/preferences to Dutch in browser. It also appears on Mac. So, some work to do ;-) Bert Op zo 4 dec. 2016 22:59 schreef Bert Verhees : > Works fine in Firefox, does not work in Chrome, both in Linux. > > (maybe that helps analyzing the problem) >

Re: openEHR and terminology servers

good. Thanks for sharing Bert Regards 2016-12-04 21:39 GMT+01:00 Bert Verhees : On 04-12-16 21:36, Diego Boscá wrote: I believe there are no country restrictions On private mail Does it work at your site? My screen looks like this. Estado HTTP 500 - com.vaadin.server.ServiceException

Re: openEHR and terminology servers

> > Cheers, > Pablo. > > On Sun, Dec 4, 2016 at 5:37 AM, Bert Verhees wrote: > > A Rest service for terminology needs to be defined per terminology, > because they are all of different features. > > There is one good source of inspiration for a SNOMED terminology.

Re: Could the specs group consider making uid mandatory?

I completely agree with this argument from Heath : I think it should be a strong recommendation rather than mandatory considering it is currently optional and the need for backward compatibility. Op ma 19 dec. 2016 07:07 schreef Thomas Beale : I knew that :) On 19/12/2016 14:17, Grahame Grieve

Re: Cloud EHRServer is about to be launched

I think Jan Marc has a point but Pablo is excused because there is no other way inside the community Would be a good idea to have a list for announcements by the public. Best regards Bert Verhees Op 26 dec. 2016 11:33 schreef "Jan-Marc Verlinden" < jan-m...@medvision360.com>

Re: Cloud EHRServer is about to be launched

mailinglists > > Peter > > > On 27 Dec 2016, at 03:55, Bert Verhees wrote: > > I think Jan Marc has a point but Pablo is excused because there is no > other way inside the community > Would be a good idea to have a list for announcemen

Re: Cloud EHRServer is about to be launched

> there is no other way to reach the community and the announcing list is used by the openEHR Foundation Board, not by community members Great Pablo, congratulations. Good work. Important for the community. I think this issue needs to be repaired soon. It must be the Christmas period that there i

Re: Better approach for announcements, forums?

Please, Ian, also discuss an announcementlist for free and open source software (my favour is read-only, announcements only), and, also your own suggestion, to have a low fee membership for single person or low income business Thanks Bert Op wo 4 jan. 2017 om 13:02 schreef Ian McNicoll : > Thank

Re: Better approach for announcements, forums?

services or software on a announcement list (which is still to setup.) Op wo 4 jan. 2017 om 14:21 schreef Thomas Beale : > > > On 04/01/2017 12:18, Bert Verhees wrote: > > Please, Ian, also discuss an announcementlist for free and open source > > software (my favour is read-onl

Re: Better approach for announcements, forums?

For me, that is just fine as you describe Op wo 4 jan. 2017 om 15:03 schreef Thomas Beale : > > On 04/01/2017 13:53, Bert Verhees wrote: > > My issue is that for people running incidental business or incidental > > income, maybe only a few thousands a year, 650 Euro is really

NHS melt down

http://www.theregister.co.uk/2017/01/31/nhs_reply_all_email_fail_half_billion_messages/ ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: NHS melt down

Op 1-2-2017 om 9:00 schreef Bert Verhees: http://www.theregister.co.uk/2017/01/31/nhs_reply_all_email_fail_half_billion_messages/ Sorry, wrong address ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org

inheritance of archetypes

suggest here maybe limited to the cases where it is real inheritance. 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: inheritance of archetypes

Good news Thomas, but don't bring it with disdain. Op 1-3-2017 om 10:15 schreef Thomas Beale: which when they are read into ADL Workbench, are re-engineered into differential form I think the ADL Workbench is a cryptic piece of software which could use some GUI-specialists to redesign it, so

Re: inheritance of archetypes

Op 1-3-2017 om 10:44 schreef Thomas Beale: Good news Thomas, but don't bring it with disdain. I don't know what the words means ;) I got it from google translate, in French it is dedain. that appears to be a PR about GDL? I meant a current list of Open Issues, I don't know why the 168 is

Re: inheritance of archetypes

> 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: @ianmcnicoll > > [ > https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjR

Re: inheritance of archetypes

not, but that discussion did not help me. But in the end my problem is solved so everything is oké now. Best regards Bert Op wo 1 mrt. 2017 15:55 schreef Bert Verhees : > Lots of good things happening. We will see when major shifts will occur. I > keep my finger in the wind and expect a

Re: SNOMEDCT - correct representation

On 25-04-17 09:50, Diego Boscá wrote: I think having this in a hardcoded terminology list is probably far from ideal (e.g. how do you put "snomed ct+norway national extension"? do we need an exhaustive listing of all possible extensions/versions?) When you use SNOMED in termbindings, you don't

Re: SNOMEDCT - correct representation

On 03-05-17 12:36, Thomas Beale wrote: The only missing part, now that I look at the SNOMED Compositional Grammar and Expression Constraint Language specs, is how to create a URI (which i

Re: SNOMEDCT - correct representation

On 03-05-17 12:53, Thomas Beale wrote: On 03/05/2017 11:40, Bert Verhees wrote: On 03-05-17 12:36, Thomas Beale wrote: The only missing part, now that I look at the SNOMED Compositional Grammar <https://confluence.ihtsdotools.org/display/DOCSCG> and Expression Constraint Language

Re: SNOMEDCT - correct representation

2017-05-03 13:09 GMT+02:00 Daniel Karlsson >: See this page: https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard Please consider the language used when p

Re: SNOMEDCT - correct representation

On 03-05-17 14:20, Thomas Beale wrote: that is seriously unreadable. I don't think that is a problem, all programming languages have libraries to en/decode that kind of strings, so archetype-tooling can do that without much programming effort, and also this can be done when copy and pasting

Re: SNOMEDCT - correct representation

this. Best regards Bert Verhees Op 3 mei 2017 16:45 schreef "Diego Boscá" : well, nothing stops you for not encoding the query in definition time, most services are ok with that e.g. http://diebosto2.pc.upv.es:/SnomedQuery/ws/JSONQuery?query= <404684003:363698007=39057004 2017-05-

Re: SNOMEDCT - correct representation

for SNOMED, but also LOINC, ICDx, HL7, and all the other terminologies. - thomas On 03/05/2017 12:09, Daniel Karlsson wrote: See this page: https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard <https://conf

<    1   2   3   4   5   6   7   8   9   10   >