Re: Archetype publication question - implications for implementers [ long ]

Eric, nice summary of issues. If I can take the liberty of pulling out what I think are your key issues to worry about + recommendations. I bolded my own subset of those ... On 10/10/2015 10:07, Eric Browne wrote: *Notes on UCUM* * UCUM does not supply normative names of units. * Some

OS licences - CC-BY-SA 4 compatible with GPLv3

Announced here officially - http://creativecommons.org/compatiblelicenses ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

New adl-antlr GitHub project

above link if you are interested in using this resource, or participating in the development. - thomas -- *Thomas Beale* Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org> Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics

Re: SNOMED CT constraint syntax - for querying instances or terminology?

Hi Michael, in that case, to what information base or DB could the amoxycillin query be applied? What is it for? thanks - thomas On 29/09/2015 23:19, michael.law...@csiro.au wrote: Hi Thomas, These constraints are essentially queries over the snomed definitional content (ie the

Re: SNOMED CT constraint syntax - for querying instances or terminology?

On 30/09/2015 07:51, michael.law...@csiro.au wrote: Imagine instead the example was using the corresponding AMT concepts (since snomed pure doesn't have any concrete domain modelling -- I.e. numeric values). Then the focus concept would be the AMT amoxycillin Medicinal Product concept

SNOMED CT constraint syntax - for querying instances or terminology?

The latest version of the SNOMED CT constraint language proposes expressions like the following: Section 6.3 To find those capsules that have a strength between 500 and 800 mg (inclusive), the following expression constraint may be used: <

Re: openEHR and IHTSDO (SNOMED CT)

A number of approaches have been made in the recent past by openEHR and CIMI, led by Dr stan Huff. The outcome is that IHTSDO do not appear to be currently interested in a formal working relationship with the content modelling communities (openEHR, Intermountain Healthcare, CIMI, ISO 13606,

Re: Advantage of ISO

, copyrighted to the foundation and will always be free to use under all circumstances, as has always been the case for 15 years. This will never change. - thomas On 09/09/2015 17:24, Bert Verhees wrote: On 09-09-15 04:20, Thomas Beale wrote: On 08/09/2015 21:55, Erik Sundvall wrote: Hi! ND

Re: Advantage of ISO

9/2015 18:09, Bert Verhees wrote: On 09-09-15 09:55, Thomas Beale wrote: Bert, my comments relate to software only, contributed by companies and other organisations at their own development expense. It has nothing to do with specifications, nor specification-related computational artefac

Re: Advantage of ISO

On 08/09/2015 21:55, Erik Sundvall wrote: Hi! ND on the specification documents is not a big or urgent problem if there are Apace 2 licenced computable artifacts like UML-files/descriptions of all classes, ADL/AQL grammars, openEHR term lists/vocabularies and other things needed for building

Re: Advantage of ISO

ND = No Derivatives and is the Creative Commons equivalent of what W3C has in their licence . It's just designed to prevent anyone republishing altered versions of the specifications /as the original specifications /- in other words forked

Re: Advantage of ISO

Gerard, the 'IP rights' are defined by the licences. You can read them here . The rights to use, copy and adapt are clearly defined, and include no curbs on freedom, and no requirement for payment. The only real requirement is that

Re: Advantage of ISO

Gerard, I am not sure why you are pursuing this line of argument. The only interesting question here is not about any 'owner', but about the 'credible maintainer'. For openly and freely licenced IP, this is all that practically matters - the capabilities and behaviours of the maintainer

Re: ACTION performer?

Can I suggest that a PR is raised for this ? - thomas On 27/08/2015 21:40, Ian McNicoll wrote: Hi Silje, I agree that ACTION.performer would be a useful addition (optional) to the RM. For now, I model

Re: Archetype versioning: Skipping v1 and going straight to v2?

Hi Silje, I would not expect any problems. - thomas On 28/08/2015 23:05, Bakke, Silje Ljosland wrote: Hi everyone, We’ve bumped into an issue related to versioning of archetypes and implementing non-published versions: Several implementation projects are using archetypes from the

Re: difference and relationship between openEHR and EN13606

Hi Bert, On 28/08/2015 16:32, Bert Verhees wrote: On 27-08-15 19:54, Thomas Beale wrote: I would suggest that CIMI has been simiplified to the point of not being directly usable as an RM by openEHR or 13606 - most of the needed context information is gone in CIMI, and it doesn't distinguish

Re: difference and relationship between openEHR and EN13606

On 26/08/2015 13:08, Bert Verhees wrote: On 26-08-15 14:03, Diego Boscá wrote: I agree with most of the points, but I'm curious why you say that 13606 does not support AQL (and in any case wouldn't be AQL does not support 13606?) Yes, that is a good question, I did not know that AQL was

Re: ACTION performer?

On 27/08/2015 10:18, Bakke, Silje Ljosland wrote: So it’s possible to specify the role of each participant? yep - the PARTICIPATION type has 'function' i.e. 'role' (this name was adopted from 13606 a long time ago - probably too late to change). - thomas

Re: difference and relationship between openEHR and EN13606

On 26/08/2015 16:46, Erik Sundvall wrote: Hi! Where can one find proposals/diagrams describing the refreshed RM (reference model) in the new 13606 revision? Will 13606 keep using the old data types or harmonize more with CIMI or OpenEHR? Is there now consensus/majority regarding using

Re: difference and relationship between openEHR and EN13606

openEHR has an EHR Extract specification http://www.openehr.org/releases/RM/latest/ehr_extract.htmlas well, which is more flexible than the 13606 one e.g. it can include information from more than one patient, and accommodates both openEHR and non-openEHR content. - thomas On 26/08/2015

Re: difference and relationship between openEHR and EN13606

On 28/08/2015 10:03, 王海生 wrote: could we just add a page on openEHR website to illustrate these points thx if you search on the wiki https://openehr.atlassian.net/wiki/dosearchsite.action?queryString=13606, with either '13606' or 'CIMI' you will find a lot of material. - thomas

Re: ACTION performer?

Normally you would use participations. Sent from my HTC - Reply message - From: Bakke, Silje Ljosland silje.ljosland.ba...@nasjonalikt.no To: openehr-technical@lists.openehr.org openehr-technical@lists.openehr.org Subject: ACTION performer? Date: Thu, Aug 27, 2015 10:00 Hi all,

Re: AQL ANTLR4-grammar

Antlr4 rule capabilities and particularly pattern matcing is weaker than yacc/lex (in some cases quite a lot weaker), but it's more concise for the production rules, and as you say, it works for any output side. So that's a big win. Over time, I expect we'll cnvert everything to Antlr4. On

Re: AQL ANTLR4-grammar

/aanastasiou/adl_ebnf I hope this helps, had a quick look at the MedInfo stuff and it looks really exciting! All the best Athanasios Anastasiou From: openEHR-technical [openehr-technical-boun...@lists.openehr.org] on behalf of Thomas Beale [thomas.be

Re: AQL ANTLR4-grammar

On 24/08/2015 11:38, Bert Verhees wrote: On 24-08-15 15:36, Thomas Beale wrote: Antlr4 rule capabilities and particularly pattern matching is weaker than yacc/lex (in some cases quite a lot weaker), Of course, Yacc/lex can only be used to generate C-code. It's functionality in pattern matching

latest updates to AD2 / AOM2 specifications

I am finalising the ADL/AOM2 specifications, mainly updating text, and incorporating content from older separate documents. It's not finished yet, but sections that may interest some people: * templates and template overlays

Re: ADL versions 1.4, 1.5 and 2.0

/trunk/architecture/am/adl2.pdf ? Regards Dave Barnet Health and Social Care Information Centre NHS England, UK -- Ocean Informatics http://www.oceaninformatics.com *Thomas Beale Chief Technology Officer* +44 7792 403 613 Specification Program, /open/EHR http://www.openehr.org/ Honorary

Re: Term set for DV_PARSABLE.formalism

Hi Pablo, in openEHR, a terminology id of 'local' normally refers to terms inside an archetype; each archetype is its own terminology. This makes sense for clinical terms in an archetype, but not, I don't think, for terms to do with data formats. We can easily add these to the openEHR

Re: Term set for DV_PARSABLE.formalism

On 28/07/2015 18:49, pablo pazos wrote: If that's the case, we lose the coding system / terminology of the mime types that are defined. It would be better to make DV_PARSABLE.formalism of type CODE_PHRASE instead of String and use local for the terminology_id of those formalisms that doesn't

Re: Archetype editor, CKM and v0 v1

Technically speaking, if we want to properly match any archetype in a slot, we need a regex that will match any level of versioning id. Since matched archetypes will eventually all have 3-part versions (but today might have only 1-part versions), we need to match thngs like .v0 .v1 .v0.0.1

Re: Archetype editor, CKM and v0 v1

openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Ocean Informatics http://www.oceaninformatics.com/ *Thomas Beale Chief Technology Officer* +44 7792 403 613 Specification Program, /open/EHR http://www.openehr.org/ Honorary

Re: VERSION.lifecycle_state options

On 09/07/2015 12:53, Erik Sundvall wrote: Hi! Is a new type of VERSION.lifecycle_state the best to solve the described use-case? Won't the correcting a typo change or we forgot a thing use-cases etc still always be there even for things written as binding contracts? Is it perhaps enough to

Re: VERSION.lifecycle_state options

Sebastian, I think this is about right. I think 'immutable' in law and 'immutable' in information systems have to be understood as different things. The law is always local, so I think the best that could be done is a standard kind of attestation whose reason for change was something like

Re: openEHR specifications - the future is Asciidoctor + MagicDraw?

Athanasios, excellent suggestion. I haven't even looked at building in syntax diagrams right now, but your timing is perfect - I was contemplating how to put the ADL grammar into the new style spec in a nice way. Currently grammar is generated as an HTML page (as per links on this wiki page

openEHR specifications - the future is Asciidoctor + MagicDraw?

Back at the September 2014 roadmap meeting *we agreed to move from the current specifications documentation *in FrameMaker to a modern tool, preferably text-based. This wiki page https://openehr.atlassian.net/wiki/display/spec/openEHR+Specifications+tooling shows various alternatives under

Re: Updated Vim mode for ADL syntax

repair in terminal, I hope you get it distributed with vim, as some other programming languages, like C, are supported default. Regards Bert Op 23 jun. 2015 18:46 schreef Thomas Beale thomas.be...@oceaninformatics.com mailto:thomas.be...@oceaninformatics.com: I have uploaded new vim syntax

Updated Vim mode for ADL syntax

I have uploaded new vim syntax colourising files https://openehr.atlassian.net/wiki/display/dev/ADL+Text+Editors, for those who use vim. I have included a dark blue background custom colour scheme as well. Have a look at the screen shots - I have tried to be somewhat scientific about the

openEHR@ StackExchange - update

To succeed with openehr.StackExchange.com, the committers phase needs 200 total. We particularly *need people who want to ask questions* to commit (do it here http://area51.stackexchange.com/proposals/87508/openehr). Secondly, 50% of those committers need 200+ reputation on any other

nearly there - openEHR @ StackExchange - 2 questions to go

If anyone has any votes left (each user has 5), here is what to do: * login to the openEHR Area51 StackExchange page http://area51.stackexchange.com/proposals/87508/openehr * find the two questions with 10 votes (currently on 6 and 8) - near the bottom of the page - and UPVOTE them *

openEHR @ StackExchange - phase 2 - commitment

We did it... but did I mention that it's only phase 1? Those of you who looked carefully will have realised that getting your own stackexchange area isn't easy http://area51.stackexchange.com/. But - let's see how we go. We are now in the 'commit' phase, which means gathering enough people

Re: openEHR @ StackExchange - getting close

On 12/06/2015 16:50, Diego Boscá wrote: I think it could be also interesting to answer the questions we know the answer for, to show there are also experts and discussion out there ;D I have not figured out whether that's what they want or not - but if we assume that the 'example' questions

Re: openEHR @ StackExchange - getting close

On 12/06/2015 16:50, Diego Boscá wrote: I think it could be also interesting to answer the questions we know the answer for, to show there are also experts and discussion out there ;D If you look at 'hardware-recommendations', another new StackExchange area in the 'Commitment' phase (openEHR

Re: VERSION.lifecycle_state options

I suspect that the idea of 'final' requires something more like a 'locked for modification' flag. But nothing is guaranteed to be immutable - what if the consent was given, and the committed information was considered clinically 'final' but then a simple typo error (e.g. patient name, or the

Re: openEHR @ StackExchange - getting close

We are getting closer http://area51.stackexchange.com/proposals/87508/openehrto the next step. We have 76 followers. We still need 17 questions with 10 votes. We have the requisite number of questions, it's just a case of people using their votes on them (don't worry if they don't really

Re: VERSION.lifecycle_state options

I think we need a clear definition of the difference between 'complete' and 'final'... On 10/06/2015 15:59, Sebastian Iancu wrote: :) final is final! Even though consent was given on wrong data... I guess if needed on application level it can be overruled under some special conditions

Re: openEHR @ StackExchange - progress

Yes - please don't vote higher than 10. These questions are 'example' questions - this is the community testing phase of StackExchange. I'm not sure if the questions get trashed later on or not, but we have to assume for now that they are used solely for gauging community size and interest.

openEHR @ StackExchange

On 25/05/2015 11:00, Diego Boscá wrote: Agree with both. Probably we should go review the mailing lists to identify which kind of questions are usually asked by newcomers. Also, we should use stackoverflow more, with dedicated tags to openEHR. I created a new site proposal for openEHR on

Re: openEHR @ StackExchange

On 25/05/2015 12:16, Diego Boscá wrote: I would assume it can be both: a question could be just about specs (just the openEHR tag) or about any specific implementation (e.g. openEHR and java) yep - that's how I think it would work. - thomas ___

Re: Template Designer - remove slot

On 04/05/2015 16:11, pablo pazos wrote: Awesome, I'll add this to the TD JIRA. Do anyone remember where that JIRA is? -- Here is a new tracker for the TD https://openehr.atlassian.net/browse/TDPR/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel - please add it here. -

AOM Translation details - can we have a concrete proposal?

As we process outstanding PRs, I discovered an old one from Sebastian Garde - SPECPR-24, that initially reports the need for better translation meta-data. Silje started a thread on more recent requirements here to which some of us replied. Could we have a concrete proposal - maybe a

Re: Have your say on existing Problem Reports

Note that you can vote on these PRs as well, according to what you think is most important to be fixed. - thomas On 09/05/2015 15:10, Thomas Beale wrote: All, there are 114 Problem Reports (PRs) being processed by the Specifications Editorial Committee (SEC) right now, here on the SPECPR

Have your say on existing Problem Reports

to convert these to Change Requests (CRs) that will be the basis of the next few releases of openEHR. If you want to make comments or review any of these PRs (or even raise new ones, but please make sure, no duplicates!) then feel free to visit the SPECPR tracker and do so. thanks - thomas

Technical and clinical lists now have searchable archive.

We have uploaded the technical and clinical list archives to mail-archive.com, which is a web-searchable interface to the lists. Technical list here https://www.mail-archive.com/openehr-technical@lists.openehr.org/ Clinical list here

Licensing of specs and artifacts

is as follows. archetype (adl_version=2.0.5; rm_release=1.0.2; generated) openehr-test_pkg-WHOLE.full_meta_data.v0.0.1 language original_language = [ISO_639-1::en] description original_author = [name] = Thomas Beale thomas.beale at oceaninformatics.com [organisation

Specifications program roadmap - have your say

comments will be read by the SEC, and incorporated into the roadmap (i.e. the CRs that result from the analysis we are doing). please report any problems with access, logging in etc to admin at openehr.org mailto:admin at openehr.org - thomas beale (Specifications Program) -- next part

OpenEHR and Oracle XML DB problems

Indeed, it would be a great thing. The reason it doesn't exist so far, is that to be useful we need synthesised data sets that have some realistic statistical spread of values. Since we are talking at multiple levels - not just vital signs measurements, but covariance of all kinds of

AOM2 initial working XSDs and example validating XML output.

I have been working with the AML (Archetype Modelling Language) team recently, and as a result have produced a set of XSDs for AOM2. These can be found here https://github.com/openEHR/specifications/tree/master/ITS/AOM2/XML-schemain Github. Notes: * it's initial work, very unlikely not to

ADL 2 Workbench update - alpha of next release available

On 03/02/2015 15:17, pablo pazos wrote: Hi Thomas, Does it have ADL 1.5 / 2 editing capabilities? partial. You can create a new archetype, template, specialised archetype by right-click on the appropriate node in the explorer of the library you are in. You can then either a) use the ADL

ADL 2 update - XML generation

For those interested, I have added a new version of the XML OPT https://openehr.atlassian.net/wiki/display/ADL/ADL+2+Operational+Template for the demonstration template. This converts more of that AOM class properties to XML attributes, reducing size a bit, and arguably improving

ADL 2 update - XML generation

, may the archetype workbench? On Wed, Jan 28, 2015 at 10:52 AM, Thomas Beale thomas.beale at oceaninformatics.com mailto:thomas.beale at oceaninformatics.com wrote: For those interested, I have added a new version of the XML OPT https://openehr.atlassian.net/wiki/display/ADL/ADL

C-CDA was created because they do not know openEHR? :)

On 20/01/2015 02:19, pablo pazos wrote: Just for the sake of discussion, See slides 22 and 23: http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertification.pdf As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple approaches for documenting template

openEHR-technical Digest, Vol 35, Issue 33

HI William, I know for a fact that archetype-based CDAs do/did exist, because Ocean built them for Nehta (not many though, it's not that easy to do it). However, Nehta is notoriously sensitive with IP, and may well have refused them to be made public. I have also seen some other technical

Does anyone implemented a transformation between AQL and XML?

Hi Pablo, I see Seref has provided some technical input. Just a note on what AQL is for, and why it is a language with a parser etc. The goal is to have queries that rely only on archetypes, and that can be shared across systems and vendors, enabling CDS and other second level processing

CRUD Restlet

On 19/01/2015 10:29, Diego Bosc? wrote: I will just add that if you are making a server you probably want to take a look and how FHIR does things. They have some pretty cool ideas for common problems that you can probably reuse (e.g. using atom for query responses) Diego, I think they are

CRUD Restlet

http://www.oceaninformatics.com/*Thomas Beale Chief Technology Officer* +44 7792 403 613Specification Program, /open/EHR http://www.openehr.org/ Honorary Research Fellow, UCL http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS http://www.bcs.org.uk/ Health IT blog http

AQL with Demographics

On 15/01/2015 09:28, Alessandro Torrisi wrote: Hello, did any off you thought about how a query should look like suppose I want such like this : Give me all *female* patients living in *Paris *and with *no allergies* and a *the last labresult of type Kreatine is 20 but within a year*

Faster ADL Workbench available

For those of you feeling the need for speed, there is a new build available on this page http://www.openehr.org/downloads/ADLworkbench/home that greatly speeds it up. This version reduces the error output a fair bit, and you are recommended to go to Tools Options Compiler Settings and set

Problem-oriented records and querying by problem

On 28/11/2014 04:17, Koray Atalag wrote: Hi Karsten, I agree about episodicity not being particularly an issue with problem orientation. Re randomness I couldn't find the best expression I guess...What I was referring to is the fact that the information captured by today's systems can be

Problem-oriented records and querying by problem

Hi Karsten, firstly, I am not offering the Care Plan means of extensionally identifying problems as a bullet-proof method; it's just a working theory at this stage. For the above: wouldn't this patient normally have a diabetic care plan, and for surgery that is not diabetic related, then

Problem-oriented records and querying by problem

On 20/11/2014 12:45, Karsten Hilbert wrote: In the other hand, yes, that information is in every MR, but you have to read a lot to find all the info relevant to a specific problem. What we need to do is to have that information linked in an explicit way to avoid that manual search, and have

Problem-oriented records and querying by problem

On 18/11/2014 03:34, pablo pazos wrote: Hi all, just re-sending this question on the clinical list too. I'm wondering how to handle the link between documents and health problems in a problem-oriented record. I think the future will be that a Care Plan informational construct (note: for

archetype UIDs

On 18/11/2014 12:50, David Moner wrote: Hi, I was not aware of this addition. It is clear that having these UIDs it will be simpler to check if the archetype has changed, as you say. But is it also the intention of these UIDs to be used to fill the archetype_id attributes in the RM

Postulate: DV_QUANTITY should be modelled with fewest possible units

On 17/11/2014 12:47, Ian McNicoll wrote: Hi Thomas, RM function to retrieve a magnitude expressed as a particular unit. from my previous email ... I think we could add something at reference model level to say give me this quantity in 'x' units, performing the conversion at server level

openEHR-technical Digest, Vol 33, Issue 23

On 15/11/2014 10:17, Gerard Freriks wrote: I prefer to deal in the Reference Model with the documentation and archiving aspects. Any Composition needs to be signed, irrespective of the content. And that signing on occasion is by multiple persons, in different roles. When specific parts of

Postulate: DV_QUANTITY should be modelled with fewest possible units

On 14/11/2014 08:42, Bj?rn N?ss wrote: I have been thinking about profiling. I am not sure if this fix the problem regarding complexity. This may be an governance thing. If we define a metric and british imperial profile we may define that in Norway every application MUST use the metric

Postulate: DV_QUANTITY should be modelled with fewest possible units

On 14/11/2014 00:57, Ian McNicoll wrote: Hi Pablo, I would agree, this information is also carried in the Archetype Editor property files, although I suspect not as well maintained as the UCUM file. @Thomas - the profile suggestion is interesting but it feels to me that it adds level of

Archetypes - new meta-data elements for 3rd party copyrights?

Hi David, licence is taken care of in the model as it is today http://www.openehr.org/wiki/download/attachments/45645905/AOM_archetype_package.png?version=2modificationDate=1412032298000api=v2. Note that it is currently spelt in international English, not US English ('license', which is only

Archetypes - new meta-data elements for 3rd party copyrights?

On 13/11/2014 10:02, Heather Leslie wrote: I've had discussions with IHTSDO about needing a formal statement about SCT that should be placed in archetypes and this will be identical to that which they are currently working on with CIMI. Regards Heather The main thing we need to do with

openEHR Confluence and Jira - Atlassian on Demand is available to us

site. Unless there are strong objections from anyone in the community, I think we will go ahead with this change. If anyone does have objections, or sees a problem with the move, please post on the technical or clinical lists. thanks - thomas beale -- next part

Another meta-data requirement from CIMI

On 13/11/2014 16:50, David Moner wrote: As you say, this information should be somehow related to the is_generated flag. But if we consider that once a human user reviews the archetype that flag is set to false, then I don't find it needed at all. ah - but consider the situation in which

ADL 1.4 migration roadmap - a start

I have started an ADL 1.4 migration roadmap page http://www.openehr.org/wiki/display/ADL/ADL+1.4+Migration+Roadmap. This currently consists of a list of all changes made from 1.4 = 2.0 (as it now is), with an idea of which retrospective interim version (i.e. 1.5, 1.6, 1.7 etc) the change

Doctor specialty in the IM

Hi Pablo, the first is as good as any. Normally PARTICIPATION.function is intended to capture the function of the physician in the activity, which could be general or specific. It might not be the same as the specialty of the doc, especially if that specialsiation is not implicated in this

Any prep for MIE 2015 in Madrid?

On 31/10/2014 07:54, Luis Marco wrote: Hi Koray, I certainly will be in MIE 2015 presenting a paper but to my knowledge there is no OpenEHR official event planned. Regards, Luis well we need to plan further openEHR working meetings, so, it's not unlikely one will be planned for then, and

Defining multiple constraint bindings in AOM/ADL 1.4

Hi David, well the very direct answer is: ADL 1.4 is ... a bit limited;-) your last example section: constraint_bindings = [BI98] = items = [ac0001] = terminology:BI98?code= [ac0001] = terminology:BI98?code= would not even be allowed in ADL 2. Now,

Error in ADL workbench

On 28/10/2014 08:39, Birger Haarbrandt wrote: Hi there, just for the case it won't get broad attention in the issue tracker (It seems to be the first time an issue got submitted :): I got some trouble with the most recent version of the ADL workbench. Has anyone else faced this issue?

MedInfo 2015 openEHR tutorials

On 24/10/2014 19:17, Bert Verhees wrote: OpenEHR is not a standard, it is a formal specification. http://www.iso.org/iso/home/standards.htm ISO, What is a standard: A standard is a document that provides requirements, specifications, guidelines or characteristics that can be used

MedInfo 2015 openEHR tutorials

___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Ocean Informatics http://www.oceaninformatics.com/*Thomas Beale Chief Technology Officer* +44 7792 403 613

Archetype Naming proposals - do we need V0?

On 03/10/2014 22:08, Bert Verhees wrote: On 03-10-14 22:28, Thomas Beale wrote: Filename is irrelevant, and has been freely choosable for 5-10 years in all archetype modelling tools that I know of. Except from CKM, it offers, when I click Export Archetype (ADL) a file named after

Archetype Naming proposals - do we need V0?

Note that in AOM 1.5 (to be renamed AOM2) spec http://www.openehr.org/releases/trunk/architecture/am/aom1.5.pdf, the idea of fixed string 'ids' is gone. Multi-part ids are now generated functionally. See Fig 8 Right now, the functions interface_id and physical_id are defined a certain

Archetype Naming proposals - do we need V0?

On 03/10/2014 14:32, Bert Verhees wrote: Thanks for getting involved in this important discussion. I am on a plane and don't have ooportunity for a full answer but it is not as simple as u have suggested. Amongst other things You have to consider what happens to archetype numbering when

Archetype Naming proposals - do we need V0?

On 03/10/2014 16:40, Ian McNicoll wrote: When this published v1 archetype needs to go back into review it gets labelled as org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.1-unstable+build.e34dgtj67856 or using the uid - 123rhturytu55634567.v.1.0.1-unstable+build.e34dgtj67856 Probably a

Archetype Naming proposals - do we need V0?

On 03/10/2014 19:54, Bert Verhees wrote: The best solution is to decouple the version from the archetypeId. And also decouple the file and filename from the archetypeId. People are responsible for overwriting their documents in Word, or save a backup, if that is their choice. The same can

Archetype Naming proposals - do we need V0?

On 01/10/2014 16:44, Sebastian Garde wrote: Hi Sebastian, I realise you are physically not too far away from me in Germany and we even share the same name, so I hope you won't shoot the messenger here, but I have to say the following... The consequence of what you are saying would be that

Licensing of specs and artifacts

At the end of the day, I don't really care what licence is used for these things in openEHR - maybe the community should just vote. The long debates from the past are summarised here http://www.openehr.org/wiki/display/oecom/Archetype+licensing+-+the+case+for+CC-BY-SA and here

Archetype Naming proposals - do we need V0?

On 01/10/2014 11:23, Ian McNicoll wrote: In that sense v0.0.0 and v1.0.0-unstable are identical in terms of their 'stability' and lack of commitment to the versioning rules. Hi Ian, I don't think this is true. Firstly, the standard first possible version is v0.0.1 in any versioning

Archetypes vs. Templates, archetype version in slots

On 30/09/2014 22:33, Ian McNicoll wrote: Hi Diego, I understand your point but I am not sure that slot naming is really working out as any of us envisaged. In the vast majority of cases where we specify an archetype pattern in the slot description we also leave the constraint open-ended

Archetype Naming proposals - do we need V0?

On 01/10/2014 13:31, Sebastian Garde wrote: It seems to me a no-brainer that we should support v0, because it's the clearest possible sign I can think of, that everyone already recognises, that indicates an artefact to be in early chaotic/uncontrolled development. So v0 should be the

Archetypes vs. Templates, archetype version in slots

Diego, your general argument is potentially right, at least in some circumstances. But don't forget, a v2 archetype is a breaking change with respect to v1. With full versioning, it's like with software - v2.0.4 compared to say v1.1.0. Where there is a breaking change, it's a new archetype.

Archetypes vs. Templates, archetype version in slots

Diego, You are right that it's not easy to do with regex lexical referencing. That's why there is a proposal to use semantic referencing http://www.openehr.org/wiki/display/ADL/Semantic+slot+proposal, which would define slot fillers of an archetype in the following way:

[openEHR-announce] roadmap 2014 meeting streaming

Hi Bert, DIPS, who provided the meeting venue and catering had to change the location a few days earlier to one outside of their offices, in a town called Lillestrom, near Oslo. So we were in a culture centre with its own wifi etc, not under DIPS control, and the best we could manage

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