Re: Extract archetypes

I spoke too fast - the ARCHETYPE_HRID syntax is specified here in the Archetype Identification spec. <http://www.openehr.org/releases/AM/latest/docs/Identification/Identification.html#_human_readable_identifier_hrid> On 30/11/2017 13:40, Thomas Beale wrote: The ADL 1.4 identifier

Re: Extract archetypes

<mailto:verat...@veratech.es>. ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing l

Updates to UML, package paths; new global class index.

global UML site <http://www.openehr.org/releases/trunk/UML/> has been updated to include these changes. The CR SPECPUB-6 <https://openehr.atlassian.net/browse/SPECPUB-6> documents this update. -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant,

Re: UCUM

that on ;-) Grahame -- 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 Profes

Re: UCUM

responding Thanks, I wonder, should such a server get funding to run in a professional hosting-environment. I never thought this was maintained by private persons. I think we must be thankful to Gunther for doing this. -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.

Re: Blockchain

d for the RM (I've added a note to this to cover the requirement to safely refer to / ?copy content from external systems). We need to consider these kind of reference questions more carefully and provide more comprehensive solutions for sure. - thomas -- Thomas Beale Principal, Ars Sem

Re: Blockchain

. Maybe this will change and blockchain will find use there. - thomas On 13/11/2017 13:15, Bert Verhees wrote: On 13-11-17 14:02, Thomas Beale wrote: ... What openEHR has as an underlying data management paradigm is distributed version control - each EHR is like a little git repo

Re: Blockchain

, not to fake transactions. Not what blockchain was designed for (and it's more or less the opposite regarding privacy). - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/>

Re: Scenarios for change type "deleted"

On 04/11/2017 18:38, Bert Verhees wrote: But also apart from that. The discussion is if a standard should facilitate an inactive patient (logical deleted) to still remain in the active clinical information system with a special flag or that he should be transferred to an archive system.

Re: Scenarios for change type "deleted"

On 04/11/2017 15:47, GF wrote: Even when the patient wants all data to be removed, this means removeal in the context of the provision of helath care. For legal and administrative purposes the data can NOT be removed but be available for these non-healthcare provision related circumstances.

Re: Scenarios for change type "deleted"

On 04/11/2017 14:20, Bert Verhees wrote: Gérard has some points. A patient, in the Netherlands, has under conditions the right to require the physical removal of all data. In that case no "deleted" marker is necessary. Then there is the case of inactive patients. In case of a GP the law

Re: AQL for multi-occurrence nodes

Dileep, see here . But I suggest you post this question on the implementers list to see if

Re: Scenarios for change type "deleted"

It's potentially not a completely wrong idea: it might be worth thinking about a 'deleted' marker on the VERSIONED_OBJECT type itself. As i noted before though, i'd like to get a better idea of real scenarios where the current model of deletion doesn't work properly before doing anything. -

Re: Scenarios for change type "deleted"

On 15/10/2017 12:49, Pablo Pazos wrote: Hi I'm trying to define a set of rules for a logical delete commit and have some gray areas that I'm not sure of. *1. commit after delete flow* [creation v1] => [modification v2] => [deleted v3] => ? Can a modification/amendment v4 happen after a

Re: AQL for multi-occurrence nodes

ge etc, please respond here, there are answers for that as well. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead, openEHR

Re: Using Other Constraints in Slots

391-2129 F +49 (0)531 391-9502 birger.haarbra...@plri.de http://www.plri.de ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Thomas Beale Princip

Re: [openEHR SEC] CONTAINS in AQL

g list openEHR-technical@lists.openehr.org <mailto:openEHR-technical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> ____

Re: CONTAINS in AQL

Hi Pablo, CONTAINS is like the '//' operator in Xpath - it's matches the thing on the right hand side, anywhere under the object on the left hand side. So doing COMPOSITION CONTAINS OBSERVATION and similar things is normal. The AQL documentation may need to be fixed. - thomas On

Re: Suitable data type to record frequency of something happening

On 28/09/2017 18:21, Dileep V S wrote: Hi, I need to record the frequency of occurrence of an event.Typical readings will be like 2/day, 5/week, 1/month etc.In archetype editor I could not find a suitable property to use under quantity. The count also does not work as it does not have a

Re: New interim release of ADL Workbench.

ewhere in Nedap? (Pieter Bos might answer here) I don't think there is yet an XSD or anything like that, although it would not be hard. - thomas On 20/09/2017 13:32, Diego Boscá wrote: I was referring to the schema to the bmm model/format itself :) 2017-09-20 14:29 GMT+02:00 Thomas Beale <

Re: New interim release of ADL Workbench.

"? Regards 2017-09-20 12:31 GMT+02:00 Thomas Beale <thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>>: I have released a new version of the ADL Workbench (build 2.0.6.2934 <https://openehr.atlassian.net/browse/AWBPR-64>) which fixes various problems,

New interim release of ADL Workbench.

was included in the previous build. The above link is a 64-bit build for Windows (7, 8, 10 etc). We'll post a Mac version as soon as possible. - thomas beale ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mail

openeHR Specifications Editorial Meeting Aug 28/31 - RFI

priority%20DESC%2C%20updated%20DESC> first - if your burning issue is there, please add more comments or detail on the relevant issue. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://

Terminology bindings ... again

plication to the Terminology service. I'd rather avoid the last, because of the brittleness of intensional ref-set query syntax expressions. In any case, we need a better idea of what meta-data are needed. E.g.: * something to do with (min) version of terminology required for the referen

Re: openEHR-technical Digest, Vol 64, Issue 6

Hi Gerard, On 07/06/2017 07:46, GF wrote: Dear Silje, Questions in questionnaire are observations. But what is it, when a Scale makes use of existing data in the database and calculates an aggregate result? (E.g. BMI) Isn’t the latter an evaluation of existing observations by means of a

Re: AOM 1.4 - Archetype.uid a UUID or OID?

On 16/06/2017 21:13, Bert Verhees wrote: UID can also be INTERNET_ID, and the "extension" and double colon are not required, so the HIER_OBJECT_ID cannot represent anything, but it is a lot. Of course it is a matter of taste, maybe there are good arguments to make the archetype.uid

Re: AOM 1.4 - Archetype.uid a UUID or OID?

change it to its common practical use, which is UUID. Best regards 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

Re: AOM 1.4 - Archetype.uid a UUID or OID?

from here : Two machine identifiers are defined for archetypes. The|ARCHETYPE|.|/uid/|attribute defines a machine identifier equivalent to the human readable|ARCHETYPE|.|/archetype_id/|.|/semantic_id/|,

Re: openEHR-technical Digest, Vol 64, Issue 19

EHR wants to play some role in this, handle OIDs so that communication partners can understand you. Such decisions should be based on rational underpinnings, not on biased preference. Vriendelijke groet, Dr. William Goossen -- Thomas Beale Principal, Ars Semantica <http://www.arsseman

Re: AOM 1.4 - Archetype.uid a UUID or OID?

On 15/06/2017 02:17, Heath Frankel wrote: Hi Thomas, Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value attribute of type UID, which may be either UUID, ISO_OID or INTERNET_ID. Right. I was

AOM 1.4 - Archetype.uid a UUID or OID?

wrong, and we should update it from 1.4.2 to 1.4.3, i.e. treat this as an error correction. Could tool makers check this issue and report here? thanks - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Health

Re: Major update to openEHR Task Planning (workflow) draft specification

to make it clear for the reader. But if the short name is a requirement, a more correct name would be "task management", since it includes planning, execution, and maybe other processes / states associated with tasks. On Tue, Jun 13, 2017 at 3:55 AM, Thomas Beale <thomas.be..

Re: Major update to openEHR Task Planning (workflow) draft specification

Hi Pablo, well we needed a short name. The idea we had so far is that the primary theme of this specification is 'planning'; execution etc comes as a logical consequence. - thomas On 13/06/2017 03:32, Pablo Pazos wrote: Shouldn't "task planning" be "task planning and execution"? in

openEHR UML website updated to latest

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

Re: Major update to openEHR Task Planning (workflow) draft specification

On 07/06/2017 19:03, Thomas Beale wrote: A new version is now up, with substantial rework on the runtime classes, also other new sections elsewhere in the document. - thomas with link <http://www.openehr.org/releases/RM/latest/docs/task_planning/task_planning.h

Re: Major update to openEHR Task Planning (workflow) draft specification

A new version is now up, with substantial rework on the runtime classes, also other new sections elsewhere in the document. - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealt

Re: Major update to openEHR Task Planning (workflow) draft specification

Hi Pablo, thanks for the comments. On 04/06/2017 03:28, Pablo Pazos wrote: Hi all, here is my first review: Section 2 a. Try to link the concept of task / task list with worklist item / worklist commonly used in imaginology flows and DICOM terminology. I've added a new section

Re: openEHR-technical Digest, Vol 64, Issue 6

for individual follow up measures. a simple question, answer, even with some total score, does usually not have such evidence base. I agree that in the data / semantic code representation in a detailed clinical model it is not different. -- Thomas Beale Principal, Ars Semantica <h

Major update to openEHR Task Planning (workflow) draft specification

20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC>, for typos, general errors. Clinical people may like to look at the requirements, and are of course welcome to common on anything else as well. - thomas -- Thomas Beale Principal, Ars Semantica <http:/

Re: Reports - a new openEHR RM type?

On 31/05/2017 01:37, Diego Boscá wrote: About "report": Maybe we just need a subclass of Folder that contains a "Locatable" (0..*) attribute. Shouldn't break things too much. Maybe going the FHIR way is also feasible: Create a new class with a Folder and a container of locatables that can

Re: Reports - a new openEHR RM type?

This seems main to be about questionnaires as well - can I suggest a separate thread for that discussion? thanks - thomas On 31/05/2017 00:37, GF wrote: There are several kinds of context archetypes/templates and their meta-data are used for: - de novo data - re-used data - step in the

Re: Reports - a new openEHR RM type?

On 30/05/2017 22:54, Pablo Pazos wrote: Hi Thomas, Thinking about the hierarchy, at which level will be a Report be? Below compo? Below entry? Structure? Representation? It is probably a COMPOSITION or specialised form of COMPOSITION - see the class DOCUMENT_COMPOSITION on the wiki page,

Reports - a new openEHR RM type?

plans. Comments and reactions welcome on the wiki page or here. thanks - thomas -- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com> Consultant, ABD Team, Intermountain Healthcare <https://intermountainhealthcare.org/> Management Board, Specifications Program Lead,

Re: SNOMEDCT - correct representation

We should not understand the namespace "snomed-ct" in this way; instead it should resolve to whatever SNOMED there is in the local termology service, which might be some Norway national thing, or Spanish regional server etc. So the expected national extensions and translations would be

Re: SNOMEDCT - correct representation

Hi Pablo, for clinical modellers I completely agree. It is mostly technical people - tool writers who work with the syntax form of things. But at the end of the day, it is them who build the systems and who must understand every last subtlety of the semantics of any of the languages we use -

Re: SNOMEDCT - correct representation

:24, Bert Verhees wrote: On 16-05-17 18:14, Thomas Beale wrote: sure. But there are a lot that do, just not the ones you know ;) We have to make things work for everyone. So what about my suggestion a few weeks ago, to add a comment-section to a terminology-binding url to explain what the url

Re: SNOMEDCT - correct representation

is for limitations on the modeling tools, or maybe they are cyborgs in disguise. On Tue, May 16, 2017 at 1:14 PM, Thomas Beale <thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>> wrote: sure. But there are a lot that do, just not the ones you know ;) We have to make

Re: SNOMEDCT - correct representation

soon become unavoidable in an EHR application, and that it is urgent to find a solution for this. Best regards Bert Verhees Op 3 mei 2017 16:45 schreef "Diego Boscá" <yamp...@gmail.com <mailto:yamp...@gmail.com>>: well, nothing stops you for not encoding the query in

Re: SNOMEDCT - correct representation

things readable enough http://snomed.info/ecl/descendantOrSelfOf <http://snomed.info/ecl/descendantOrSelfOf> 73211009 |Diabetes mellitus| 2017-05-03 14:20 GMT+02:00 Thomas Beale <thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>>: ___

Re: SNOMEDCT - correct representation

Language, which keeps things readable enough http://snomed.info/ecl/descendantOrSelfOf <http://snomed.info/ecl/descendantOrSelfOf> 73211009 |Diabetes mellitus| 2017-05-03 14:20 GMT+02:00 Thomas Beale <thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>

Re: SNOMEDCT - correct representation

On 03/05/2017 14:04, michael.law...@csiro.au wrote: I think this thread has gone a little off the rails. There are predefined (by FHIR) URIs for value sets that are defined just as descendants of a single concept, or members of a reference set. For an enumeration of concepts and/or a

Re: SNOMEDCT - correct representation

On 03/05/2017 13:31, Diego Boscá wrote: Or just use the "Long syntax" as described in point 5.2 from Expression Constraint Language, which keeps things readable enough http://snomed.info/ecl/descendantOrSelfOf 73211009 |Diabetes mellitus| at the very least, a %20 is needed for the spaces,

Re: SNOMEDCT - correct representation

Please consider the language used when posting. /Daniel On May 3, 2017 13:03, Bert Verhees <bert.verh...@rosa.nl> wrote: On 03-05-17 12:53, Thomas Beale wrote: On 03/05/2017 11:40, Bert Verhees wrote: On 03-05-17 12:36, Thomas Beale wrote:

Re: SNOMEDCT - correct representation

On 03/05/2017 11:40, Bert Verhees wrote: On 03-05-17 12:36, Thomas Beale wrote: The only missing part, now that I look at the SNOMED Compositional Grammar <https://confluence.ihtsdotools.org/display/DOCSCG> and Expression Constraint Language <https://confluence.ihtsdotools.or

Re: SNOMEDCT - correct representation

ding in ADL2 <http://www.openehr.org/releases/AM/latest/docs/AOM2/AOM2.html#_terminology_package>) from a post-coordinated expression or constraint expression. This should be trivial, but I don't see where SNOMED has specified it. - thomas On 03/05/2017 11:23, Thomas Beale wrote: Hi Kora

Re: SNOMEDCT - correct representation

Hi Koray, On 03/05/2017 10:41, Koray Atalag wrote: Hi again, I’ve been snowed under for a while and just now catching up with this…I reckon there was a suggestion that we do not include SNOMED codes within archetypes, or more specifically post-coordinated expressions, if I understand

Re: SNOMEDCT - correct representation

ter <http://eepurl.com/b_w_tj> ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org <mailto:openEHR-technical@lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Ian McNicoll __

Re: Add SNOMED codes to values in Internal code set

fe.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* Management Board, Specifications Program

Re: Random / Synthetic Data Generation over Templates

Pablo, is that a tool we can list on the openEHR tools page ? - thomas On 13/04/2017 10:59, Pablo Pazos wrote: Hi, I have developed a tool that does that, is the openEHR-OPT project in my GitHub account (ppazos). On Apr 13, 2017 12:37 PM,

Re: Template specs

Hi Jan-Marc, I think you will find what you need via the links in the 'ITS' table, lower down the specifications jump page . - thomas On 03/04/2017 10:02, Jan-Marc Verlinden wrote: Hi all, We are looking for the opt and oet

Re: inheritance of archetypes

well the problem with continuing to use ADL 1.4 is the in a) weaknesses modelling semantics (much weaker in 1.4) b) errors caused by lack of differential representation of specialised archetypes (a major problem) and c) different representation of templates (in ADL2 they are built-in).

Re: inheritance of archetypes

On 01/03/2017 10:00, Bert Verhees wrote: Op 1-3-2017 om 10:44 schreef Thomas Beale: Good news Thomas, but don't bring it with disdain. I don't know what the words means ;) I got it from google translate, in French it is dedain. c'était une blague... that appears to be a PR about GDL

Re: inheritance of archetypes

we may be able to re-use ideas from the Intermountain Healthcare Activity-Based Design (ABD) project I am working on in the US, which includes presentation specification in its archetypes (they are not ADL archetypes, but something similar). On 01/03/2017 09:26, Anastasiou A. wrote:

Re: inheritance of archetypes

On 01/03/2017 09:35, Bert Verhees wrote: Good news Thomas, but don't bring it with disdain. I don't know what the words means ;) Op 1-3-2017 om 10:15 schreef Thomas Beale: which when they are read into ADL Workbench, are re-engineered into differential form I think the ADL Workbench

Re: inheritance of archetypes

On 01/03/2017 09:03, Bert Verhees wrote: Dear all of the technical mailing list, I made a new message tothis list (specialized ;-), so it will be discussed separately. I do that because in the other message, I describe a real problem which needs a solution, and this message is about

better diagram for 'clinical investigator recording process'

I have created a newer version of the oft-copied and used diagram on clinical process , as part of progressively upgrading diagrams in various specification documents. Source is in draw.io format; here are

Re: FOR REVIEW: Proposed major RM extension specification - Planned Tasks

The ISSUEs mentioned in the draft spec are now tabled on the wiki page for commenters' use. - thomas ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: ELEMENT.null_reason proposal

Diego, I think this is the same as * extending the current openEHR null_flavour code set, and making it hierarchical OR * allowing other local code-sets to be used in that slot. o if these codes were understood as proper local extensions of the openEHR code-set, i.e. any new

ELEMENT.null_reason proposal

Silje has just pinged me again on the question of whether we should have an ELEMENT.null-reason or similar attribute to accommodate specific reasons for null_flavour being set. There are 3 PRs on this as follows: * SPECPR-41 - Enable

Re: Use of RM:provider

Ideally there would be one or more classifiers at the ENTRY level, something that does not exist today. There are some others that we will include, e.g. relating to epistemic_status. I would follow Ian's suggestion on the extension slot; it may be that the coding recorded there may need to

Re: Runtime name suggestions?

Hi Silje, I'm not sure enough of the requirement, but this ADL logic may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just before the following heading after that section. The

Re: Use of RM:provider

Hi Silje, there is no immediate equivalent of these codes, which have indirect equivalents, i.e. 1. Result = OBSERVATION; provider = lab; limited to certain archetypes; also comes under SOAP 'O' Heading 2. Observed by physician = OBSERVATION, provider = PARTY_IDENTIFIED (physician);

Re: Better approach for announcements, forums?

On 04/01/2017 13:53, Bert Verhees wrote: My issue is that for people running incidental business or incidental income, maybe only a few thousands a year, 650 Euro is really a lot of money. Of course for real business, with employees and so on, 650 is nothing. Those people running incidental

Re: Better approach for announcements, forums?

On 04/01/2017 12:18, Bert Verhees wrote: Please, Ian, also discuss an announcementlist for free and open source software (my favour is read-only, announcements only), and, also your own suggestion, to have a low fee membership for single person or low income business Bert, I would

Better approach for announcements, forums?

Following from what you and Bert have said, it seems that the following could make sense: * Foundation announcements list / channel (= openehr-announce list we have now) * software / libraries / tools announcements (= web home page news items with cog icon, also here

Re: Cloud EHRServer is about to be launched

It may be that we need a community-based announce list as well. We'd have to think of some rules to make sure it was low volume, useful and balanced. - thomas ___ openEHR-technical mailing list openEHR-technical@lists.openehr.org

Re: SV: Could the specs group consider making uid mandatory?

On 16/12/2016 02:37, Bjørn Næss wrote: If you add UID on ENTRY level and you want to use that for some referencing/look up functionality: How do you handle versioning of Compositions and its content? Is it a new entry UID for each version ? same UID across versions. There is a way to

Re: Could the specs group consider making uid mandatory?

right. Good argument from evidence for the UID. Want to create a PR with these notes? Not sure about mixing URIs with UIDs... OTOH, usually easy to detect by parsing. - thomas On 19/12/2016 09:22, Heath Frankel wrote: I think it should be a strong recommendation rather than mandatory

Re: Could the specs group consider making uid mandatory?

I also think that would be a good idea, since ENTRY = clinical statement. We could make it an openEHR rule. - thomas On 14/12/2016 00:24, Ian McNicoll wrote: There may be some advantages in routine application of uid at ENTRY level. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office

Re: Could the specs group consider making uid mandatory?

On 13/12/2016 23:46, Seref Arikan wrote: My preferred scenario would be to have an identifier on every node indeed. Not having that, I could live with identifiers for at least some types, such as entry subtypes and a few more. If it cannot be UID, so be it. What is the meaning of overhead

Re: Could the specs group consider making uid mandatory?

https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-91?filter=allopenissues On 13/12/2016 23:01, Boštjan Lah wrote: On 13 Dec 2016, at 12:36, Thomas Beale <thomas.be...@openehr.org> wrote: On 13/12/2016 22:27, Pieter Bos wrote: Generally the top-level structures will have

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

Re: RM Participations name/role?

. On Wed, 23 Nov 2016 at 17:32, Thomas Beale <thomas.be...@openehr.org <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

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

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

technical-boun...@lists.openehr.org> on behalf of Thomas Beale <thomas.be...@openehr.org> *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 _

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

Re: SV: More generic reference model

my iPhone On 13 Sep 2016, at 1:23 AM, Thomas Beale <thomas.be...@openehr.org> 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

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

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

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

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

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 additional

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

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

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

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.

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

, 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 committees

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