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

Re: More generic reference model

e 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 SNOMED CT had existed we would have done pretty much the same t

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

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.openehr.org> Chartered IT Profes

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

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

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

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

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

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

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

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

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

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

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 ___

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

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

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

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,

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 Technolog

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

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

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

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

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

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

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

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

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

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

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

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

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

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 <thomas.be...@openehr.org <mailto:thomas.be...@openehr.org&g

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

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

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?

... - 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 were going

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

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?

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

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

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

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

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

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

Re: Usage of Compositoin.Category

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 Beale* Management Board, Specific

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.

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

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

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

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

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

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,

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

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

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

Re: Archetype relational mapping - a practical openEHR persistence solution

This is correct. The usual way I do this with an object model is to create a set of P_XXX classes, where 'P_' means 'persistent form'. The P_ classes are a transform of the main IM (whatever it is) that does things like * stringifying a lot of low-level fields * ignoring derived fields *

Re: Archetype relational mapping - a practical openEHR persistence solution

based on a quick look, my reaction is the same, unless they have some very interesting Archetype => Schema transformation. On 25/01/2016 14:25, pazospa...@hotmail.com wrote: I talked about this approach with a colleague from China during MEDINFO. The problem is your schema grows with your

concept maps (Cmaps) for archetyping?

this group of researchers appears to have created an approach to modelling health information using something a bit more powerful than mindmaps. They seem to know about CDA but not openEHR. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3833511/pdf/gahmj.2012.1.4.003.pdf - thomas

Re: New EHRServer v0.5 and roadmap

Hi Pablo, I watched the latest video, very nice. Why not consider a revoiced version in English some time? I think it's mature enough to start trying to get a wider audience. - thomas On 14/01/2016 05:42, pablo pazos wrote: Hi all! I'm very excited to share the good news with all my

Specifications Committee meeting Feb 2016 - have your say

There will be a SEC (Specifications Editorial Committee ) face to face meeting in Stockholm 11 and 12 February. This will do its usual work of considering next releases, processing Problem Reports (PRs), Change Requests, and

Re: Trial of openEHR's own 'stackExchange' on the openEHR wiki

Bert, were you logged in? On 06/01/2016 09:33, Bert Verhees wrote: On 06-01-16 09:07, Bakke, Silje Ljosland wrote: one of the features we don't use on the wiki is 'Questions', which you can see here . There seems to be an authorization-problem,

Re: Trial of openEHR's own 'stackExchange' on the openEHR wiki

On 07/01/2016 17:12, Bert Verhees wrote: On 07-01-16 17:28, Thomas Beale wrote: I changed the wiki so that Questions is now visible read-only to non-logged in users. I have checked that this works on a test machine. Works OK now. What makes me doubt is a very obvious competition-figure

Trial of openEHR's own 'stackExchange' on the openEHR wiki

one of the features we don't use on the wiki is 'Questions', which you can see here . This supposedly is the same kind of function as StackExchange, which we didn't get off the ground. So maybe we should try locally. My proposal would be for

Re: CAMSS assessment of openEHR

Hi Silje, I had a look at the website - it doesn't seem as if anyone is using CAMSS much, if we believe this page, which contains CAMSS assessments , none of which are health related. On this page

Re: CAMSS assessment of openEHR

hnical [mailto:openehr-technical-boun...@lists.openehr.org] *On Behalf Of *Thomas Beale *Sent:* Monday, January 4, 2016 2:57 PM *To:* openehr-technical@lists.openehr.org *Subject:* Re: CAMSS assessment of openEHR Hi Silje, I had a look at the website - it doesn't seem as if anyone is using CAMS

Making FHIR work for everybody

Here is a blog post on a proposal for making FHIR work more easily with other health information architectures , including openEHR, which may interest some people here. - thomas ___

Re: Specialization depth

ARCHETYPE_ID is for AOM 1.4, ARCHETYPE_HRID is for AOM 2.0 We will rationalise all these classes in to the BASE component in Release 1.1.0 of the RM. - thomas On 17/12/2015 07:24, Bert Verhees wrote: On 16-12-15 14:05, Thomas Beale wrote: that's why it is gone in ADL2/AOM2. The new

Re: Specialization depth

The error messages are actually in ODIN format, which can accommodate EN-US as well as EN, if we really want to bother with that. - thomas On 17/12/2015 07:16, Bert Verhees wrote: For US/international English spelling, we tend to use International English for all natural language, and

Re: Specialization depth

On 16/12/2015 10:54, Bert Verhees wrote: On 16-12-15 11:37, Diego Boscá wrote: but there is an example of an specialized identifier in that same document e.g. "uk.nhs.clinical::openEHR-EHR-SECTION.t_encounter_report-vital_signs_headings-0001.v1" in

Re: Specialization depth

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

Re: Specialization depth

This is not a specialised identifier, it's just an identifier that has '-' characters in it, which in ADL2 are not special. Just look at the id1.x code of the root node to get the specialisation depth of any ADL2 archetype. - thomas On 16/12/2015 10:37, Diego Boscá wrote: but there is an

ADL 1.4 specification - now in Asciidoctor format

The old ADL 1.4 spec is now online in the new format. This was done primarily to: * fix various formatting * fix syntax rendering * provide a source form of the ADL 1.4 spec in case interim releases between 1.4 and 2.0 are

Re: Party-actor-folder relationships in hierarchy

A couple of words of advice: normally, EHR and demographics 'databases' would be separated for security and operational reasons. EHRs are not normally 'inside' any demographic entities. This section

Re: Party-actor-folder relationships in hierarchy

Hi Bert, there is no 'policy' about treating the Demographics specification as 'inferior'. The practical point about demographics is that it is often not implemented because many clinical IT environments already have an MPI, so an openEHR EHR system typically implements the

openEHR RM Release-1.0.3 - EHR Extract - SURVEY OF USE

*If your organisation or implementation uses the openEHR EHR Extract specification PLEASE READ THIS.* Release-1.0.3 is getting close. For those with too much time on their hands, you can follow progress here on Jira . We have

Re: Binding to multiple terminologies / code systems

Dave, the solution to this situation is not yet 100% clear in ADL2 (it is in ADL1.4, as others have described). We are trying to define a cleaner way to represent it in ADL2, but I'm still not clear on the requirements. It appears that the scenario you have is that since SNOMED CT, READ and

OPT2 specification, choosing terminology bindings...

One of the final things to get right in ADL2 is how to choose terminology bindings, also languages and a few other settings when going from source archetypes and templates to the OPT. I have put up a draft OPT2 specification with

Re: OPT2 specification, choosing terminology bindings...

looks like sharing SVGs in email is not a good idea... 2nd go ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Binding to multiple terminologies / code systems

On 30/10/2015 16:00, Barnet David (HEALTH AND SOCIAL CARE INFORMATION CENTRE) wrote: Thomas For use (NHS in England) it’s probably at the template level (but it would be good to occasionally specify at the node level). just to be clear on this point, because this is the one I want to

Re: Binding to multiple terminologies / code systems

The answer isn't completely simple. Some background here . If there are bindings defined for snomed_ct, read2 and ctv3 to the ac-code that appears in the archetype definition section, and no further

Re: Archetype publication question - implications for implementers

As a reminder, the current draft spec on versioning and lifecycle is here, and as usual, comments are welcome

Re: Archetype publication question - implications for implementers

Hence my earlier proposal... On 19/10/2015 09:18, David Moner wrote: 2015-10-16 3:22 GMT+02:00 Heather Leslie >: ·It means that new implementers can use the corrected v1 revision and we don’t have to

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

surely the obvious approach is that the stored field contains the UCUM case-sensitive code, and that applications / services use UCUM tables to render whatever display form is asked for in a client call? (I realise openEHR archetypes are not doing this; they should be...) there's another

Re: Archetype publication question - implications for implementers

I've skimmed the replies on this thread, and I'm inclined to think everyone could be right. Problem is, they can't all be right at the same time. So considering the issue from a global deployment perspective I had the folllowing idea: * in the archetype library, we should stick to

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