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

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

Re: Re: Scenarios for change type "deleted"

If someone wants to read that email. I can forward it, it is in Dutch that is why I don't post it here. Next may, 2018, the new European privacy regulations will become effective. Op di 7 nov. 2017 18:15 schreef Bert Verhees <bert.verh...@rosa.nl>: > I just received ab em

Re: Re: Scenarios for change type "deleted"

I just received ab email about this. In Dutch from the Dutch Authority Privacy (Autoriteit Persoonsgegevens ) The DPIA mentions very explicitly right on correction and right on removal. Else the system owner will be fined. It is European law. No room for discussions or ethical considerations.

Re: Scenarios for change type "deleted"

for archiving. I must excuse myself,I am not able to participate more in this discussion this week because I am onholiday Best regards. Bert Op ma 6 nov. 2017 15:40 schreef Bert Verhees <bert.verh...@rosa.nl>: > For the first scenario, changing a care plan, or stopping it, I wouldn't > thin

Re: Scenarios for change type "deleted"

standard is, as far as I know not a facility to do this. In fact the second scenario is, as I see it, from the openehr point of view the same as the third. Bert Op ma 6 nov. 2017 15:11 schreef Thomas Beale <thomas.be...@openehr.org>: > > > On 04/11/2017 18:38, Bert Verhees wrote: >

Re: Scenarios for change type "deleted"

that the data will be maintained for longer time, for example in case of hereditary diseases. Op zo 5 nov. 2017 16:51 schreef Karsten Hilbert <karsten.hilb...@gmx.net>: > On Sun, Nov 05, 2017 at 03:12:20PM +0000, Bert Verhees wrote: > > > In the Netherlands as in many countries, if you c

Re: Scenarios for change type "deleted"

rnance of who can propagate such a deletion. > > Cheers, Sam > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > -- > *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org> >

Re: Scenarios for change type "deleted"

Here is the a description by royal organization of medical institutions of the Dutch law for saving medical data. https://www.knmg.nl/advies-richtlijnen/artseninfolijn/praktijkdilemmas-1/praktijkdilemma/hoe-lang-moet-ik-medische-dossiers-van-patienten-bewaren.htm It was years ago 10 years. It is

Re: Scenarios for change type "deleted"

if a standard should define a "deleted" flag. I think such a flag is a technical flag to organize some way of archiving data. It has no additional semantic meaning and should not belong in a standard defining semantic structures. Op za 4 nov. 2017 21:18 schreef Bert Verhees <bert.ve

Re: Scenarios for change type "deleted"

, and therefor not readable for others, and also not interesting for others I rather take that communication to private level instead of public discussion group level. Best regards Bert Verhees Op za 4 nov. 2017 18:48 schreef GF <gf...@luna.nl>: > Even when the patient wants all data to b

Re: Scenarios for change type "deleted"

uda > the Netherlands > > On 3 Nov 2017, at 13:49, Thomas Beale <thomas.be...@openehr.org> wrote: > > It's potentially not a completely wrong idea: it might be worth thinking > about a 'deleted' marker on the VERSIONED_OBJECT type itself. As i noted > before though, i'd like t

Re: Scenarios for change type "deleted"

bout a 'deleted' marker on the VERSIONED_OBJECT type itself. As i > noted before though, i'd like to get a better idea of real scenarios > where the current model of deletion doesn't work properly before doing > anything. > > - thomas > > > On 03/11/2017 02:36, Bert Verhe

Re: Scenarios for change type "deleted"

I shouldn't write in the middle of the night, while travelling. Of course the deleted status is in the version, not in the composition. Sorry for confusing reply. Have a nice day Bert Op vr 3 nov. 2017 05:36 schreef Bert Verhees <bert.verh...@rosa.nl>: > In a versioned system there is

Re: Scenarios for change type "deleted"

In a versioned system there is no status for "deleted" necessary *inside* a composition. The system itself marks the composition deleted. With this in mind it seems to me the semantical meaning of the inside "deleted" status is meant for something else. Bert Op do 2 nov. 2017 20:01 schreef

Re: Better approach for announcements, forums?

Hi, I wonder if there is any status-change since then? Almost 10 months ago since we had this discussion Bert For me, that is just fine as you describe Op wo 4 jan. 2017 om 15:03 schreef Thomas Beale <thomas.be...@openehr.org>: > > On 04/01/2017 13:53, Bert Verhees wrote:

Re: AOM 1.4 - Archetype.uid a UUID or OID?

-17 15:11, Thomas Beale wrote: On 16/06/2017 21:13, Bert Verhees wrote: UID can also be INTERNET_ID, and the "extension" and double colon are not required, so the HIER_OBJECT_ID cannot represent anything, but it is a lot. Of course it is a matter of taste, maybe there are good

Re: AOM 1.4 - Archetype.uid a UUID or OID?

On 16-06-17 21:12, Thomas Beale wrote: It's not correct to say that HIER_OBJECT_ID can represent anything. It can represent ids that are made of a UID root (either a UUID or OID or domain name or reverse domain name) and a String extension. While the String part could be abused, it isn't in

Re: AOM 1.4 - Archetype.uid a UUID or OID?

change made to an archetype inside a controlled repository (for example, addition or update of meta-data fields), this field should be updated with a new UUID value, generated in the normal way. - thomas On 15/06/2017 23:09, Bert Verhees wrote: Seems that the story is not finished yet. S

Re: AOM 1.4 - Archetype.uid a UUID or OID?

I have a few thoughts, although the question has become less urgent to me, because I can use the HIER_OBJECT_ID to store a UUID. Which is a bit funny, but it is correct following the OpenEHR specs, so I can convince others that it is right. On 16-06-17 01:36, Heath Frankel wrote: No one

Re: AOM 1.4 - Archetype.uid a UUID or OID?

ion*.*lifecycle_state*. > > For every change made to an archetype inside a controlled repository (for > example, addition or update of meta-data fields), this field should be > updated with a new UUID value, generated in the normal way. > - thomas > > > On 15/06/2017 23:09,

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Pazos" <pablo.pa...@cabolabs.com>: > Hi Bert, when using ISO OIDs, UUIDs are not one arc OIDs since they have > to start with a specific arc 1. or 2. > > http://www.oid-info.com/cgi-bin/display?tree= > > On Jun 15, 2017 4:33 AM, "Bert Verhees" <bert.verh...@rosa.nl

Re: AOM 1.4 - Archetype.uid a UUID or OID?

On 15-06-17 12:49, Thomas Beale wrote: On 15/06/2017 02:17, Heath Frankel wrote: Hi Thomas, Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value attribute of type UID, which may be either UUID,

Re: AOM 1.4 - Archetype.uid a UUID or OID?

Although the OID and UUID as used in the archetypes are (in the most simple (one arc) OID-occurrence) technical interchangeable is their semantical meaning completely different. So what do we want to express here? Is it ever used in the way a OID is meant to be used? (to trace back the

Little sync problem in Java-code regarding ResourceItem

Hi, A short notification for there is a small but disturbing problem in Java-lib code, which I was studying for some project purpose. In the code in java-libs is in conflict with the specifications (the specifications are right, also conform the many examples on CKM). It is not a big

Re: A little community coordination

Yes, me too, good idea. Working on project, more details soon Op za 20 mei 2017 10:04 schreef Pablo Pazos : > Great suggestions, will add a comment on that to the form so people can > specify that in free text (trying not to make it too structured). > > On Sat, May 20,

SNOMEDCT - correct representation

Hi, First this, because of some technical issue at my provider, all my emails of yesterday are gone, I am now replying from the mail-archive of OpenEHR. So I can not reply inline. --- I favour the idea of having an explaining-comment-feature for the terminology

Re: SNOMEDCT - correct representation

g can be a few diferent things: * a single concept code * a single code referring to an external value set known in SNOMED * a composition expression that refers to a more refined concept * a constraint expression that locally determines a value set intensionally, to be resolved by app

Re: SNOMEDCT - correct representation

clinical ideas in a language independent interoperable way. I have difficulties to understand the resistance against this. It can take OpenEHR, in my view, to a higher level, without changing much on the standard. Bert - thomas On 16/05/2017 13:08, Bert Verhees wrote: Most creators or users

Re: SNOMEDCT - correct representation

CT+URI+Standard <https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard> Please consider the language used when posting. /Daniel On May 3, 2017 13:03, Bert Verhees <bert.verh...@rosa.nl> <mailto:bert.verh...@rosa.nl> wrote:

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

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

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

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

Re: inheritance of archetypes

ybe it is 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 <bert.verh...@rosa.nl>: > Lots of good things happening. We will see when major shifts will occur. I > keep my fin

Re: inheritance of archetypes

i...@freshehr.com> > twitter: @ianmcnicoll > > [ > https://docs.google.com/uc?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ > ] > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org ian.mcnic...@openehr.org> > Director, fr

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

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

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: 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

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: 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 <thomas.be...@openehr.org>: > > 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 th

<    1   2   3   4   5   6   7   8   9   >