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

<thomas.be...@openehr.org>: > > > On 21/02/2018 13:00, Bert Verhees wrote: > >> On 20-02-18 20:09, Thomas Beale wrote: >> >>> >>>> The terminology service also has dependencies to rm data types, only >>>> because of codephrase. Woul

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: Clarifying - Templates for application form development

regards Bert Op di 20 feb. 2018 17:05 schreef Bert Verhees <bert.verh...@rosa.nl>: > Hi Thomas, good clarification, although too much in detail at some > points in this moment of thinking about it. > > I see it as more simple, > > 1) about the classes, it would be nice, in my op

Re: Templates for application form development

> > So splitting up the RM instead of making it larger would be my idea. The > first is not easy to do, but the second is, and helps us avoiding further > problems and avoiding creating unnecessary large libraries. > > > We are not intending to make the RM any larger, not sure why you think we >

Re: Templates for application form development

terminologyId would be a part of terminology service. Or support should be the inner most circle, then terminology and then datatypes? Bert Op di 20 feb. 2018 21:19 schreef Bert Verhees <bert.verh...@rosa.nl>: > I must have missed new developments, I am still working with RM 1.0.3 &

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

In fact David, the work is about how an interface should look like, that is interesting for GUI designers. But the discussion here is not about GUI design but about offering a technical environment to GUI designers. Bert Op 19 feb. 2018 17:57 schreef "David Moner" : I was

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: Templates for application form development

in the first announcement of a good plan. Best regards Bert Op za 17 feb. 2018 22:53 schreef A Verhees <bert.verh...@rosa.nl>: > I know Thomas, but they have dependencies to other classes in the RM. To > data types, to support. By the way, I have never seen use for translation >

Re: Templates for application form development

further problems and avoiding creating unnecessary large libraries. Bert Op 17 feb. 2018 22:12 schreef "Thomas Beale" <thomas.be...@openehr.org>: On 17/02/2018 18:06, A Verhees wrote: If it was to me to design, I would not change the RM. In fact, I think the RM has already

Re: Templates for application form development

If it was to me to design, I would not change the RM. In fact, I think the RM has already classes which do not belong there in my opinion. I think of AuthoredResources, TranslationDetails, they belong in the AOM. The RM should not be a myriad of classes used left/right in the OpenEhr system. We

Re: Archetype pattern

ion to you Thomas, am I right or am I wrong? Best regards Bert Op 17 feb. 2018 20:22 schreef "A Verhees" <bert.verh...@rosa.nl>: > It was my own idea, I wrote they will not say that out loud. > > (It was a joke) > Bert > > Op za 17 feb. 2018 20:18 schreef Thomas Beale

Re: Archetype pattern

It was my own idea, I wrote they will not say that out loud. (It was a joke) Bert Op za 17 feb. 2018 20:18 schreef Thomas Beale <thomas.be...@openehr.org>: > > > On 16/02/2018 18:30, A Verhees wrote: > > > > But I have one remark about your point 4, about SNO

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

the result to the database-specific AQL engine maintainers/developers. Bert 2018-02-17 9:23 GMT+01:00 A Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>>: The discussion Pablo has makes me think it could be good to have in an AQL-engine an entry to have ex

Optmizing AQL

The discussion Pablo has makes me think it could be good to have in an AQL-engine an entry to have external query languages executed like SNOMED expressions which can treat result data as hierarchies of data and so add an extra functionality layer Bert

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

Hi, sorry to interfere, if II understand well, I think a possible problem could be that respiratory infection caused by a virus can return some derived codes to be returned although in this case it are not so many. However to use this mechanism generally, it can happen that really many derived

Re: Archetype pattern

> > AQL does have a 'wildcard' - it is the CONTAINS operator - it's the > equivalent of the '//' operator in Xquery and Xpath. That's why you can > query for an Observation path (say, to systolic BP) regardless of how many > layers of SECTIONs it might be under. > Sorry I did not think about

Re: Archetype pattern

Op vr 16 feb. 2018 14:26 schreef Thomas Beale <thomas.be...@openehr.org>: > > > On 16/02/2018 09:23, Bert Verhees wrote: > > > > I think it means, predictable paths, so data can be found by queries > > without even knowing exact what one is looking for. For ex

Re: Archetype pattern

irector, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 16 February 2018 at 13:22, Thomas Beale <thomas.be...@openehr.org> wrote: > > > On 16/02/2018 09:48, Bert Verhees wrote: > > On 16-02-18 12:41, Thomas Be

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

source domain. But first we need a plan, architecture. We'll see. Bert Op 16 feb. 2018 14:28 schreef "Thomas Beale" <thomas.be...@openehr.org>: > Bert, > > agree, and that's a good list. > > - thomas > > On 16/02/2018 09:59, Bert Verhees wrote: > > I think

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

Re: Announcing Archie version 0.4

Thanks, Pieter, very useful, good work Best regards Bert On 31-01-18 16:18, Pieter Bos wrote: Hi, We’re pleased to announce Archie version 0.4! For those of you unfamiliar with Archie, it’s an Apache 2 licensed OpenEHR java library, suitable as a basis for archetype modelling and EHR

Re: Quantities of arbitrary units in openEHR

On 29-01-18 15:22, Thomas Beale wrote: Another idea is to change it to a CODE_PHRASE, with terminology_id = UCUM Yes, I understand the decision, but IO regard it as a quick decision which can cause problems on the longer term. For the record, I object against this decision for the last

RE: Quantities of arbitrary units in openEHR

compatibility may be important. I don't know if Diego's proposal is feasible and I hope to hear from others what they think. Bert Op 28 jan. 2018 23:17 schreef "A Verhees" <bert.verh...@rosa.nl>: > Sam, for me the point was not having an OpenEhr property but an UCUM > p

RE: Quantities of arbitrary units in openEHR

Sam, for me the point was not having an OpenEhr property but an UCUM property which has also conversion routines for units within that property boundary available, so that it does not matter if the dataset contains Fahrenheit or Celsius when property "temperature" was constrained, because UCUM can

Re: Quantities of arbitrary units in openEHR

On 27-01-18 11:16, Thomas Beale wrote: Bert, I don't disagree philosophically, but practically speaking, no SNOMED service is going to be able to answer requests to do with unit properties, unit conversions, or different forms of rendering, which are all things we need to take care of

Re: Quantities of arbitrary units in openEHR

On 27-01-18 11:10, Bert Verhees wrote: If one wants an UCUM term in the DvQuantity and another wants a SNOMED term, it is both legal and possible. What is preferable, that is not to us to decide while thinking about OpenEhr. But having said this Until now, in practice, people use

Re: Quantities of arbitrary units in openEHR

On 26-01-18 10:00, Thomas Beale wrote: The thing I am not a fan of is that units themselves become part of terminology. This is a SNOMED direction but I think a wrong one. The reason is that the ontology of units isn't the same as the ontology of findings, medications and so on. In fact they

Re: AW: AW: Quantities of arbitrary units in openEHR

On 26/01/2018 13:23, Bert Verhees wrote: On 26-01-18 08:53, Sebastian Garde wrote: This is where I think that not only it is stated that openEHR uses UCUM (and not some part or “inspiration” of it), but also implies that the case sensitive version of it is used (which in my view is important

Re: AW: AW: Quantities of arbitrary units in openEHR

On 26-01-18 08:53, Sebastian Garde wrote: This is where I think that not only it is stated that openEHR uses UCUM (and not some part or “inspiration” of it), but also implies that the case sensitive version of it is used (which in my view is important to know at least for some of the units). I

Re: Quantities of arbitrary units in openEHR

On 26-01-18 10:40, Bakke, Silje Ljosland wrote: (We are literally talking about a 'public available UCUM service') I don't think that is necessary, UCUM is a very small service, which can also be in software as a library or small external service in microservice architecture.

Re: AW: Quantities of arbitrary units in openEHR

On 25-01-18 17:48, Bert Verhees wrote: A UCUM-service is quite simple, it has a simple API. You can extract it from this testfile which you find here: https://github.com/BertVerhees/ucum/blob/master/convey/ucum/UcumEssenceService_test.go I must add a few small remarks, this github-repository

Re: AW: Quantities of arbitrary units in openEHR

On 25-01-18 17:34, Thomas Beale wrote: On 25/01/2018 16:28, Bert Verhees wrote: On 25-01-18 11:03, Sebastian Garde wrote: Hi Silje, I think this may ‘just’ be a modelling tooling issue, openEHR itself supports this ok. Speaking for CKM, if you upload an archetype with this to CKM

Re: AW: Quantities of arbitrary units in openEHR

pes could constrain these properties instead of constraining the stringified 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: Quantities of arbitrary units in openEHR

It would be good if OpenEhr RM would support the UCUM-properties fully in the DvQuantity, then all problems regarding units would be over for the next 20 years, and no maintenance on customer or OpenEHR-foundation side is needed. UCUM is, I think, widely regarded as the most important

Re: UCUM

that an improved version of the UCUM standard website will be transferred soon to the infrastructure that hosts the LOINC website too. So the bell ringing worked out ;-) Bert On 21-11-17 09:04, Bert Verhees wrote: I wrote a message to the chief Nictiz terminology specialist to ring some bells. I don know

Re: Extract archetypes

suggested. Okay, thanks. - thomas On 30/11/2017 13:55, Bert Verhees wrote: So, there are also considerations I did not see. I can live a few days more without having a definite policy ;-) But the classes are there and people will want to use them. I think Thomas proposal is in line with the other

Re: Extract archetypes

penEHR-EHR_EXTRACT-EXTRACT.something.v1.0.0. There are examples <https://github.com/openEHR/adl-archetypes/tree/master/Example/openEHR/ehr_extract_template/Working/Archetypes/ehr_extract> already of this in the archetype test repo. - thomas On 30/11/2017 12:09, Bert Verhees wrote: On 30-11-17

Re: Extract archetypes

ract.html <http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html> (notice that demographics and EHR are the other package names). After that you would put the corresponding class name to constraint Regards 2017-11-30 8:55 GMT-03:00 Bert Verhees <be

Re: Extract archetypes

eases/RM/latest/docs/ehr_extract/ehr_extract.html <http://www.openehr.org/releases/RM/latest/docs/ehr_extract/ehr_extract.html> (notice that demographics and EHR are the other package names). After that you would put the corresponding class name to constraint Regards 2017-11-30

Re: Extract archetypes

eases/RM/latest/docs/ehr_extract/ehr_extract.html (notice that demographics and EHR are the other package names). After that you would put the corresponding class name to constraint Regards 2017-11-30 8:55 GMT-03:00 Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>>:

Extract archetypes

Hi, Since that it is so that some extract-classes derive from Locatable, they can be used to use them as RM-class for an archetype-definition. But how would the ArchetypeId look like, special the rmName. Would it be something like openEHR-Extract-Extract ? Thanks in advance for

Re: Blockchain

On 22-11-17 18:07, Philippe Ameline wrote: Bert, I just found this image on Twitter and it made me remember this trend where you tried to argue in favor of the blockchain in front of naysayers. https://twitter.com/MalwareTechBlog/status/932649133256597505

Re: Blockchain

ea. But I know it is useless since, in France, our technocrats have been trying to do it with the "DMP" for 13 years... and going... since, these days, there is a new attempt... and they are very optimistic since, after carefully listening to the MDs, they built a user interface with

Re: Blockchain

How do you explain that mayor players in government and healthcare-ict industry do not agree with this? Which mistake do they make? Op wo 22 nov. 2017 11:38 schreef Philippe Ameline : > Hi to all, > > Just discovered a decision tree about using Blockchain that pretty

Re: UCUM

On 20-11-17 12:02, Bert Verhees wrote: On 20-11-17 11:26, Thomas Beale wrote: Seriously though, why isn't it hosted at Regenstrief or HL7, or even better, NLM? It's one of the best pieces of work in the history of health informatics - it really should be kept alive for the long term. I

Re: UCUM

On 20-11-17 11:26, Thomas Beale wrote: Seriously though, why isn't it hosted at Regenstrief or HL7, or even better, NLM? It's one of the best pieces of work in the history of health informatics - it really should be kept alive for the long term. I wrote a message to the chief Nictiz

Re: UCUM

governmental institution for Health ICT). They have a lot of information about UCUM and how good it is on their website. Bert I’ll pass your thanks on Grahame On 20 Nov 2017, at 8:27 pm, Bert Verhees <bert.verh...@rosa.nl> wrote: On 20-11-17 02:58, Grahame Grieve wrote: Gunthe

Re: UCUM

On 20-11-17 02:58, Grahame Grieve wrote: Gunther says that the server had crashed, and he thinks it's memory related. He's put a process in place to email him when it stops responding Thanks, I wonder, should such a server get funding to run in a professional hosting-environment. I never

Re: UCUM

On 19-11-17 09:47, GF wrote: Lesson: - One is at risk when relying on one single source; one single point of failure. It is not really a single source, the XML file can be downloaded from many sites, also Nictiz. Even from my github-account:

Re: UCUM

On 19-11-17 09:31, Ian McNicoll wrote: Does not work here either, Bert. The whole site is offline. Probably just a tech snafu. Thanks Ian, it is strange, it is so since (at least) three days. I wouldn't expect that from such an important standard. Bert

UCUM

Sorry for this message which has nothing to do with OpenEhr, but I have a problem and possible here someone knows how to help. I am trying since a few days to reach the UCUM site because I want to download the UCUM XML file This would be on the URL: http://unitsofmeasure.org/trac But it

Re: Blockchain

in the hype-phase. - Many of the potential advantages will have to be proven. Gerard Freriks +31 620347088 gf...@luna.nl <mailto:gf...@luna.nl> Kattensingel 20 2801 CA Gouda the Netherlands On 15 Nov 2017, at 21:14, Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>>

Re: Blockchain

to play nice with other specs and technologies. > > 2. If someone is interested in BC, might write an ITS document relating > openEHR and BC at the implementation technology level, I don't see any > links between BC as a technology and openEHR as a specification. > > > My 2C. >

Re: Blockchain

be cheap. What we need now is crypto analysts which can work this out. That is what I wanted to say. Best regards Bert Verhees Op 15 nov. 2017 17:11 schreef "Thomas Beale" <thomas.be...@openehr.org>: > That is okay, Gerard, no need to be very sorry. It is just a discu

Re: Blockchain

y. > What I wrote I found it at their summary (page 8) of the NICTIZ document. > Of course it is my selection from that text. > > Gerard Freriks > +31 620347088 <+31%206%2020347088> > gf...@luna.nl > > On 16 Nov 2017, at 00:53, Bert Verhees <bert.verh...@rosa.nl> wro

Re: Blockchain

Mastercard thinks that this is indeed possible. Best regards Bert Verhees Op 16 nov. 2017 00:03 schreef "GF" <gf...@luna.nl>: > Hi, > > > A *blockchain*[1] > <https://en.wikipedia.org/wiki/Blockchain#cite_note-te20151031-1>[2] > <https://en.wikipedia.org/wik

Re: Blockchain

There are so many privacy breaches in medical data, hacked accounts, data-leaks, wacky account rules, social hacking, temporary personal from employment agencies, no logging on access to systems, systems standing open and the nurse doing something else. A GP can call a specialist, it is very

Re: Blockchain

On 14-11-17 17:44, GF wrote: In other words: What is BlockChain solving? My answer: it solves non-repuduation without a third trusted party. It also allows to chain events ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: Aw: Re: Blockchain

On 14-11-17 16:39, Grahame Grieve wrote: either you end up falling back to a central authority after all - Can you explain why? Bitcoin, f.e. is about billions of dollars without central authority, that is one of the reasons the Chinese government prohibited the creation (although they do

Re: Aw: Re: Blockchain

On 14-11-17 16:24, Seref Arikan wrote: You may want to check internet access packages in the Himalayas or Sahara before you setup shop there Bert ;) I am not really into that technical knowledge like radio-modulation or laser-light modulation. But when they communicate with the Hubble

Re: Aw: Re: Blockchain

On 14-11-17 16:02, Philippe Ameline wrote: It can currently been argued that this competition led to concentrating miners in China... but what could possibly go wrong? Bitcoin is since a few weeks prohibited in China but it seems hard to kill. But still, I don't think the use of blockchain in

Re: Blockchain

On 14-11-17 15:50, Bert Verhees wrote: Can it be that data refer to data on other systems, or may they only refer to data on the same system, copies of data from other systems? In the Netherlands we have a national system called the LSP, which makes medical data available to other clinicians

Re: Blockchain

will find use there. - thomas On 13/11/2017 13:15, Bert Verhees wrote: On 13-11-17 14:02, Thomas Beale wrote: ... What openEHR has as an underlying data management paradigm is distributed version control - each EHR is like a little git repo. This is no longer new or interesting (in fact, I w

Re: Blockchain

it on the screen is also an action, and then going to visit the patient, action... It gets more interesting when more systems are involved because they together register a chain of events, and because of the blockchain they can relate to each other. - thomas On 13/11/2017 14:02, Bert Verhees wrote

Re: Blockchain

[3] for agreements, 2-of-3 multi-sig for escrow, BTC for remittance and IPFS for distributed file storage. [1] https://www.openbazaar.org/ [2] https://en.wikipedia.org/wiki/OpenBazaar [3] https://en.wikipedia.org/wiki/Ricardian_contract On Mon, Nov 13, 2017 at 7:47 AM, Bert Verhees <bert.v

Re: Blockchain

On 13-11-17 15:00, Grahame Grieve wrote: In FHIR I think that discussion will come very sooner, because, it is about messaging, and also, it describes technical layers. yes it did. I'm sceptical there for the same reasons. You can track the discussion if you are interested:

Re: Blockchain

, blockchain is unlikely to be be scalable. Maybe this will change and blockchain will find use there. - thomas On 13/11/2017 13:15, Bert Verhees wrote: On 13-11-17 14:02, Thomas Beale wrote: ... What openEHR has as an underlying data management paradigm is distributed version control - each EHR

Re: Blockchain

problem to date. However, if you want to accumulate the whole contents of transactions, blockchain is unlikely to be be scalable. Maybe this will change and blockchain will find use there. - thomas On 13/11/2017 13:15, Bert Verhees wrote: On 13-11-17 14:02, Thomas Beale wrote: ... What openEHR

Re: Blockchain

On 13-11-17 14:02, Thomas Beale wrote: On 13/11/2017 12:32, Grahame Grieve wrote: I am sceptical of most use cases of block chain outside payments witnessing in some limited trading schemes. There are 2 inter-related problems. - block chain is a very inefficient solution to a problem that

Re: Blockchain

On 13-11-17 13:55, GF wrote: see below. Gerard Freriks +31 620347088 gf...@luna.nl <mailto:gf...@luna.nl> On 13 Nov 2017, at 13:17, Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote: Not very far from now (looking into the future, Scotty and Capt

Re: Blockchain

selective sharing data for research using active blockchains (e.g. ethereum) but by and large these seem outside the scope of records and EHRs to me Grahame On Mon, Nov 13, 2017 at 11:24 PM, Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote: On 13-11-17 13:

Re: Blockchain

king place. That is the reality today, this will become more and more soon. Bert 2017-11-13 13:17 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>>: Not very far from now (looking into the future, Scotty and Captain Kirk), health information will be a wo

Re: Blockchain

On 13-11-17 13:24, Anastasiou A. wrote: I agree, I was referring to more use cases with the outlook of incorporating blockchain into the existing openEHR model. Not blockchain itself. (The bit about interacting parties is the "maybe add it in the service model" (?)) Maybe, I am not the

Re: Blockchain

On 13-11-17 13:06, GF wrote: What problem is BlockChain solving, that deployed technologies can not solve? Read the document I linked to in my previous message, you can read dutch. Gerard Freriks +31 620347088 gf...@luna.nl On 13 Nov 2017, at 12:46, Bert Verhees <bert.verh...@rosa

Re: Blockchain

Original Message- From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Bert Verhees Sent: 13 November 2017 11:47 To: For openEHR technical discussions Subject: Blockchain How are the plans about blockchain for OpenEhr? Is there any plan to incorporat

Re: Aw: Re: Aw: Blockchain

better an old joke then everybody sad ;-) On 13-11-17 13:04, Birger Haarbrandt wrote: ;) Sorry, I could not resist -- Diese Nachricht wurde von meinem Android Mobiltelefon mit 1&1 Mail gesendet. Am 13.11.17, 12:59 PM, Bert Verhees <http://bert.verhees>@rosa.nl> schrieb: On 1

Re: Aw: Blockchain

6 PM, Bert Verhees <http://bert.verhees>@rosa.nl> schrieb: How are the plans about blockchain for OpenEhr? Is there any plan to incorporate it in the standard, or is it regarded as a technical implementers business? Bert __

Re: Blockchain

OpenEhr does not want to get involved with. Bert On 13-11-17 12:49, Diego Boscá wrote: Hi Bert, Where do you want to apply it? 2017-11-13 12:46 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>>: How are the plans about blockchain for OpenEhr? Is th

Blockchain

How are the plans about blockchain for OpenEhr? Is there any plan to incorporate it in the standard, or is it regarded as a technical implementers business? Bert ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: Stackoverflow tag: openehr

will break out of the inner-circles in which it seems to be now (to my feeling) Best regards and thanks Bert Verhees On 13-11-17 12:31, gjb wrote: On 11/11/2017 18:28, Bert Verhees wrote: Well done, Gavin, I hope there will be the needed activity. It may, for some people, being more ad hoc

Re: Stackoverflow tag: openehr

Wasn't that something on a sister-site of Stackoverflow? StackExchange or something like that. Anyway, this is technical only. Maybe it will succeed. The community is growing and so maybe people will try to find answers on Stackoverflow. Op za 11 nov. 2017 18:56 schreef Pablo Pazos

Re: Stackoverflow tag: openehr

it now, but the tag adding needs some peer review, maybe Gabin, you can take care for that. https://stackoverflow.com/review/suggested-edits/17913444 https://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve Best regard Bert Verhees

<    1   2   3   4   5   6   7   8   9   >