Re: RM Participations name/role?

Hi David, On 24/11/2016 08:18, David Moner wrote: Hi, I'm not sure if this is a correct approach. What in the example you call a function can be in fact a full Action that is being done. That is, if the function is so relevant that you can even assign a dedicated participant to it, it should

Re: RM Participations name/role?

Ian. On Wed, 23 Nov 2016 at 17:32, Thomas Beale <mailto:thomas.be...@openehr.org>> wrote: Hi Silje, The PARTICIPATION class <http://www.openehr.org/releases/RM/latest/docs/common/common.html#_overview_3> has a codable attribute 'function' for this pur

Re: RM Participations name/role?

Hi Silje, The PARTICIPATION class has a codable attribute 'function' for this purpose (calling it 'function' rather than 'role' came from 13606). It may be that you want to state a 'role' as well, i.e. to say that

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

alf of Thomas Beale *Sent:* Thursday, November 3, 2016 8:02:41 AM *To:* openehr-technical@lists.openehr.org *Subject:* Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives ___ openEHR-technical mailing list openEHR-technical@lists.openehr.or

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

Hi Pieter, On 01/11/2016 10:22, Pieter Bos wrote: I fully agree that they should be mandatory. Things like this make writing software based on OpenEHR more complex than it could be. I also never understood that the DV_-types do not have an archetype node id in the reference model. this is

HL7 Specification: Characteristics of a Value Set Definition, Release 1 - open for comments

An HL7 specification of the above title is visible here , and open for comments. This is likely to be relevant to our conversations here on terminology + openEHR. I've made some comments as can be seen at that link; others might find

Re: SV: More generic reference model

) Michae Sent from my iPhone On 13 Sep 2016, at 1:23 AM, Thomas Beale wrote: Bert, these are just selectors; what I mean is that in the generated result - the actual value set - that IS-A relationships are returned as well as concept codes. Without IS-A relationships a user can't na

Re: SV: More generic reference model

Grahame, can you post a URL to that functionality / spec? thanks - thomas On 12/09/2016 16:36, Grahame Grieve wrote: yes. In our terminology, this is paging through an expansion Grahame ___ openEHR-technical mailing list openEHR-technical@list

Re: SV: More generic reference model

Can everyone who has concrete ideas on ways forward make an effort to update the wiki page we created for this, and/or add to the Questions facility for some of the use

Re: SV: More generic reference model

In other words something like a DB cursor to traverse large value sets that reside on the server, in response to client (user) actions on the screen? Has that been implemented in FHIR-land? - thomas On 12/09/2016 16:26, Grahame Grieve wrote: The best way to resolve this is to make the termin

Re: SV: More generic reference model

On 12/09/2016 07:25, Bert Verhees wrote: Op 11-9-2016 om 20:21 schreef Thomas Beale: Not an unreasonable point of view, but it sort of implies that there are / will be no well-known / reliable terminology value sets out there - only specific value sets inside specific terminology services

Re: SV: More generic reference model

On 12/09/2016 10:27, Bert Verhees wrote: Op 12-9-2016 om 10:32 schreef Thomas Beale: we also still need a standard approach for non-SNOMED CT terminologies, such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of progress on this issue? There is a detailed answer, I

Re: SV: More generic reference model

homas On 12/09/2016 10:23, Bert Verhees wrote: Op 12-9-2016 om 10:30 schreef Thomas Beale: does the expansion preserve IS-A relationships (at least optionally)? That's crucial for making any value set of more than about 20 terms usable in a real system. I think you need to do that by

Re: SV: More generic reference model

we also still need a standard approach for non-SNOMED CT terminologies, such as ICDx, ICPC, ICF, LOINC and a hundred others... does anyone know of progress on this issue? - thomas On 12/09/2016 07:32, Diego Boscá wrote: sure thing, that's why we need standard expressions 2016-09-12 8:27 GM

Re: SV: More generic reference model

On 12/09/2016 07:01, michael.law...@csiro.au wrote: I strongly recommend looking at the way terminology services are handled in FHIR. A ValueSet Resource (ie the subsets you're talking about) has a URI, so that it can be replicated in a local TS and referenced by it's well-known identifier

Re: SV: More generic reference model

Not an unreasonable point of view, but it sort of implies that there are / will be no well-known / reliable terminology value sets out there - only specific value sets inside specific terminology services. On 11/09/2016 19:10, Diego Boscá wrote: The problem I see with depending on a given ter

Re: SV: More generic reference model

On 11/09/2016 15:48, pablo pazos wrote: Hi Bert, I was thinking about integrating SCT with path-based queries (I'm not in AQL yet), but maintaining the complexity of the SCT relationships and expressions on the terminology service (TS) side, so on queries there are just simple codes (spec

Re: SV: More generic reference model

On 11/09/2016 18:44, pablo pazos wrote: IMHO the clearness of the query should not depend on the AQL code, but the metadata associated with the query, like the ADL header and ontology, the AQL would be the "definition" of the query. To share queries between systems the AQL is not enough. We

Re: More generic reference model

ideas. -- Bert ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Thomas Beale* Management Board, Specifications P

Re: SV: More generic reference model

countries, like ICD and LOINC. However, it is understandable that for people in non-member countries it seems like IHTSDO assumes that the whole world uses SNOMED CT. Regards Mikael Thomas Beale wrote: Indeed. Ideally we would work more closely with IHTSDO on this (I spent 4 y on standing

Re: More generic reference model

this is an eminently sensible suggestion for how to implement certain aspects of terminology processing in an openEHR system. - thomas On 02/09/2016 06:28, Daniel Karlsson wrote: Bert, if I understand your issue correctly, I believe that some sort of "code index" is needed in openEHR persist

Re: More generic reference model

On 03/09/2016 10:34, Bert Verhees wrote: On 03-09-16 18:17, Thomas Beale wrote: WHERE c/name/value='Current Problems' AND diagnosis/data/items[at0002.1]/value/defining_code *matches* { http://snomed.info/id/4257030190487|cancer Dx refset|} That is a very OpenEHRish wa

Re: More generic reference model

... etc. Querying properly means understanding where in the data you are looking, and the archetypes help with that. - thomas On 02/09/2016 09:55, Bert Verhees wrote: On 02-09-16 16:45, Thomas Beale wrote: Actually SNOMED did exist when we designed the openEHR RM, and even if today's

Re: More generic reference model

On 02/09/2016 04:04, Bert Verhees wrote: On 02-09-16 11:18, Daniel Karlsson wrote: Terminologies typically do not specify which pieces of information are needed in a given situation. Hi Daniel, I don't have at the moment opportunity to reply to all you write, so excuse me for cherrypicking

Re: More generic reference model

I would be interested to see a) developer code for a 100 event time series of BP with no dedicated structures, just hierarchy + SNOMED and b) a query to find systolic BPs over 165 that persist for more than 10 mins in that same series. They're both doable, but they will be harder. - thomas

Re: More generic reference model

Actually SNOMED did exist when we designed the openEHR RM, and even if today's SNOMED CT had existed we would have done pretty much the same thing I think. The Observation model for example is a structural model of time series data, adapted to direct software use. Trying to use SNOMED to code

Re: Do you know of any new openEHR projects?

See here - should be up to date now. On 27/07/2016 09:26, pablo pazos wrote: Hi Thomas, EHRGen (generator of openEHR EMRs) and EHRServer (openEHR service-oriented backend) are different projects, I think both should be on that page. Also I hav

Re: Do you know of any new openEHR projects?

___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Thomas Beale* Management Board, Specifications Program Lead, openEHR Foundation <http://www.

Re: SV: initial states for instructions / when do we need actions?

On 26/07/2016 07:58, Ivar Yrke wrote: Hi Last thing first: We also have the need for «proposed». For that we use PLANNED. After all you can CANCEL from PLANNED, so it serves the purpose. I think the issue here is to not overinterpret the names in the state machine and to avoid making it ov

Re: initial states for instructions / when do we need actions?

On 22/07/2016 18:35, Etienne Saliez wrote: Thank you very much for the schema. However I believe that the handling of an Action should start earlier before the "INITIAL" state. - "SUGGESTED" Preliminary informal suggestion, according to some generic guidelines, regardless of the details o

RM ideas to deal better with orders, workflow, panels, order sets

A problem the community has been looking at in openEHR for some time is how to deal clearly with order-related meta-data (typically: requestor and receiver ids of various sorts). The topic of 'orderables' has been mentioned in some recent discussions in CIMI

Re: initial states for instructions / when do we need actions?

Hi Pablo can you raise a PR for this, with some summary of the changes you think are needed? thanks - thomas On 14/07/2016 05:16, pablo pazos wrote: Hi Heath, thanks for taking the time to answer, this is really useful and I think your comments should be included in the specs as examples

Re: Specs about ACTIVITY.timing still unclear

On 26/06/2016 22:23, pablo pazos wrote: Thanks for your message Ian, IMO avoiding the implementation of ACTIVITY.timing raises the question of why that was introduced in the model and if we should keep it or not. it was included on the assumption that timing would be represented as a forma

Do you know of any new openEHR projects?

We have updated the EHR System Components page with some of the newer projects we know about. This page doesn't include the commercial products from the vendor pages (maybe it should? Opinions we

Re: INTERVAL_EVENT questions about the correctness of the specs

On 17/06/2016 22:26, pablo pazos wrote: Done: https://openehr.atlassian.net/browse/SPECPR-197 I added this to the PR description: PP: is it possible to record a mean and a max value no the same EVENT.data? e.g. mean syst BP and max syst BP in an interval of time. Since there is only one math

Re: ADL Workbench exceptions when opening the audiogram archetype

Hi Pablo, even if it is for archetypes not in Git, it is still better to create a 'repository' and within that a 'library' containing the archetypes you work on - that's the normal working approach. I agree that the ad hoc 'Open' function should always work - can you raise an issue on the ad

Re: INTERVAL_EVENT questions about the correctness of the specs

On 17/06/2016 04:55, pablo pazos wrote: Hi, I'm preparing some materials for a course and I was reviewing the HISTORY/EVENT package. On the INTERVAL_EVENT field descriptions I noted that those might not be 100% correct or clear. Before raising an issue on JIRA I wanted to know what you th

Re: ADL Workbench exceptions when opening the audiogram archetype

Pablo, I'll look into what is going wrong there, but that's not the normal way to use the Workbench to look at CKM archetypes (it's still a bug obviously;). It will work if you follow the instructions here - then you can lo

Re: ADL Workbench exceptions when opening the audiogram archetype

Pablo, I suggest you try the newer Windows (64-bit) 2.0.6.2902 build . To access CKM archetypes, all you need to do is to follow the instructions here for the CKM-mirror r

Re: ADL validity rules on CKM

Hi Pablo, only a few rules were specified in ADL/AOM 1.4 - you can see them in the ADL1.4 spec - I think you will find the newer HTML version easier to use. They were not collected in an easy to read list, but I think we coul

Re: openEHR draft Expression spec

On 19/05/2016 16:20, Pieter Bos wrote: Hello Thomas, I had already noticed the expressions part and based my experimental implementation on that. This email got quite long, so let’s start with a summary: Summary: - The current spec is quite similar to XPath. We can keep this even closer by

Re: openEHR-technical Digest, Vol 51, Issue 26

On 19/05/2016 18:19, William Goossen wrote: It does include VERY much more than mg or number of tablets. I.a units like in insulin, drops like in a piper, percentage of working substances in herbs and MANY more. Unfortunately you have to study it yourself 😩 right - that is what I assume. Wh

new FAQ page - context in openEHR

in response to some questions in CIMI, I created a new FAQ page - Context and attribution in openEHR . Feel free to add and improve. - thomas ___ openEHR-techn

Re: openEHR-technical Digest, Vol 51, Issue 24

William, I think the question is /how/ they use UCUM. If it's just a question of expressing '5 mg', that works out of the box. I would imagine that here you are talking about the manufactured dose of one tablet / capsule / etc, i.e. the manufacturer's point of view (what's printed on the box).

openEHR draft Expression spec

Pieter, With respect to the 'rules' bit of ADL, and also GDL, there is a new draft 'Expressions' spec in the BASE component . This is a working draft, and partly lifted from ADL/AOMs specs (those now just include this one), plus some ext

Re: UCUM code in body temperature archetype

On 19/05/2016 08:26, Ian McNicoll wrote: Hi Thomas, I appreciate that the Quantity classes add computability such as the +,-,=, diff operators etc but computability (or at least safe/sensible computability) is not a given even when the two operands share the same unit. it might not be clini

Re: UCUM code in body temperature archetype

Hi Gerard, they actually could be, but whenever this discussion comes up, no-one proposes it. I'm not sure if I would either, because these arbitrary units are still not computable in general, but 'dose units' can be made computable but only with some extra data fields, i.e. you need both the

Re: UCUM code in body temperature archetype

Grahame, I think you are saying that you can implement the /semantics /of dose units with just a DvQantity / FHIR Quantity. If 'dose units' includes the knowledge of the discrete unit of delivery, i.e. table, drop etc, as well as total amount, you can't. You need at least the elements here, or

Re: Archie version 0.1.0 released

openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Thomas Beale* Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org> Chief Technology Officer, O

Re: UCUM code in body temperature archetype

Eric, One thing I had better do is re-instate my UCUM string checker in the ADL Workbench... thanks for the timely warning. - thomas On 18/05/2016 12:59, Eric Browne wrote: Dear All, There are many, many, many archetypes in the various openEHR CKMs that DO NOT, I repeat DO NOT, I repeat

Re: UCUM code in body temperature archetype

I knew someone would say that;-) But it's not for some principle of ontological purity. It's for the most basic practical reasons. Consider a quantity / units library designed based on a rigorous model of units, like UCUM (which is a very good and rigorous piece of work), and also other basic

Re: UCUM code in body temperature archetype

On 18/05/2016 12:24, Ian McNicoll wrote: Hi thomas, See https://openehr.atlassian.net/browse/SPECPR-96 for discussion on this. Medication dose and quantities need both SI units and otherwise. The current restrictions make the modelling much clunkier than is necessary IMO. I'm not clear why s

Re: UCUM code in body temperature archetype

On 18/05/2016 12:21, Grahame Grieve wrote: The main problem is that ucum units are not human readable units, right - my idea 13 years ago was to use the UCUM string as a key into something that generated a human-readable form. For reasons that became clearer since, I think we all agree that

Re: UCUM code in body temperature archetype

Hi Ian As far as I know, 'dose units' are not scientific units as such; they're measures of discrete objects (including 'puffs' etc), which don't fit into a clean grammar of scientific units, and trying to do so will just ruin the former. We do of course need dose units, but we need a better

Re: UCUM code in body temperature archetype

It's not out of the question, although my view was always that the units string should be parsed and then rendered using one of the other columns of UCUM, or even something else. But this does as Silje says, put more work on to implementers, so we probably should consider a CR on the RM to add

Re: UCUM code in body temperature archetype

Hi Daniel, the reason it is a String is because we have always treated UCUM units as parseable strings. E.g. kg.m^-2 and kg/m^2 are parseable according to UCUM's grammar into an expression that has a single meaning, and can also b

Re: Terminology bindings in openEHR

Some background information from the ADL2 spec may help. This description explains the same semantics as for ADL 1.4. archetypes, except that in ADL 1.4, 'at' and 'ac' codes are used, whereas ADL2 has 'id',

Re: SNOMED

Mikael Ok, I take your point in one sense, but how are we to know what is 'in use', 'not really in use', 'outdated', ? More importantly, how would a national programme signal to its user base which hierarchies are deprecated, semi-deprecated, needing work - don't use), or something simila

Re: SNOMED

Hi Mikael, right... but the usual idea is that these codes would be used in a post-coordinated expression. I think most of those expressions are problematic as well. Aside: quite what 'Abuse counselling for non-offending parent (situation)' is doing there is another question. Or 'Both paren

Re: SNOMED

On 29/04/2016 16:28, Bert Verhees wrote: Thanks Thomas, I read your text a few times, and now I think I understand what you are saying. You say that SNOMED (first remark is not of that high quality to be useful for this purpose) is too extended, too many datapoints, and many useless datapoin

Re: SNOMED

Hi Bert Erik and Ian partly answered this, but it is always worth remembering that SNOMED CT, if based on proper ontological principles, contains assertions that represent entities in the real world. This means taxonomy (IS-A) and properties, qualities, possible relationships and so on (see B

ADL Workbench 64 bit build available

For those who use the ADL Workbench, there is a new 64-bit Windows build available . See top entry in 'Latest Builds'. This also fixes a number of bugs. A proper release will be posted shortly. - thomas ___

Re: Ordinal values without descriptions

On 26/04/2016 19:54, David Moner wrote: I will not discuss about the readiness of that particular scale. But un general words, we are very accustomed to scales where you have to answer "From 1 to 10, score your satisfaction with the service provided, with 1 meaning 'not satisfied at all' and 1

Re: Ordinal values without descriptions

If you give someone a '3' on the Apparent Sadness scale, what does it mean? Apparently it's /between /'Looks dispirited but does brighten up without difficulty' and 'Appears sad and unhappy most of the time' So now imagine that this '3' appears for me in my record - just that value. The sc

Re: Activity based workflow - request for literature & resources

This is very relevant. Can you please post this as an answer to the wiki page , that way it won't get lost, and we can get back to you as we process the in

Re: Activity based workflow - request for literature & resources

On 13/04/2016 14:45, Seref Arikan wrote: Hi Tom, Very interesting. Good to see Intermountain tackling wflow. Especially the idea of adaptive wflows is intriguing. Cooperative category sounds like a true challenge. Inevitable questions follow: Any specs out there? Any code? A shared space

Re: Activity based workflow - request for literature & resources

I added a bit more background information on the ABD workflow project: Activity-Based Design is based on the idea that an 'Activity' is the unit of clinical work, and thus also the unit of formal definition of a workflow. An Activity as currently conceived includes: * semantic model (elemen

Re: Activity based workflow - request for literature & resources

Hi Klaus, this looks very relevant. Can you add it to the wiki page as a response (doing this means I can more easily track back to contributors). Is Esso

Re: Activity based workflow - request for literature & resources

:14, Mate Beštek wrote: Hi Thomas, We have worked with BPMN2 on the eCare project. Basically, we modeled interventions with BPMN2 and OpenEHR. Still doing things with this. Regards,Mate On Tue, 12 Apr 2016 at 13:07 Thomas Beale <mailto:thomas.be...@openehr.org>> wrote: As pa

Activity based workflow - request for literature & resources

As part of the Activity-based Design (ABD) workflow project on which I am engaged in at Intermountain Health, I agreed to do a literature search on the topic. Since I believe this is of general interest to us in openEHR, I'm making it an open question. Note that the design work of the ABD gro

Re: SV: Usage of Compositoin.Category

On 11/04/2016 11:07, Bjørn Næss wrote: But if we want to avoid double results in querying, we need some sort of 'is_derived' or 'is_copy' marker (and a link to original content) on the copy. At least that's where I got to the last time I thought about it. Yes – I think we need some kind o

EC EXPERT PANEL ON EFFECTIVE WAYS OF INVESTING IN HEALTH - Disruptive innovation - openEHR comments

In November 2015, there was an EC RFI on their draft document on 'disruptive innovation' put out, to which openEHR put together a response. The new document

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

flect ... - thomas On 07/04/2016 20:12, Bert Verhees wrote: On 07-04-16 17:44, Thomas Beale wrote: well, we need to get this right for everyone. The current spec works, but you are suggesting that it be changed to make it 'regex-only'; Diego I think is suggesting something else; but if we

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

well, we need to get this right for everyone. The current spec works, but you are suggesting that it be changed to make it 'regex-only'; Diego I think is suggesting something else; but if we were going to change it, we need to get input from openEHR tool implementers, 13606 group, AML develo

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

On 07/04/2016 13:01, Bert Verhees wrote: On 07-04-16 13:55, Thomas Beale wrote: OK, but there is only one data structure <http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_c_string_class>: constraint: List No, that is not necessary, the structure is redefine

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

On 07/04/2016 12:58, Diego Boscá wrote: It was already like that in the original AOM (pattern & list) right - but a couple of years ago, we simplified and reworked the C_PRIMITIVE subtypes (mainly based on analysis done due to AML). So today there is only 'constraint'. (There is an additio

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

OK, but there is only one data structure : constraint: List Are you saying you want another, separate string field? On 07/04/2016 11:05, Bert Verhees wrote: On 07-04-16 11:16, Diego Boscá wrote: I don't see the

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

On 07/04/2016 10:16, Diego Boscá wrote: IMHO even if regexes are powerful enough using them for representing lists or literals is an overkill (precisely by the reason you gave, having to control and escape all characters would make adl code more less readable (think that a series of specialized

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

This is a question we have wrestled with in defining the AOM String constrainer type C_STRING . Bert has brought it up with some useful analysis in this issue. I would be interested in other opinions on this question s

Re: Composition commit and change types

On 04/04/2016 19:14, pazospa...@hotmail.com wrote: Hi Thomas, What about having the 'delta' mode just at the API level? Storage might not store delta objects, just full objects, but the API allows to send only what was added, modified or deleted instead of the full compo? then you hav

Re: CAMSS assessment of openEHR

I forgot, w.r.t. to versioning of archetypes, this is the specification <http://www.openehr.org/releases/AM/latest/docs/Identification/Identification.html>that applies. On 04/04/2016 15:51, Erik Sundvall wrote: Adding some thoughts below. On Mon, Apr 4, 2016 at 4:02 PM, Thomas

Re: CAMSS assessment of openEHR

On 04/04/2016 14:07, Bakke, Silje Ljosland wrote: Hi, The project has now done a preliminary CAMSS assessment of openEHR. It’s identified some issues that I would like some input on: 1.A.16: “Are the technical specification or standards reviewed using a formal review process with all rele

Re: Composition commit and change types

On 04/04/2016 07:23, pablo pazos wrote: I thought you had more specific cases :) Having specific lists per clinician was commented by Karsten on a previous message and I commented on that. I'm not sure at which extent that is a backend issue, an API issue or an UI issue. I would say if this

Re: Adressing of i.e. discharge summaries

so are we really talking about 'ADT' patterns? On 16/03/2016 07:51, Heath Frankel wrote: Hi Bjorn, Yes we have used these archetypes for representing the service request at both the instruction and composition level. Our instruction starts in a care plan so we have to represent the referred

Re: Usage of Compositoin.Category

___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Thomas Beale* Management Board, Specifications Program Lead, openEHR Foundation <http://www

Re: SV: SV: Usage of Compositoin.Category

On 16/03/2016 05:19, Bjørn Næss wrote: The problem is not to filter in data. The most important feature to support is to filter out data. The proposed solution is to add a new category code to add a new group of Compositions which by default is sorted out. This could be done by archetypes. Bu

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

Hi Daniel, I read most of your thesis, it is fascinating (it's one of those things that requires contemplation, so I have not read it straight through). I recommend others to have a look . One thing that I

Re: Usage of Compositoin.Category

Ivar, yes, this is a reasonable way of looking at things, and it is the way AQL currently works. There is talk of adding a new operator to follow links, but we need to invent a way to mark the returned data as being targets of references rather than primary in this case. The reason to allow

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

I can only see the abstract for now, but I think the authors seem to have developed the misconception that end-users would somehow be designing applications. openEHR doesn't try to do that, and it's the first time I've heard anyone suggest it. openEHR just enables domain experts (generally =

Re: SV: Usage of Compositoin.Category

Currently I think we filter on 'report' COMPOSITIONs via something like: FROM COMPOSITION c[openEHR-EHR-COMPOSITION.report.v1] CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.body_weight.v1] So that would not need any change to the COMPOSITION.category to be achieved. Not saying there a

Re: Usage of Compositoin.Category

Re: process, yes, it needs to be managed separately. Ian is the terminology component owner. But I assumed Bjørn was talking about the semantics of the new term - 'Report'. Bjørn - can you elaborate on what Compositions would merit the 'report' Composition category? - thomas On 04/03/2016

Re: Strange use of 'offset' as a settable RM attribute

Using the rules could be a useful approach. One thing we decided in the SEC meeting last week was to rework the 'rules' part of ADL as a small core model in the BASE component and then re-use that back into ADL2 and also GDL. This will result in a new small BASE/Rules specification and the AD

Re: Archetype relational mapping - a practical openEHR persistence solution

On 16/02/2016 11:26, Seref Arikan wrote: The document oriented view of the domain has no problem with storing XML text in the DB, because the implementations are built against that view. The clinical care focused use cases require developers to focus on reading & writing documents, so there i

Re: Strange use of 'offset' as a settable RM attribute

On 15/02/2016 10:25, Sebastian Garde wrote: We have been through this a long time ago I think, with Koray having the exact question and opinion I had. The downside if you don't allow this kind of constraint(!) on functional attributes in archetypes, here you cannot constrain the other two

Re: Archetype relational mapping - a practical openEHR persistence solution

On 14/02/2016 23:25, Bert Verhees wrote: One doesn't know what software really does. One must distinguish what software seems to do and what it really does. Storing XML really as XML means, storing a lot of redundant information. I don't know, but I cannot believe postgress really stores

Re: Strange use of 'offset' as a settable RM attribute

On 12/02/2016 04:29, Koray Atalag wrote: Hi, We noted it is possible to set values from AE/TD to a RM attribute named “offset” In the specs (looked at >1.0.1) it is not a regular att

Re: Representing microseconds in DateTime

Well, we can change the spec if people find it confusing, but as far as I can see, it doesn't say anything about milliseconds or limiting fractional seconds to 3 places. But if you want to propose a wording change, feel free to raise a PR, we can address it in the next minor release. - tho

Re: Representing microseconds in DateTime

I don't think there is any assumption that [,sss] means there are no microseconds. The field is just called 'fractional_second' and it's a Real (i.e. a float). We just used 'sss' as an arbitrary indicator of fractional seconds (how many 's' do you want ;-) - thomas On 02/02/2016 09:51, Kora

Re: Archetype relational mapping - a practical openEHR persistence solution

I have not performance tested my own implementation (although I did actually build one over a decade ago). But the Informix path system was real and performant (they used a hierachical number node code approach e.g. 1.2.3, 1.2.3.1.2 etc). There are others I have read about as well, but I'd ha

Re: Archetype relational mapping - a practical openEHR persistence solution

On 26/01/2016 09:51, Bert Verhees wrote: On 26-01-16 10:38, Jan-Marc Verlinden wrote: # Our first version was Java based with a postgres DB, everything stored as path/values. Every query would take about a second. We did not even try complex queries..:-). Also the GUI side did not know what t

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