Re: AQL on specific list of compositions

main 'problem' on admission. An episode of care is usually thought of as care to resolve an issue for a patient by a team of HCPs working in an integrated environment, e.g. a hospital. If the resolution of the issue requires care that crosses institutions (usually the case), then a different term is

Re: AQL on specific list of compositions

is one-off. It can encompass a multitude of Reasons for Encounter, about different care targets. An Episode of Care is a time range during which one particular care target is handled. It manifests itself during 1..many Encounters, each of which is about 1..many care targets (problems). Karsten

Re: AQL on specific list of compositions

On 18/08/2018 07:56, Bert Verhees wrote: I cannot imagine how a folder structure can get lost except by data corruption. In that case anything is lost anyway and a rollback from a backup is needed. It's a thought experiment, not a serious proposition about a real system. But it partially

Re: AQL on specific list of compositions

for the typos, on the phone..) On Friday, August 17, 2018, Thomas Beale mailto:thomas.be...@openehr.org>> wrote: There is a bigger question of how best to model 'encounter' and 'admission', which some implementers are doing with Folder

Re: AQL on specific list of compositions

am using AQL to retrieve data per encounter and need to pass the corresponding set of compositions. Thanks in advance regards -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Project, Intermountain Healthcare <https://intermountainhealt

Re: Drug dispense entry class question

There is nothing to prevent the creation of an ACTION /and /an ADMIN_ENTRY, possibly in the same COMPOSITION, and in at least some situations, this is probably the right thing to do. - thomas On 11/08/2018 20:51, Pablo Pazos wrote: Thanks Ian, I know this was modeled. Just wanted to

Re: Drug dispense entry class question

On 11/08/2018 20:21, Karsten Hilbert wrote: On Sat, Aug 11, 2018 at 04:03:28PM -0300, Pablo Pazos wrote: How would you map a "pharmacy drug dispense" task, where the patient comes with a prescription and a clerk delivers the medication packages? I was thinking this is clearly and ACTION,

Re: Is description = <"*"> mandatory?

: http://arketyper.no <http://arketyper.no/>/ Twitter: @arketyper_no <https://twitter.com/arketyper_no> ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_l

Re: Empty COMPOSITION.content is valid?

On 04/07/2018 22:49, Pablo Pazos wrote: Hi all, Recently a client committed COMPOSITIONS with empty content to the EHRServer, because in the OPT all the structure was associated to context.other_context. After reviewing the specs, I found this invariant on the COMPOSITION spec:

Re: Meaningful API's

One general thing to remember is that there will normally be multiple levels of API, from data to domain to business to application. The APIs at those levels are likely to be designed based on different design principles, e.g.: * data level - API will be typically CRUD and query

Re: Meaningful API's

On 16/07/2018 14:56, Bert Verhees wrote: On 16-07-18 14:55, Thomas Beale wrote: well some templates are being slowly added to the international CKM and other CKMs, but generally, templates are what local users and vendors create themselves. Since they don't break archetypes, it is safe

openEHR Basic Meta-Model (BMM) and syntax major upgrade

I have created a new blog post on the latest BMM upgrade. From the post: The openEHRBasic Meta-Model (BMM) that has been in use in some

Meaningful API's

On 16/07/2018 13:35, Bert Verhees wrote: On 16-07-18 13:49, Thomas Beale wrote: It seems to be a competitor to FHIR in some way, since it is not using FHIR. Aren't we all? ;-) But serious, I don't think so, they don't use FHIR because their target-market does not use FHIR. It are mostly

Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

On 13/07/2018 12:13, Diego Boscá wrote: Technically in ADL1.4 it is completely legal that alternatives have their own node codes. Other thing is that OPT or current software supports it it is legal, but not always implemented. Your group (UPV) did the right thing with LinkEHR early on, and

Re: Unique paths for nodes in multiple instances of one archetype in the same OPT

On 06/07/2018 18:03, Pablo Pazos wrote: Hi Dileep, In the EHRServer we use the template path as an absolute path for each node in the template, that allows to identify each node in the OPT even if different nodes hang from the same archetype root (have the same archetype path). This

Re: Machine Learning , some thoughts

data - i.e. the protobuf equivalent of Template Date Schema (TDS). - thomas On 29/06/2018 21:48, Bert Verhees wrote: On 29-06-18 10:27, Thomas Beale wrote: The intention is certainly a good one. It just needs to be the reference model and the Abstract Platform Specification <http://

Re: Machine Learning , some thoughts

y done it and did I miss it? Bert ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Thomas Beale Principal, Ars Semantica <http://www.arssema

Re: Interval events - "change" math function semantics

On 27/06/2018 18:21, Pablo Pazos wrote: I'm inclined to have an initial absolute / reference value, then the "changes" (deltas, increase, decrease, ...) to be recorded in the same HISTORY.data time series. IMO this needs clinical validation, but my assumption os if "reference" and

Re: Interval events - "change" math function semantics

increase is compared with. Agree; to make it sensible, one would expect the first value in a HISTORY of EVENTs to be an absolute instantaneous value, with some or all of the other values being differences. -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Cons

Re: AE constraints offset for POINT_EVENTs

. For example, the Apgar uses only the specific offsets 1 min, 2 mins, 5 mins and 10 mins. - t -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Project, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications

Re: AE constraints offset for POINT_EVENTs

for the RM is the XML Schema and it doesn't define them. -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Project, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Found

Re: Question about periodic interval events

always from start to start, assuming there is periodicity. On 23/06/2018 20:35, Pablo Pazos wrote: Hi all, As usual I'm reading the specs and have a question about periodic interval events. I'm not sure how the period is calculated in a series. Let's say we have interval events on a

Re: SMART on FHIR integration

<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> _______ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Thomas Be

Re: SEC meeting 18-20 April; community issues solicited

s On 23/04/2018 12:00, Bert Verhees wrote: On 23-04-18 11:06, Thomas Beale wrote: The next RM and BASE releases are nearly finalised, and we expect to issue RM Release 1.0.4 within a few weeks. Hi Thomas, Is there some thing to say when the RM Release 1.1.0 approximately will be expect

Re: SEC meeting 18-20 April; community issues solicited

mments to any of these pages. The next RM and BASE releases are nearly finalised, and we expect to issue RM Release 1.0.4 within a few weeks. You will also see a lot of changed statuses on Problem Reports and RM Change Requests. - thomas beale On 10/04/2018 11:01, Thomas Beale wrote: W

SEC meeting 18-20 April; community issues solicited

>. If members of the community have other issues not covered by raised PRs, e.g. future directions questions, that they would like to be discussed, they may add to the agenda page under the 'Community Issues' heading. - thomas beale ___ openEHR-technical ma

Re: SV: [Troll] Terminology bindings ... again

On 05/04/2018 13:50, Philippe Ameline wrote: In my mind, fils guides and archetype are of different kind: an archetype is a flexible information schema and nodes that were "build using this mold" keep a link to it ; on the contrary, a fil guide is nothing more than a UI helper that makes a

Re: SV: [Troll] Terminology bindings ... again

n in terms of bridging the gap between linguistic expression and structural expression - for now, openEHR has no 'system' to do the former, it is just done /ad hoc/ by those who want it. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Interm

Re: [Troll] Terminology bindings ... again

 Some theory along these lines is needed... On 03/04/2018 08:35, A Verhees wrote: GF :"There are NO agreed standardised archetypes/patterns we all use to define the meta-data in order to document the

Re: [Troll] Terminology bindings ... again

In a so-called closed-world system, everything that is stated constitutes the totality of the truths about the world it relates to. In particular, /absence/ of an assertion (such as 'patient X has cancer') means negation, i.e. that patient X doesn't have cancer. But openEHR and 13606 don't

Re: [Troll] Terminology bindings ... again

On 01/04/2018 13:16, GF wrote: Pre-coordinated SNOMED codes are like classifications, in that they are used at the user level, the User Interface, The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed in its constituents. These decomposed primitive codes can be used in

Re: SV: [Troll] Terminology bindings ... again

One thing I have noticed in recent systems in Brazil I looked at is that the codes are locally defined (e.g. SIGTAP, a Brazilian vocabulary for procedures) and almost all pre-coordinations of the most unscientific kind (with terms of the form 'cholecystectomy performed at private or military

Re: SV: [Troll] Terminology bindings ... again

On 31/03/2018 10:38, Philippe Ameline wrote: ... When I try to explain all this to lesser tech-savvy people (means, who don't belong to this list ;-) ), I usually explain that: - usual systems (with an information schema tied to a database schema) are like a printed form. The day after you

Re: [Troll] Terminology bindings ... again

. The unique path defines its meaning. In my way of modelling the collection of paths is a kind of ontology for data in healthcare records. -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealt

Re: [Troll] Terminology bindings ... again

        Mitral valve             Doppler                 Mitral leak         Hence, the "basic query unit" is not for leave nodes, but rather for a path ; for example a query for "Echocardiography/Findings/Mitral valve" would return a sub-tree. -- Thomas Beale Principal,

Re: SV: SV: [Troll] Terminology bindings ... again

-- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org> Chartered IT Professional Fellow, BCS

Re: SV: [Troll] Terminology bindings ... again

ived scale of the problem. michael -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org&g

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

Calendars are for dates and times, not durations. On 21/03/2018 13:47, Bert Verhees wrote: On 21-03-18 13:57, Thomas Beale wrote: although 'month' is not a scientific notion (it's not constant), we do treat it as a data type or unit in /social date time types/, which is what we are mostly

Re: SV: [Troll] Terminology bindings ... again

ckground radiation (physical force) |, 60638008 | Planetary surface craft, device (physical object) | and 242250006 | Crash landing of spacecraft (event) | and I don't need that kind of concepts at my clinic." because the simple solution is to not use what you don't need. Regards

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

a Real + units, e.g. 205ms, 89ns, 4.5min etc So I think it is quite right to standardise these two notions in the RM, and also if we can, a standard model of 'time specification' which is the '3 times/day' kind of idea. We still don't have a good solution for this last one. - thomas -- Thomas

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

On 20/03/2018 23:33, A Verhees wrote: One last remark. There is in medical context need of a datatypes to express: "do this one time a month, for example on a specific date". But technically seen, this is not a duration, the maybe a need for another datatype to express this. Using the

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

xref table referred to above is an attempt to do this. We can expand that table to include more languages/technologies, or do it some other way.  If we can use this table, it means we can avoid publishing another separate spec. - thomas -- Thomas Beale Principal, Ars Semantica <http

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

On 19/03/2018 22:25, Pablo Pazos wrote: Hi Thomas, the definition of DV_DURATION is clear to me :) The issue is on the 1.0.2 specs, I guess they used DV_DURATION in C_DURATION because the referenced Duration class in C_DURATION was not included on the specs. _This is the issue I'm pointing

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

a cleaner programmer journey would be AOM2/ADL2, even if you stick to RM 1.0.2 ;) - thomas ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

don't know why they do that - that is not what the spec says. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEH

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

On 19/03/2018 08:57, GF wrote: Again my thoughts Duration is not a Data Type in many computer languages. So we need to model it in an Archetype (Chairos) that's true, but in databases and XML it is, and it is mostly treated like a primitive data type - i.e. a non-identified, instance-only

Re: [Troll] Terminology bindings ... again

t;). When said patient travels to the United States many people will understandably ignore the "A" (as it has no meaning to them and it does not belong to the core definition of ICD-10), et voila, we've got a manufactured HIV infection. Even more dangerous situations could be construed.

Re: [Troll] Terminology bindings ... again

Of course we should contribute missing concepts - that's a given (and the mechanisms for doing so are always improving), but read my post again, that is not really the main problem with where we are now - I'm talking about strategic directions. - thomas On 14/03/2018 23:19, Mikael Nyström

Re: [Troll] Terminology bindings ... again

On 14/03/2018 14:57, Philippe Ameline wrote: Le 14/03/2018 à 12:41, Thomas Beale a écrit : so the long term solution is healthcare data and major services (workflow / process) must eventually be part of a back-end system that isn't owned by any product vendor or care delivery location

Re: [Troll] Terminology bindings ... again

bulary included, whereas we chose (rightly or wrongly) to try to connect to Snomed, LOINC and all the other published terminologies out there. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountai

Re: [Troll] Terminology bindings ... again

where the term "patient" is prohibited. I would say: the term 'patient' just gets demoted to meaning a client/supplier relationship that sporadically occurs between a person in a health system, and the health system's healthcare provider organisations. - thomas -- Thomas Beale

Re: [Troll] Terminology bindings ... again

On 13/03/2018 21:25, Philippe Ameline wrote: * So the question is: if we have formal models of the structured form such as archetypes (maybe even FHIR profiles), why bother with the grammar strings? This is a pivotal question, but you may remember that I am used to putting it

Re: [Troll] Terminology bindings ... again

later), 3. assisted coding (software helps users to code, and there are many ways of doing this, from NLP to GUI wizards). But I'm not sure if Karsten was talking about this, let's wait :) -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermou

Re: [Troll] Terminology bindings ... again

n a meta-model that makes them work for ICDx, LOINC, RxNorm, ICF, ICPC, and anything else, not just SNOMED CT. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/>

Re: [Troll] Terminology bindings ... again

rst. Grahame ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain

Re: [Troll] Terminology bindings ... again

oes it fit in the "pair of wings" to "dead horse" range? I think you have just created the new technological utility scale! -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermo

Re: Templates for application form development - should probably explain our EtherCIS/QEWDjs/PulseTile stack here

tend UX/UI framework for healthcare -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org>

Re: Templates for application form development

it?usp=sharing -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org> Chartered IT

Re: Setting thresholds

item-ID, Low value plus units, High value plus units, date of publication. -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program L

Re: Setting thresholds

On 01/03/2018 11:05, Seref Arikan wrote: Hi Diego, I'd like to hear how you'd address the requirement via a call to an external service. I don't think it should be that complicated - after all, a call out to a terminology service is already a call out to a service; terminology is just

Re: Setting thresholds

; and a "desired" range to each test result. For what that's worth. Karsten -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications

Re: Announcing Archie version 0.4

On 23/02/2018 15:36, Pieter Bos wrote: For microservices with enough traffic, or for devices with limited processing power or limited bandwidth, a binary encoding makes sense. However, GRPC would not be my first choice for OpenEHR - you would have to find a way to map all the inheritance in

Re: Announcing Archie version 0.4

days is REST APIs, which both Java and JS can do easily enough. - thomas On 03/02/2018 07:56, Peter Gummer wrote: On 1 Feb 2018, at 05:13, Thomas Beale <thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>> wrote: ... But the main interest is that we will be able

LOINC Groups

This may be interesting for those using LOINC. Help us improve LOINC Groups We need your feedback on the new LOINC Groups. There are a number of ways you can contribute. Do you know about

Re: Templates for application form development

I didn't change my mind, I was just not precise when I said that ;) - t On 20/02/2018 23:29, A Verhees wrote: So splitting up the RM instead of making it larger would be my idea. The first is not easy to do, but the second is, and helps us avoiding further problems and avoiding

Re: Templates for application form development

On 17/02/2018 21:53, A Verhees wrote: I know Thomas, but they have dependencies to other classes in the RM. To data types, to support. that should not be the case - that's exactly what we are avoiding. If we missed something it is an error. But note - most of the RM 'Support IM' model

Re: Templates for application form development

We're still working on this somewhat , using Task Planning as the excuse to finally get it right On 20/02/2018 16:44, Diego Boscá wrote: These rules/assertions are things we can express with the AM right now,

Re: Templates for application form development

On 19/02/2018 10:47, Pablo Pazos wrote: IMO annotating templates with UI info is not a good idea. A layered approach is much cleaner and scalable, i.e. to define a new artifact on top of current templates / archetypes / RM (these are also examples of layered design). here, 'templates' means

Re: Templates for application form development

.openehr.org <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.ope

Re: Templates for application form development

I've created a new wiki page here on this topic , with the original post contents as background. If others would like to share existing methods or ideas for formalisation of visual or other data sets, I

Re: Templates for application form development

ble. - thomas Also looking at the things done in the format used/shared by Marand and DIPS is an interesting input for gathering requirements. //Erik Sundvall -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcar

Re: Templates for application form development

On 17/02/2018 20:11, Pablo Pazos wrote: I think SET has a lot of applications, including result sets. Of course that should interior from LOCATABLE to be archetypable. I'm not sure on the types associated with the UI. I have a specification for UITenplates that includes some of that, I can

Re: Templates for application form development

On 17/02/2018 18:06, A Verhees wrote: If it was to me to design, I would not change the RM. In fact, I think the RM has already classes which do not belong there in my opinion. I think of AuthoredResources, TranslationDetails, they belong in the AOM.  these things are generic and are in the

Templates for application form development

ng ways to formalise such ideas in a way that would make use of existing tools and formalisms that we have. thoughts? - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthc

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

resolved internally. agree - CKM and other source management repos should be kept separate. Operational artefact repos should only include valid artefacts that are part of some release that is intended to be used with the system, including for query computations. -- Thomas Beale

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

people who work more in this area, such as your team ;) - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, o

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

://www.packtpub.com/application-development/microservice-patterns-and-best-practices -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEH

Re: Archetype pattern

On 16/02/2018 09:23, Bert Verhees wrote: I think it means, predictable paths, so data can be found by queries without even knowing exact what one is looking for. For example, the eye-colour example for a pregnant woman as Thomas gave. I changed it to iris, because iris is not often

Re: Archetype pattern

On 16/02/2018 09:48, Bert Verhees wrote: On 16-02-18 12:41, Thomas Beale wrote: - Specific Local Templates/patterns used in a defined community for specific purposes specialisations of any archetype for local usage. I don think you should ever create an archetype in the idea

Re: Archetype pattern

and that are used to construct the patterns above such as: types of Result, types of temporal meta-data, etc. Data types and Data structures part of RM. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare

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

I've been developing an abstract version of the platform definition in the background, mostly reverse-engineered from the REST API, in order to capture the pure call semantics (i.e. without HTTP protocol effects, JSON or XML serialisation etc), and in that I proposed two interfaces, one for

Re: Archetype pattern

istinfo/openehr-technical_lists.openehr.org -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org>

Re: Announcing Archie version 0.4

, which both Java and JS can do easily enough. - thomas On 03/02/2018 07:56, Peter Gummer wrote: On 1 Feb 2018, at 05:13, Thomas Beale <thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>> wrote: ... But the main interest is that we will be able to build new tools such

Re: Announcing Archie version 0.4

hetype validator and operational template creator work with both the BMM models or with metadata derived from an actual java reference model implementation. Many tests were added to ensure better conformance with the specification and many fixes have been introduced. We’d like to thank Thomas

Re: Quantities of arbitrary units in openEHR

On 30/01/2018 16:24, Pablo Pazos wrote: Hi Silje, My thinking is for your use case, DV_QUANTITY doesn't apply for arbitrary, since those seem not related with physical properties (mass, length, area, concentration, etc.) As I said, "level of X" makes me think of DV_ORDINAL. or even

Re: Quantities of arbitrary units in openEHR

think we should. That is what we currently do in the RM for fields like language and country. - thomas On 28/01/2018 23:37, Pablo Pazos wrote: Maybe we can analyze the need/implications of changing the string tour of units for a coded text in the SEC? On Jan 26, 2018 9:11 AM, "Thomas

Re: Quantities of arbitrary units in openEHR

SNOMED to the units paths in archetypes. - thomas On 27/01/2018 10:10, Bert Verhees wrote: On 26-01-18 10:00, Thomas Beale wrote: The thing I am not a fan of is that units themselves become part of terminology. This is a SNOMED direction but I think a wrong one. The reason

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

CUM-defined functionality, it would also have, for example, conversion routines from UCUM, which are usable for software defined in the UCUM essence-file." -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Heal

openEHR REST APIs - Release 0.9.0 / invitation for comments

release 1.0.0 at the end of February, at which point the formal process kicks in. Since we are in Release 0.9.0, the formal PR/CR process is not needed, and you can comment here. However, if you want to raise a PR you can, in which case, please set the Component and Affects Version fields appropri

Re: Quantities of arbitrary units in openEHR

type: I don't care about the exact unit here, but please let it be a "Mass". -Ursprüngliche Nachricht- Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org <mailto:opene

Re: Quantities of arbitrary units in openEHR

r terminology advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' all mixed up. That's why I also expect these properties to be as derived from the codes and not the other way around. -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com>

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

omething we could easily specify and implement, if there is not already one in existence. */[SG] Agree – such a  UCUM service may also be able to give a print version, e.g. /**°C instead of CEL or °F instead of **[degF]**//* */Sebastian/* *//* -- Thomas Beale Principal, Ars Semantica <

Re: Quantities of arbitrary units in openEHR

Right - at the moment, it is a 'fake' field in archetypes, enabled by being in the BMM or other expression of the RM. It's convenient to do this occasionally, since we don't think 'property' needs to be a field of DV_QUANTITY - but maybe it should be, since for some of the more esoteric units,

Re: Quantities of arbitrary units in openEHR

Ah I was being dense, I thought you were talking about the units field, not the property field. In that case, what would it mean if property were set to 'Arbitrary' - does that mean the units has to be from the current list of arbitrary units, which is not-length, not-pressure, not-everything

Re: AW: Quantities of arbitrary units in openEHR

t some information. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http://www.openehr.org> C

Re: Quantities of arbitrary units in openEHR

info/openehr-technical_lists.openehr.org -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR Foundation <http:/

Re: Are there any tutorial on ADL 2.0

ife.in/> e: dil...@healthelife.in <mailto:dil...@healthelife.in> ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Thomas Beale Princi

Using the openEHR Problem Reports tracker - voting, search, comments.

openEHR 'issues', aka Problem Reports (PRs) are located here . There are two features which the community can use on issues which can help you to help us improve the specifications more quickly. The first

Re: Extract archetypes

https://github.com/openEHR/archie/issues/8 ( Pieter On 30/11/2017, 15:23, "openEHR-technical on behalf of Thomas Beale" <openehr-technical-boun...@lists.openehr.org on behalf of thomas.be...@openehr.org> wrote: I think the string matching should be case-insensitive,

Re: Extract archetypes

I think the string matching should be case-insensitive, and the current regexes allow for any case. Various tools implementers would need to check to see if their tools match 'ehr_extract' to 'EHR_EXTRACT' etc. - thomas On 30/11/2017 13:55, Bert Verhees wrote: So, there are also

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