Paths in archetyped data

Something IMPORTANT I have said before, and completely forgot due to other distractions: There is a proposal (it's on the SPECPR issue tracker somewhere) to add a property to the LOCATABLE class called (say) sibling_id: INTEGER which would have the effect of unambiguously numbering sibings und

Paths in archetyped data

On 22/11/2013 09:44, Thomas Beale wrote: > > Something IMPORTANT I have said before, and completely forgot due to > other distractions: 'should' have said before! > > There is a proposal (it's on the SPECPR issue tracker somewhere) to > add a property t

Paths in archetyped data

On 22/11/2013 10:18, Bert Verhees wrote: > On 11/22/2013 10:44 AM, Thomas Beale wrote: >> as ADL short hand for >> >> cluster[@archetype_node_id='at0009']/items[@archetype_node_id='at0008', >> @sibling_id='2'] > > > I am not su

archetype node_ids again - looking for final solution

I spent a bit of time trawling back through that last discussion on C_OBJECT.node_id (the property that carries at-codes) and whether it should be mandatory or optional, and also whether empty is valid. Currently it is mandatory, and can't be empty. We need to make the spec work for 2 distinct

Instruction archetypes and overlaping nodes with INSTRUCTION.narrative

d narrative anyway? (Even though the >> narrative is mandatory by the IM) >> >> Thanks! >> >> -- >> Kind regards, >> Eng. Pablo Pazos Guti?rrez >> http://cabolabs.com >> >> ___ >> ope

Instruction archetypes and overlaping nodes with INSTRUCTION.narrative

nsistency is detected, which one is supposed to be right? > > > 2013/10/29 Thomas Beale <mailto:thomas.beale at oceaninformatics.com>> > > > Just to re-iterate, the 'narrative' property is meant to carry the > piece of text that would appear

Instruction archetypes and overlaping nodes with INSTRUCTION.narrative

Indeed. We were very wary of this CDA style duplication, which from my point of view is pretty ambiguous if not downright problematic . However, unless we develop some new formal relationship between the text and the structured

Instruction archetypes and overlaping nodes with INSTRUCTION.narrative

On 29/10/2013 16:28, Dr Ed Hammond, Ph.D. wrote: > > As a point of interest, the "required" narrative section in CCD was an > interim step because we (US) still have a number of sites that cannot > accommodate structured data. In my opinion it does not imply correctness. > Ed, I suggested some

Polishing node identifier (at-codes) use cases.

On 02/09/2013 07:19, David Moner wrote: > > > > 2013/8/30 Thomas Beale <mailto:thomas.beale at oceaninformatics.com>> > > > You are probably right. I think for the moment I would like to get > ADL/AOM 1.5 completed (more or less) with the current assumpt

Polishing node identifier (at-codes) use cases.

On 02/09/2013 08:49, David Moner wrote: > > > > 2013/9/2 Thomas Beale <mailto:thomas.beale at oceaninformatics.com>> > >> >> Well, LinkEHR is a real implementation in use by several >> organizations, and we think these identifiers are needed bo

openEHR and Data Warehousing

people of Ocean Software didn't respond yet. The Template Designer is free to use these days. It will be open sourced soon (when we get around to cleaning up the code a bit). The usual build server is not available right now, so we have added a download link on the openEHR website modell

date-time pattern

On 02/09/2013 13:55, Bert Verhees wrote: > I have received a few archetypes created with the LinkEHR editor. > > In there is a dateTime pattern like this: > time existence matches {1..1} matches {-??-??T??:??:??} it shouldn't be a legal pattern - at least year has to be specified. if you real

concerning adl-parser

ITY > is removed > -- > I don't know if it is wished that both issues which are repaired this > way will be posted in the according repository. > If so, I can post the change. > > If not, it works for me. > > Thanks > Bert > > > _

concerning adl-parser

On 02/09/2013 20:28, Bert Verhees wrote: > Op 02-09-13 16:54, Thomas Beale schreef: >> you might want to consider posting these issues on the Java list, >> you'll probably get more answers there... not everyone bothers to >> read all messages on this list if they a

State transitions - ACTIVITY/ACTION

On 10/09/2013 09:38, Bj?rn N?ss wrote: > > Hi all. > > We are discussing some details with the INSTRUCTION STATE MACINE. I > will go directly to my two questions: > > 1 > > The state machine define transition from all not-terminated states to > a terminated state. Except from POSTPONED state. The

AOM 1.5 update published

e all been implemented and validated in the ADL Workbench, which will be released in a new beta in the next week or so. The Java implementation group at Marand are working on upgrading the Java ADL compiler to the same models. Any questions, complaints, wish list, etc, as usual - please

Polishing node identifier (at-codes) use cases.

On 20/09/2013 12:01, Diego Bosc? wrote: > By the way, I just found out that archetype_node_id from locatable > class from the reference model (common_im document, page 22) is > obligatory (!!!). > > The meaning of the attribute is as follows: > "Design-time archetype id of this node taken from it

Polishing node identifier (at-codes) use cases.

On 20/09/2013 20:40, Bert Verhees wrote: > Op 20-9-2013 17:01, Thomas Beale schreef: >> it's simpler than you think - we made that property mandatory so that >> programmers would never get a null exception. > Must have been along time ago, nowerdays, programmers have no pro

Polishing node identifier (at-codes) use cases.

On 23/09/2013 11:47, Bert Verhees wrote: > On 09/23/2013 10:38 AM, Thomas Beale wrote: >> On 20/09/2013 20:40, Bert Verhees wrote: >>> Op 20-9-2013 17:01, Thomas Beale schreef: >>>> it's simpler than you think - we made that property mandatory so >>&

Rich text format in DV_TEXT

I would advise against putting markup directly in DV_TEXT.value - that will surely led to non-interoperable data. I would suggest using DV_PARSABLE, with the XML or HTML you want. However the problem here is that the parent clinical_synopsis archetype on CKM has this definition:

Polishing node identifier (at-codes) use cases.

On 24/09/2013 00:10, Bert Verhees wrote: > >> >> For that reason I believe specifications should very carefully >> specify things. I'll give a very simple example. The openEHR >> specifications routinely specify which properties of a class are >> mandatory, optional, and which String fields have

Polishing node identifier (at-codes) use cases.

On 25/09/2013 00:53, Bert Verhees wrote: > >> sure - if you have a separate property to store the archetype id, it >> is empty in 95% of all object instances, and also you need a class >> invariant to prevent it being filled at the same time as the >> archetype_node_id (at-code) property. > > I

Polishing node identifier (at-codes) use cases.

On 23/09/2013 11:57, Diego Bosc? wrote: > How does this 'unknown' value relate to the discussions we already had > regarding the need of having all at codes present in the ontology? it's a fake node id value I use in the ADL workbench compiler, just to guarantee the non-void non-empty requir

Polishing node identifier (at-codes) use cases.

On 25/09/2013 23:20, Bert Verhees wrote: > Op 25-9-2013 22:47, Thomas Beale schreef: >> On 25/09/2013 00:53, Bert Verhees wrote: >>> >>>> sure - if you have a separate property to store the archetype id, >>>> it is empty in 95% of all object instances, an

Polishing node identifier (at-codes) use cases.

;]/. > > The software would know in one step what to do to build its dynamic > GUI. It would see in one step that there is another > archetype/ontology-section involved, and it would know in the same > step which archetypeNodeId to look for. > > It seems to me that th

Alignment of languages and translations in templates (was: Invalid language codes in languages codeset)

On 02/04/2014 15:13, Gerard Freriks wrote: > imo > > 1- Slots need to 'point at' archetypes by Name of the Archetype and > NOT the file name. Plus something else ... Gerard, this has always been the case. I hope no-one is implementing anything to do with filenames! > 2- All Nodes in any archet

ADL 1.5 single-file templates proposal

There is a new page here that describes a proposal for ADL 1.5 single file templates. Note that other useful rsources are on the ADL/AOM 1.5 parent page

ADL 1.5 ANTLR definitions...and a few questions.

Athanasios, I have been re-organising the resource pages somewhat - I have put your information below on the ADL parser resources page - feel free to rewrite & keep up to date. - thomas -- next part --

ADL 1.5 ANTLR definitions...and a few questions.

On 03/04/2014 09:21, Athanasios Anastasiou wrote: > > > POINTS OF NOTICE REGARDING ADL 1.5: > > 1) Are there any ADL 1.5-specific files available out there for testing > purposes? Hopefully the starting point for all resources is now here

ADL Workbench on Linux amd64

Tim, thanks. It's up - see here . - thomas On 08/08/2014 16:55, Timothy W. Cook wrote: > If you are attempting to run the ADL Workbench on 64 bit systems with > MultiArch support you will need to setup support for the 32

Small question about commits and AUDIT_DETAILS.system_id

Hi Pablo, the original idea is that it is an id more like "emr1.my_domain.uy" - i.e. an actual host domain, so if the data are copied or moved elsewhere, the receiver knows the original EMR system that the data were created on. - thomas On 20/08/2014 17:25, pablo pazos wrote: > Hi, > > I'm r

Small question about commits and AUDIT_DETAILS.system_id

Heath, this is correct, you were not wrong for 10 y ;-) We don't record the name or type or id of the application, and I am not sure even now if that would be of any use. I can't see that it would be. The system_id is for exactly the purpose that Heath as explained here. - thomas On 21/08/2

Faster ADL Workbench available

For those of you feeling the need for speed, there is a new build available on this page 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 s

Faster ADL Workbench available

Another 20% faster, see 'latest builds' here . - thomas -- next part -- An HTML attachment was scrubbed... URL:

CIMI archetype examples using latest openEHR AOM & ADL

For those of you following CIMI, there is now a dedicated CIMI space on the openEHR wiki. This page summarises some recent developments on the question of 'pan

CIMI archetype examples using latest openEHR AOM & ADL

Hi Pablo, I don't personally particularly agree with this approach either. There are two other approaches that could be used: the COMPOSITION / SECTION / multiple ENTRYs approach, and the CLUSTER-per-analyte approach (an earlier suggestion of Ian's and mine). I am going to build these models

CIMI archetype examples using latest openEHR AOM & ADL

On 16/02/2014 09:24, Bert Verhees wrote: > I have read the PPT from Thomas which is linked in > http://www.openehr.org/wiki/display/CIMI/CIMI+Entry-in-Entry+Modelling+Pattern just to clarify, this PPT was created by the CIMI - it's based on the CIMI model, not the openEHR reference model. I have

What does ADL 1.5 look like?

For intrest - some real world archetypes are posted here . Also a link to the newly upgraded ADL regression test archetypes, for the masochists here :) - thomas -- next part -- An HTML attachment was

What does ADL 1.5 look like?

On 17/02/2014 09:34, Diego Bosc? wrote: > The list of terminology codes (at, id, ac) mixed with no clear order > seems scary, but again it isn't something I expect anybody to read > without a tool aid ;) > It wouldn't be hard to order them, but I don't know if it's useful other than for purely

CIMI archetype examples using latest openEHR AOM & ADL

Bert, I think we can achieve more flexibility than the current RM without too much change, and keeping the useful components that exist today. On 17/02/2014 09:28, Bert Verhees wrote: > Bert Verhees schreef op 16-2-2014 16:57: >> Or is it possible that a new way of structuring health-data can c

CIMI archetype examples using latest openEHR AOM & ADL

On 17/02/2014 17:37, Bert Verhees wrote: > Thomas Beale schreef op 17-2-2014 14:59: >> >> >> Can you say how this could happen? If there is doubt, just choose the >> one that seems to fit, and use it. I think the only question is: for >> a given clinical content

Too much implied semantics for acxxxx code?

On 17/02/2014 17:43, Diego Bosc? wrote: > (Posting this here as Ian suggested) > I was looking at the Demonstration archetype and found something strange. > > When I look where ac0001 is used in this archetype I feel that too > much implied knowledge is being used. > > >

ADL/AOM 1.5 - id-codes unification - the final change

Thanks for the input; see the wiki page for response. On 02/01/2014 09:41, Diego Bosc? wrote: > Made a comment on the wiki page, but I will copy that here too: > > Still thinking about this, but I have a first doubt: > > What i

ADL/AOM 1.5 progress

I have uploaded a new ADL 1.5 and AOM 1.5 specification, showing recent major improvements: * new identification approach * removal of AOM CONSTRAINT_REF class * removal of AOM C_REFERENCE_OBJECT class * simplification of archetype terminology They will contain a errors in prose parts,

ADL & AOM specifications upgraded

The ADL and AOM specification documents have now been upgraded to reflect recent developments. They new include the new identification system, plus terminology URIs, as well as other simplifications and cleaning up. These changes are all implemented in the forthcoming ADL workbench. See here:

radical idea - where term value sets should be defined in archetypes.

I have created a wiki page to describe a possibly radical idea about how we define value sets (like body position etc) in archetypes. all feedback welcome. - thomas -- next part -- An HTML

radical idea - where term value sets should be defined in archetypes.

On 14/01/2014 10:52, Daniel Karlsson wrote: > Thomas and All, > > [Sent to CIMI-list as well... Sorry for cross-posting] > > >From what I can see the > difference, apart from syntax, from the current AOM is that value sets > are named objects by themselves. This would actually solve the problem > o

radical idea - where term value sets should be defined in archetypes.

On 14/01/2014 11:07, Diego Bosc? wrote: > I like the idea, we were already exploring something similar to this > for intra-archetype semantic relationships. > > I have two questions/suggestions: > > -once the vs is intoduced, do we still need to specify it as > "local". Wouldn't be always be

Intra-archetype semantic relationships

On 14/01/2014 11:07, Diego Bosc? wrote: > I like the idea, we were already exploring something similar to this > for intra-archetype semantic relationships. > Since Diego brought up the topic one of the final things needed in ADL/AOM 1.5 is a better kind of slot, which works off an ontology

Intra-archetype semantic relationships

On 15/01/2014 09:09, Diego Bosc? wrote: > I agree that sometimes regular expressions can be tricky, and surely > they don't look pretty on its current form. However, but they have an > advantage: They are formal and easily evaluated in any language. The > problem I see with this approach is that

Update on meta-data for openEHR and 13606

Following conversations with Ian McNicoll and others working on the archetype meta-data question, I have posted a possible revised model containing the following changes to the current one: * copyright has been moved to

Update on meta-data for openEHR and 13606

On 27/01/2014 14:01, Ian McNicoll wrote: > Hi Thomas, > > Looking good. I think we do need to think of adding 'version_id to > each Translation to help developers know which original language > version/revision has been used to create the translation. This was > something that Bert mentioned. > I

Update on meta-data for openEHR and 13606

On 27/01/2014 13:37, Diego Bosc? wrote: > Just a couple of comments: > > Do really is_template & is_overlay need to be mandatory? well they are only mandatory due to being Booleans, and in standard programming languages, Boolean (or bool or whatever) is a builtin type that is always there. In XM

ADL/AOM 1.5 progress update

Update on progress in the last few weeks: I have implemented a reasonable form of the value-sets in terminology idea. All is explained here on the updated wiki page . Originally I had notions of making some 'powerf

ADL/AOM 1.5 - id-codes unification - the final change

happy new year and best wishes for 2014. I hope your new year's day is a bright one (unless you live in the UK, in which case it's a lost cause today ;-) I have been working in the last few months to produce a final version of ADL/AOM 1.5, based on: * existing requirements

openEHR ecore model?

Good question. There is not, but if this is a candidate starting point, and if it is in current ecore format (I don't know much about the format, pity it's XML - otherwise we could read it), it could be a starting point for a publishable ecore model. I'll get Seref to have a look at it, but an

BMM (Basic Meta-Model) upgrade

["careProvider"] = (P_BMM_CONTAINER_PROPERTY) < name = <"careProvider"> type_def = < container_type = <"List"> type_def = (P_BMM_GENERIC_TYPE) < root_type = <&quo

Wrong link to openEHR XSDs?

On 12/03/2014 20:13, pablo pazos wrote: > https://raw.github.com/openEHR/specifications/Release-1.0.2/publishing/its/XML-schema/index.html > > > This URL will work: http://htmlpreview.github.io/?https://github.com/openEHR/specifications/Release-1.0.2/publishing/its/XML-schema/index.html I'll p

ADL 1.5 definitions

I've put up a new page on this here . Please note that there are a few legacy rules that you don't need to care about if you are doing pure 1.5. We'll make a pure version of these parser grammars at some point. The ones at this

ADL 1.5 definitions

On 17/03/2014 16:31, ANASTASIOU A. wrote: > Hello Thomas > > Thank you for the quick response. I guess i am going to have to go > through the yacc style files and get the definitions...it's been > sometime since i last used that family of tools. I am primarily > interested in ADL 1.5, for the new w

Archetype for patient demographics.

On 21/03/2014 16:13, Alejandro Benavides wrote: > Thank Pablo for you answer. > > We want store this information because the RIS, will start stored the > information demographic patients and not will have way make query to a > MPI. Maybe we need to provide in this projeThank Pablo for you answer.

Cyclic datatypes: OpenEHR virus

Hi Bert, On 12/05/2014 15:07, Bert Verhees wrote: > Hi, > > I found a peculiarity which causes me some trouble. Not that my > trouble is a problem, I can solve that, but not without breaking some > rules, and the solutions is quite arbitrarily. > The solution is to check if there is any cyclic

Cyclic datatypes: OpenEHR virus

On 12/05/2014 22:20, Bert Verhees wrote: > Thomas Beale schreef op 12-5-2014 17:25: >> I don't see the problem here; the DV_CODED_TEXT of the >> TERM_MAPPING.purpose is always a different instance from the root >> DV_TEXT or DV_CODED_TEXT instance. So how can a loop occ

Cyclic datatypes: OpenEHR virus

Agree with all this. But you can't code for every possibility in existence, you still have to pick and choose, according to the feasibility criterion ;-) On 13/05/2014 09:36, Bert Verhees wrote: > On 13-05-14 10:12, Thomas Beale wrote: >> this bit is true. Do you have such pat

Cyclic datatypes: OpenEHR virus

On 14/05/2014 10:05, Bert Verhees wrote: > It should not be focused on OpenEHR, I guess many more > modeling-systems (not only two level) can have same situations, but I > guess developers have caught most of them. But since this is an > OpenEHR-list, and I run against this problem in an OpenEHR

Cyclic datatypes: OpenEHR virus

On 15/05/2014 17:51, Bert Verhees wrote: > On 14-05-14 11:49, Thomas Beale wrote: >> I would recommend a 2 or 3 pass validator. It's tempting to try to do >> everything in one pass, and it may be more efficient, but it's much >> harder to get the logic right. &

Cyclic datatypes: OpenEHR virus

on this if you need. - thomas On 16/05/2014 09:28, Bert Verhees wrote: > On 16-05-14 03:55, pablo pazos wrote: >> I mentioned the phases, several times, in my previous messages :) >> >> Maybe Thomas can break that up into more phases. > > On 16-05-14 09:16, Thomas Beale

Cyclic datatypes: OpenEHR virus

On 16/05/2014 12:35, Timothy W. Cook wrote: > Tom gave a good intro to ADL 1.5 on the webinar Tuesday. Maybe Tom > knows if they recorded it and posted to YouTube? > I don't see a link yet, but in any case, it was pretty rough, so I might do one myself and post it on Youtube. The time has come.

ADL / AOM 1.5 wiki resources have moved to new 'ADL' space

or has complaints, please let me know on this list or privately. I am continually trying to improve the usability of these pages, so feedback from all users is extremely valuable. Please either leave comments on specific pages, or post on the lists. thanks - thomas beale -- next p

Cyclic datatypes: OpenEHR virus

On 16/05/2014 19:10, Timothy W. Cook wrote: > On Fri, May 16, 2014 at 2:23 PM, Thomas Beale > <mailto:thomas.beale at oceaninformatics.com>> wrote: > > On 16/05/2014 12:35, Timothy W. Cook wrote: >> Tom gave a good intro to ADL 1.5 on the webinar Tuesday. May

Cyclic datatypes: OpenEHR virus

On 17/05/2014 10:44, Timothy W. Cook wrote: > Exactly. One of the options when you start a Hangout is to enable > live recording to YouTube. You can then go back and edit it if you > wish. Otherwise it is streamed and recorded on YouTube. You fill in > the metadata and enable publication. T

Cyclic datatypes: OpenEHR virus

On 17/05/2014 12:21, Timothy W. Cook wrote: > I guess I should create some kind of index. Your the second person > this week to ask where to start. For the Healthcare IT Live! videos; > they are all numbered with the guests name in the title and are > listed in the playlist link above. The

Ocean Template Designer crashes

Hi Pablo Ocean does work on the TD, but also intends to open source it. The only barrier to this is that some code has to be removed that connects to internal Ocean tools, also we need to check on any non-open source libs that might have been used. We are being slower on this than we should,

open platforms blog post

Although not directly about openEHR, I made a recent blog post on open platforms that some people here may find useful, e.g. in advocacy inside your organisations. - thomas -- next part -- An HTML attachment w

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 act

ADL 1.4 migration roadmap - a start

I have started an ADL 1.4 migration roadmap page . 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 co

ADL 1.4 migration roadmap - a start

On 07/11/2014 12:57, David Moner wrote: > Hello Thomas and thank you very much for pushing this. As we talked > early this year, I think this interim or transitory versions are the > way to go before 2.0 is complete. > Personally, and regarding EN ISO 13606, I also think it is the best > option

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

Something that has become clear in CIMI, and will affect openEHR, 13606 and most likely any archetype developer is that acknowledgements of 3rd party copyrights and trademarks need to be made. The most obvious common one is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at I

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

On 13/11/2014 09:10, Heather Leslie wrote: > > It is actually relevant to have this information in the ?Use? as it is > a reasonable place to look to see constraints on use and how it should > be implemented in systems. > > No reason why it can?t be in a dedicated/purpose-built place as well. >

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

Well, my point here isn't to discuss whether LOINC needs to be mentioned, it's to determine the way for general recognition of 3rd party IP used in the artefact. - thomas On 13/11/2014 09:27, Jussara Rotzsch wrote: > https://loinc.org/terms-of-use > > Enviado do meu iPad -- next p

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

Hi David, licence is taken care of in the model as it is today . Note that it is currently spelt in international English, not US English ('license', which is o

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

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

the home page for that. I'll do a test this weekend on the new 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

Another meta-data requirement from CIMI

In CIMI, there are now some thousands of archetypes, 90% converted from Intermountain CEMs. We can start converting openEHR archetypes to CIMI form as well, for contribution to CIMI. To provide traceability, we probably are going to need a new meta-data item where some information about model

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 wh

Another meta-data requirement from CIMI

On 13/11/2014 18:37, David Moner wrote: > I don't think so, but maybe we could use the release_candidate state, > instead the draft one that I mentioned. well I think either could be correct, depending on the circumstances. E.g. the latest openEHR/FHIR joint Adverse reaction archetype might go

Another meta-data requirement from CIMI

On 13/11/2014 18:48, David Moner wrote: > We can't assume that an approved/published Intermountain model (to say > something) automatically becomes a published archetype either. So we > have a problem here. Which should be the default life cycle state of > an auto-generated archetype? I don't t

Another meta-data requirement from CIMI

On 13/11/2014 18:43, David Moner wrote: > > > 2014-11-13 19:23 GMT+01:00 Thomas Beale > <mailto:thomas.beale at oceaninformatics.com>>: > > On 13/11/2014 16:50, David Moner wrote: >> As you say, this information should be somehow related to the >

Postulate: DV_QUANTITY should be modelled with fewest possible units

On 13/11/2014 20:34, Bakke, Silje Ljosland wrote: > The original context for this discussion was this archetype: > http://arketyper.no/ckm/#showArchetype_1078.36.25 (default archetype language > for this CKM is Norwegian, but it can be changed manually) > > Being an all-metric country since the 1

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 m

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 le

Postulate: DV_QUANTITY should be modelled with fewest possible units

Should we have a way of marking the 'normative' units for computation / conversion? So that then you only create AQL queries in the units you want, and let the query service do the rest (e.g. by looking up the UCUM DB)? In fact, you don't even need to mark anything as normative, if the query s

Postulate: DV_QUANTITY should be modelled with fewest possible units

On 14/11/2014 13:32, Diego Bosc? wrote: > Again, I strongly believe we can achieve this with > Assertions/pseudo-OCL that currently can be defined in archetypes. > For example: "if 'units' from at are 'kg' then > 'value'='value'*1000 and 'units'=g" > > I think Thomas told me there were some imp

ORIGINAL_VERSION.attestations is needed in the IM?

Hi Pablo, yep, it's correct as it is - the model satisfies the use case where there can be more than on attestation. It was designed to deal with things like (from memory) a junior doc attesting, and later a more senior doc. These were clinical expert's requirements at the time, and someone l

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

Postulate: DV_QUANTITY should be modelled with fewest possible units

On 17/11/2014 07:42, Ian McNicoll wrote: > Hi Karsten, > > I agree, this will not always be possible but where the conversion can > be safely done, I would still argue that this should be done at RM > level and not per-archetype. > Hi Ian, I'm not sure what you mean by "doing this at the RM level

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 l

archetype UIDs

We are finalising the last details of the ADL 2/AOM 2 specifications for a Trial release. One detail is the question of UIDs. The current AOM 2 specification shows two UIDs: provenance_id and instance_id. The former is created at archetype creation and never updated, even with major archetype

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 i

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

<    5   6   7   8   9   10   11   12   13   14   >