Re: FHIR-like terminology 'binding strengths'?

hi Tom > well we need to be precise about what 'extended' means. If you add first > level siblings to the previous version of your value set, it means your > value set was incomplete when published. > yes. and that's the point. The world gets by on incomplete agreements > If you want to add chil

Re: FHIR-like terminology 'binding strengths'?

t a valid > use case in the future and I see some value in aligning with the FHIR > options (if HL7 allow us to do that) even if we only support a subset. > > > > Regards > > > > Heath > > > > *From:* openEHR-technical *On > Behalf Of *Grahame Grieve > *

Re: FHIR-like terminology 'binding strengths'?

hi Tom We did not define extensible bindings because we like it. Using it creates many issues and it's problematic. We defined it because it's a very real world requirement, in spite of it's apparent 'unreliability'. The use cases arises naturally when - the approval cycle of changes to the value

Re: MEDINFO 2019, Lyon, France.

> > Over the years I’ve attended so many Ed & Chuck sessions where they have > provided informative updates on HL7 activities. > ok. > Perhaps you missed my suggestion for a “Panel exploring how openEHR, FHIR > & SNOMED work together – a cross SDO panel”? > I did miss that, yes. > Why don’t yo

Re: MEDINFO 2019, Lyon, France.

> > It will likely be a useful counter to the usual HL7 panels that run each > conference. > out of interest, what are those? do you want to continue to act 'counter' to HL7, or is there a different future? Grahame ___ openEHR-technical mailing list op

Re: [Troll] Terminology bindings ... again

> > > > I am get the impression that SNOMED CT is hard to implement, and therefore > wondered if we are at some kind of tipping point, like where HL7v3 was a > few years ago, and some bright spark came along, and now we have FHIR that > is gaining great traction in the health community due to the e

Re: [Troll] Terminology bindings ... again

hi Philippe No one who's actually tried to use Snomed CT could think that in it's current form it's the answer to everything. But anyone who's tried to work on real terminologies must also be aware of just how much work is involved in these things. So there's very much a glass half full/empty thi

Re: UCUM

I’m sure Gunther would enjoy it if you helped out with some funding :-) I’ll pass your thanks on Grahame > On 20 Nov 2017, at 8:27 pm, Bert Verhees wrote: > >> On 20-11-17 02:58, Grahame Grieve wrote: >> Gunther says that the server had crashed, and he thinks it's memor

Re: UCUM

I won’t pass that on ;-) Grahame > On 20 Nov 2017, at 9:09 pm, Thomas Beale wrote: > > > openEHR would be happy to host it. I'm sure Gunther would lve that. > >> On 20/11/2017 09:27, Bert Verhees wrote: >>> On 20-11-17 02:58, Grahame Grieve wrote: &

Re: UCUM

Gunther says that the server had crashed, and he thinks it's memory related. He's put a process in place to email him when it stops responding Grahame On Sun, Nov 19, 2017 at 7:37 PM, Bert Verhees wrote: > On 19-11-17 09:31, Ian McNicoll wrote: > >> Does not work here either, Bert. The whole s

Re: Aw: Re: Blockchain

> > > Agreed, but a third party that would just be in charge of making certain > that the blockchain is unaltered has nothing to do with the business > involved. It is a technical trusted party, and there is no true reason it > should be expensive (for example, it could publish the hash of the > bl

Re: Aw: Re: Blockchain

bitcoin doesn't use a reduced proof of work. That's the costly feature of it, and why it's genuinely distributed. Grahame On Wed, Nov 15, 2017 at 2:55 AM, Bert Verhees wrote: > On 14-11-17 16:39, Grahame Grieve wrote: > >> either you end up falling back to a

Re: Aw: Re: Blockchain

> > In the healthcare related blockchain ideas or prototype implementations I > have heard about so far something different than proof of work is used, for > example proof of authority. That has other drawbacks and challenges, but it > does not suffer from the same power consumption problems. > th

Re: Blockchain

> > In FHIR I think that discussion will come very sooner, because, it is > about messaging, and also, it describes technical layers. > yes it did. I'm sceptical there for the same reasons. You can track the discussion if you are interested: https://chat.fhir.org/#narrow/stream/blockchain Grahame

Re: Blockchain

I am sceptical of most use cases of block chain outside payments witnessing in some limited trading schemes. There are 2 inter-related problems. - block chain is a very inefficient solution to a problem that largely does not exist in healthcare: untamperable evidence that something happened, in th

Re: Blockchain

what would it do? Grahame On Mon, Nov 13, 2017 at 10:46 PM, Bert Verhees wrote: > How are the plans about blockchain for OpenEhr? Is there any plan to > incorporate it in the standard, or is it regarded as a technical > implementers business? > > Bert > > >

Re: Questionnaires

hi Heather > A generic question/answer pattern is next to useless - interoperability is really not helped I think you should rather say "A generic question/answer pattern is only useful for exchanging the questions and answers, and does not allow re-use of data". This is not 'next to useless for

Re: Could the specs group consider making uid mandatory?

> > Not sure about mixing URIs with UIDs... OTOH, usually easy to detect by > parsing. > there's a URI format for UIDS: urn:uuid:{lowercase} That's the best to handle mixing them Grahame > - thomas > > On 19/12/2016 09:22, Heath Frankel wrote: > > I think it should be a strong recommendation ra

Re: openEHR and terminology servers

Hi All, >>>> >>>> so I'll start: >>>> At Linköping University we did a demonstrator in 2012 using a homebrew >>>> REST interface to an expression repository based on the SNOMED CT query >>>> language at the time. The demonstrator s

Re: openEHR and terminology servers

hi Daniel I'll listen to this discussion with interest. I expect that the answer will be: same functional needs as already covered by FHIR terminology services, but there's some additional information features that are needed to enable seamless integration. Grahame On Fri, Dec 2, 2016 at 7:50 P

Re: SV: More generic reference model

http://hl7.org/fhir/2016Sep/valueset-operations.html#expand, see params offset and count Grahame On Tue, Sep 13, 2016 at 3:27 PM, Thomas Beale wrote: > Grahame, > > can you post a URL to that functionality / spec? > > thanks > > - thomas > > > On 12/09/20

Re: SV: More generic reference model

as 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 terminology server part of >> the local system, and have the resolution a dynamic one between the >> systems

Re: SV: More generic reference model

The best way to resolve this is to make the terminology server part of the local system, and have the resolution a dynamic one between the systems. That allows you to optimise the performance implications of large value sets. Grahame On Tue, Sep 13, 2016 at 1:21 AM, Thomas Beale wrote: > Bert,

Re: SV: More generic reference model

FHIR terminology servers can (and mostly do) handle all of those terminologies, though I don't know if anyone has handled ICF in practice. And expansions can preserve is-a relationships if you want, though... life is complicated and the answer is not automatically 'yes' Grahame On Mon, Sep 12,

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

ject line so it is more specific >> than "Re: Contents of openEHR-technical digest..." >> >> >> Today's Topics: >> >> 1. Re: UCUM code in body temperature archetype (Ian McNicoll) >> 2. Re: UCUM code in body temperature archetype (Grahame

Re: UCUM code in body temperature archetype

data-oriented Quantity type >- a bunch of if/else code to treat different Quantity 'types' >differently >- I have to move the operators out to another level, because they no >longer make sense for this new style of Quantity > > So, in terms of what we do

Re: UCUM code in body temperature archetype

maintainable code > in the long run. > > The final result may not be particularly differentiated on the screen, or > even consciously understood by end users, but they are miles away from the > models and code inside the systems we build. > - thomas > >> On 18/05/2016 12

Re: UCUM code in body temperature archetype

wise don't differentiate them Grahame > On 18 May 2016, at 9:41 PM, Thomas Beale wrote: > > >> 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 a

Re: UCUM code in body temperature archetype

Really? No one has ever brought that to us as an requirement Grahame > On 18 May 2016, at 9:48 PM, Diego Boscá wrote: > > And we probably want that the human-readable form can be multilingual as well. > > 2016-05-18 13:41 GMT+02:00 Thomas Beale : >> >> On 18/05

Re: UCUM code in body temperature archetype

The main problem is that ucum units are not human readable units, and trying to force them to be will generate substantial pushback from end users. In USA, this is an open problem for CDA adoption. In Australia, I solved it by declaring that we would never retire valid ucum units in CDA. A seco

Re: UCUM code in body temperature archetype

IC > Hon. Senior Research Associate, CHIME, UCL > >> On 18 May 2016 at 10:11, Grahame Grieve wrote: >> That's overkill - just have two fields, human and computable units. >> >> Grahame >> >>> On 18 May 2016, at 7:05 PM, Daniel Karlsson wrote: &

Re: UCUM code in body temperature archetype

That's overkill - just have two fields, human and computable units. Grahame > On 18 May 2016, at 7:05 PM, Daniel Karlsson wrote: > > So, right now the DV_QUANTITY.units is a String, perhaps it should be > DV_CODED_TEXT? > > /Daniel > >> On 2016-05-18 10:25, Bakke, Silje Ljosland wrote: >> Th

Re: openEHR-Based PhD Thesis Successfully Defended

hi Nadim FHIR was created July 2011, but you couldn't possibly have used it as a base for this kind of PhD until maybe this year. btw. well done. Grahame On Thu, Mar 10, 2016 at 9:48 PM, Nadim Anani wrote: > Dear John, > > > > Thank you very much! > > > > When I started my PhD in 2011 FHIR ha

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

hi Eric Some comments: * UCUM introduces ambiguity, despite the above claim. > please demonstrate examples. > * UCUM does not provide a single code for each unit - it provides 2 > normative codes, as well as a non-normative display/print rendition and an > ad-hoc name. For each unit, UCUM defi

CRUD Restlet

+1 this makes sense, though we retrofitted OMG RLUS onto FHIR, rather than it being our logical basis. But we simplified it a lot. Still, following the same pattern would make sense. Grahame On Wed, Jan 21, 2015 at 9:22 AM, Heath Frankel < heath.frankel at oceaninformatics.com> wrote: > I too h

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

www.technikum-wien.at/ibmt > I: www.healthy-interoperability.at > > Am 13.11.2014 10:07, schrieb Grahame Grieve: > > my advice from LOINC/regenstrief is that it does apply > > Grahame > > > On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale < > thomas.beale at oc

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

my advice from LOINC/regenstrief is that it does apply Grahame On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > Something that has become clear in CIMI, and will affect openEHR, 13606 > and most likely any archetype developer is that acknowledgeme

Licensing of specs and artifacts

> *Controlling Conformance*: CC-0 just means 'public domain', no copyright. > How do you exert any kind of control (which you mention) over the > conformance not being messed with? > The point of a trademark is that you can control what the name means. We say that we define what conformance to "FH

Licensing of specs and artifacts

ed in a way that they haven't go the guts to do. They still insist on attribution etc. So there! Grahame On Thu, Oct 2, 2014 at 10:19 PM, Thomas Beale wrote: > > Grahame, > > we should certainly examine the discussions you have had in FHIR-land. Is > there a link to any discussion,

Licensing of specs and artifacts

This is why we choose CC-0 for FHIR. End of story, there are no debates. Sure, people can go and try and make money off FHIR. All power to them. But times have changed - if they're intending to compete, they won't stay ahead of the community nowadays. So anyone worth working with will share the co

The joint openEHR/FHIR review of Allergy/Intolerance is open

hi All We have opened the joint openEHR/FHIR review of Allergy/Intolerance: http://omowizard.wordpress.com/2014/07/11/inaugural-joint-archetype-review-by-hl7-openehr/ http://www.healthintersections.com.au/?p=2169 The review is open until July 28th. We would like to encourage everyone to contribu

Fwd: Joint OpenEHR / FHIR review of Allergy-related Resources

Hi Everyone Just a heads up to what is coming in the near future: http://www.healthintersections.com.au/?p=2137 One of us (Heather Leslie or I) will post more about this shortly. Grahame -- next part -- An HTML attachment was scrubbed... URL:

Cyclic datatypes: OpenEHR virus

there's usually edge cases in validation where you can stack crash if you're not really careful (been there many times). That doesn't mean that the specs are wrong, but if you can clearly describe the case, it might be worth documenting the risks around it Grahame On Tue, May 13, 2014 at 1:25 A

open platforms blog post

saw it - you're on my blog list. I will think about it over the weekend. Grahame On Sat, May 10, 2014 at 12:27 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > Although not directly about openEHR, I made a recent blog > post

openEHR-technical Digest, Vol 18, Issue 38

hi William There is plenty of health informatics science that tells that combining data from various systems is only possible when each data element is uniquely coded. That single use case alone - reusing data from multiple systems - justifies the SHALL linkage between data element/node and termi

Trying to understand the openEHR Information Model

hi Tom you kind of need to set the ground rules for this. It's not really practical to use schematron to do detailed terminology validation. Must serious attempts end up creating some kind of web service terminology server that can be invoked from the schematron rules. Once you've done that, you'

Trying to understand the openEHR Information Model

nk of that last as the worst possible outcome. Grahame On 16/04/2013, at 4:43 AM, Bert Verhees wrote: > On 04/15/2013 08:37 PM, Grahame Grieve wrote: >> but you can't afford to do either version based merging, or to lose either >> the previously committed information > But

Trying to understand the openEHR Information Model

concurrency is a real issue. Period. Grahame On Tue, Apr 16, 2013 at 2:08 AM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > On 15/04/2013 14:37, Grahame Grieve wrote: > >> "big risk" - it's a combination of how likely it is, and how bad it is if >

Trying to understand the openEHR Information Model

a clash bad. Grahame On Mon, Apr 15, 2013 at 11:25 PM, Bert Verhees wrote: > On 04/15/2013 02:56 PM, Grahame Grieve wrote: > >> well, that's true for some parts of the record - the historical parts. >> Other parts, summary parts, that's quite untrue. In mos

Trying to understand the openEHR Information Model

> this makes sense for EHR and similar systems because there is very low / no write competition for the same piece of the same patient record well, that's true for some parts of the record - the historical parts. Other parts, summary parts, that's quite untrue. In most enterprise systems, records

The Truth About XML was: openEHR Subversion => Github move progress [on behalf of Tim Cook]

Hi Tom You ask: > Is there a better meta-architecture available? When actually the question at hand appears to be: is it even worth having one? I don't think that this is a question with a technical answer. It's a question of what you are trying to achieve. I've written about this here: http://w

The Truth About XML was: openEHR Subversion => Github move progress [on behalf of Tim Cook]

Hi Tom You ask: > Is there a better meta-architecture available? When actually the question at hand appears to be: is it even worth having one? I don't think that this is a question with a technical answer. It's a question of what you are trying to achieve. I've written about this here: http://w

Feedback on an archetype governance issue please

ing - and DNA results. > > regards, > Colin > > > From: openehr-technical-bounces at lists.openehr.org > [openehr-technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve > [grahame at healthintersections.com.au] > Sent: Saturday, 28 Ju

Feedback on an archetype governance issue please

I agree with Option 1, making it clear that > the old archetype is a 'deprecated draft', annotating it with a reference to > the new archetype. > > Regards, > Colin Sutton > ________ > From: openehr-technical-bounces at lists.openehr.org &g

Feedback on an archetype governance issue please

been used within systems, despite the >> draft status. We don?t have any metrics on the extent of the use ? there is >> no reliable way to tell from downloads of the models, nor any voluntary >> usage system ? but that issue is for solving in the future and not the >> purp

13606 revisited - list proposal

> Some, actually most, of the issues you mentioned in the context of the NEHTA > work are familiar, and I think apply to many implementation situations. > Thomas and I have been discussing some possible solutions. > > 1. The ability to expose parts of the RM which are of particular > significance t

13606 revisited - list proposal

>>>? I am having a hard time understanding when the modeller would not know >>> if there was a series of events or not? << > Well for an experienced modeller it is not too hard, although there are > still quite a number of grey areas. particularly if you are modeling general cases rather than ver

13606 revisited - list proposal

>> well, currently, that means that we have to break up what is a simple single >> archetype otherwise into a set of archetypes, and we have poor binding >> between >> them. > > I don't think Thomas was suggesting multiple archetypes. I think he was > saying that you would have multiple data inst

13606 revisited - list proposal

> Perhaps I am splitting hairs, but isn't that what definitions are for? I'd > like it relaxed a little. > > can you post a Problem Report here? ok, I'll do that. > Generally, in the NEHTA context, we've struggled with the openEHR RM here. > Partly it's tooling (AE and CKM) - it doesn't support t

13606 revisited - list proposal

> "Summarisation" > > I think I probably have a somewhat more liberal interpretaion of > 'summarisation' , which would include analysis or interpretation of the > data, to include 'tissue/lab/x-ray diagnosis' but short of clinical > diagnosis. well, clarification would help. (so would tooling!) >

13606 revisited - list proposal

t; Apologies if this is old ground for some people, but I think the discussion > is useful to a wider audience, in the context of a bit of blue-sky thinking > for openEHR 2.0 and 13606 alignment. > > Ian > > On 27 March 2012 03:30, Grahame Grieve > wrote: >> >> hi Sam

13606 revisited - list proposal

hi Sam > The summary of the time series can be as structured as you like. No limit ? > just archetypes. The fact that the first requirement you expressed was a > graphic as part of the report, but it has never been archetyped. except that the definition is "optional summary data expressing e.g. t

13606 revisited - list proposal

Hi. Several comments: > We put it in because Grahame Grieve had identified a use case where there > was something like an image that summarised the data in the time series in > some visual way. Right. But had I know then what I know now, I would've held out for a less limite

Suggestion to replace use of generics with inheritence in future RM versions

Generally, you can do things in specifications that can't be reproduced in actual implementations. Since there is one specification, but many implementations, the list of things that the specification contains that aren't easy to implement varies widely between implementations. The things that are

UCUM

you would just escape the ^ in the HL7 message Grahame On Thu, Mar 22, 2012 at 6:35 AM, Michael Osborne wrote: > well... good question. So in other words: if there is a units field > specifically for 'formal' units, is it UCUM only or not? I would have > said it should be except for annoying p

Units, Quantities, etc

On 19/03/2012, at 9:25 PM, Thomas Beale wrote: > On 19/03/2012 02:15, Grahame Grieve wrote: >> >> for me, conversion between different units that are comparable. You >> should ask Tom what else he thinks it yields up. I'd be interested. >> >> Grahame >

Units, Quantities, etc

: > Dear all, > > On s?n, 2012-03-18 at 13:57 +0100, Grahame Grieve wrote: >> Are discrete units only encountered in administrative directives? Do >> you prohibit people from making observations or measurements that >> include discrete units such as puffs, tablets, patches

openEHR / FHIR data types cross analysis

Hey Sam it's a good day when you can upset both Tom and I equally in a single paragraph. Grahame On Mon, Mar 19, 2012 at 9:24 AM, Sam Heard wrote: > Sorry about the Eiffel slur J > > Cheers, Sam > > ** ** > > *From:* openehr-technical-bounces at lists.openehr.org [mailto: > openehr-tec

Units, Quantities, etc

ty" -- what > are the kinds of things that one wants to "compute" with these kinds of > countable things? > > michael > > On 18/03/12 10:57 PM, "Grahame Grieve" > wrote: > >>Are discrete units only encountered in administrative directives

Units, Quantities, etc

you'll still have to look, even though it's not many cases. Grahame On Mon, Mar 19, 2012 at 10:57 AM, Thomas Beale wrote: > On 18/03/2012 21:45, Grahame Grieve wrote: >> >> ok, so you say it should be computable, but then allow a fixed unit of >> one, >>

openEHR / FHIR data types cross analysis

at lists.openehr.org] On Behalf Of Grahame Grieve >> Sent: Monday, 19 March 2012 8:16 AM >> To: For openEHR technical discussions >> Subject: Re: openEHR / FHIR data types cross analysis >> >> Hi Sam >> >> Actually, this has come up in a couple of other places. T

Units, Quantities, etc

Hi Heath yes, this the problem. I don't know if your solution works. I've considered putting a service up in the cloud that provides a service to take represented units and convert them to ucum units. But it's a many to many mapping unless the conversion is actually done in the context of a speci

Units, Quantities, etc

> well it's not prevented from being expressed; it's just expressed using a > Quantity field (e.g. a DV_COUNT) and another field saying what you are > counting (there are a reasonable number of examples of this already in the > archetypes - number of cigarettes a day, number of previous pregnancies

openEHR / FHIR data types cross analysis

> FHIR has no such restriction - elements must have a type of one or more > of the defined types, either primitive or complex > > ok, but how do w write a normal statically typed classes in Java or C# to > deal with that? Many boolean elements are mandatory - they map straight onto the primitive b

openEHR / FHIR data types cross analysis

in terms of requirements for rigor. > > Cheers, Sam > > >> -Original Message- >> From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- >> technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve >> Sent: Sunday, 18 March 2012 11:50 PM

Units, Quantities, etc

Are discrete units only encountered in administrative directives? Do you prohibit people from making observations or measurements that include discrete units such as puffs, tablets, patches, vials, strips etc? why? HL7 does because we claim that you have to have UCUM codes so the data can be comp

openEHR / FHIR data types cross analysis

>> I just wasn't thinking what I wrote this. In FHIR, a boolean data >> type, primitive, is a >> type that can be used in models an is exactly equivalent to DV_BOOLEAN. > > but isn't the problem that it doesn't inherit from some DATA_VALUE parent > type (Any in HL7 data types)? How can it be one of

openEHR / FHIR data types cross analysis

> Couple of quick reactions - you need to talk to clinical modellers to get a > better response (maybe post on clinical list)... um, maybe. but most are representational questions, not questions of meaning, I think. >> * DV_BOOLEAN - maps a to a coded value with true/false. True and false are >>

openEHR / FHIR data types cross analysis

HI I have responded to the comments in the wiki. Generally, the FHIR data types are not purely for computation; they contain some features related to display. Some further responses here: * DV_BOOLEAN - maps a to a coded value with true/false. True and false are defined codes. I'd be interested

future of CEN 13606 data types

his stage of the process. Grahame > At the HL7 meeting last week in San Diego, Grahame Grieve presented > something called Resources for Healthcare (RFH), essentially a replacement > model for much of HL7v3, for 'practical use'. The driver was the well-known > over-complexi

Unable to express an unit of measurements in UCUM syntax

> I don't think that your proposed solution is valid. It meets the > syntactical requirements while making a mess of any semantic > meaning. > > > well... ok, but {} in UCUM is for things whose syntax doesn't make proper > sense >From UCUM: "Annotations do not contribute to the semantics of the un

Unable to express an unit of measurements in UCUM syntax

it'd be either Orders and Observations or Modeling and Methodology. I don't think that your proposed solution is valid. It meets the syntactical requirements while making a mess of any semantic meaning. Grahame On Fri, May 27, 2011 at 10:26 PM, Leonardo Moretti wrote: > > In UCUM, the period '

Unable to express an unit of measurements in UCUM syntax

ional dimensions (i.e. as soon as you start using floating point > numbers for values that are almost always integers, computers struggle to > get it right...). > > - thomas > > On 29/04/2011 01:48, Grahame Grieve wrote: > > Hi Leo > > Gunther says that these units are not pr

Unable to express an unit of measurements in UCUM syntax

nEHR - both have the same scope and the same usage of UCUM) Also see http://www.unitsofmeasure.org/wiki/ProcedureDefinedUnits Grahame On Fri, Apr 29, 2011 at 9:20 AM, Grahame Grieve wrote: > There's some question about whether such a funky unit is > a proper unit. It does look rather

Unable to express an unit of measurements in UCUM syntax

uot; to find more references. > > Thanks for your help. > leo > > > Grahame Grieve-3 wrote: >> >> Hi Leo >> >> Can you please provide some references to show the use of height^2.7? >> >> Grahame >> >> >> On Thu, Apr 28, 2011 at 6:47 PM

Unable to express an unit of measurements in UCUM syntax

Hi Leo Can you please provide some references to show the use of height^2.7? Grahame On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo wrote: > In cardiology, left ventricular mass (LVM) is often indexed to better > identify left ventricular hypertrophy. > Possible indexations are: > - LVM/BSA

Unable to express an unit of measurements in UCUM syntax

hi Leo I have forwarded this question onto the UCUM wizard (Gunther Schadow). It's a pretty good question. Simply allowing the decimal would make the syntax ambiguous, but there's no easy way to do it any other way. Grahame On Thu, Apr 28, 2011 at 6:47 PM, Moretti Leonardo wrote: > In cardiolo

Use of Identifiers in archetypes

> There have been a few issues with DV_IDENTIFIER - largely that all fields > are mandatory that's pretty remarkable. really? > This may mean that users puts stuff in that is not helpful. sure would. Grahame

Use of Identifiers in archetypes

Hi Peter, Tom thanks > Just take care to use FEEDER_AUDIT for ids generated in external systems, > rather than assigned within the openEHR system, including by users of apps > talking directly to the openEHR system. I'm not sure which way to parse that sentence Generally, about FEEDER_AUDIT, it

Use of Identifiers in archetypes

hi Tom thanks > So considering the notion of order and filler ids, and whatever other ids > are required in a typical clinical process, it is clear that such things > need to be accommodated in archetypes, if they are not already in the > underlying reference model, because they are part of the i

Use of Identifiers in archetypes

as I know DICOM does not support the concept of different > revisions of the same data object. (Called a SOP instance in DICOM speak.) > > > Best wishes > Nick > > --- On *Tue, 18/1/11, Grahame Grieve * wrote: > > > From: Grahame Grieve > Subject: Use of Identifi

Use of Identifiers in archetypes

hi Tom I was working with Heather today on the imaging exam archetype. Two different considerations associated with identifiers came up during our work. The first is that in the archetype design we came up with (still be posed on CKM yet), there's a lot of identifiers present. These identifiers a

Should this list receive notifications for changes to ADL reference archetypes & schemas?

ing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- - Grahame Grieve, Health Intersections Pty Ltd. grahame at healthintersections.com.au | http://www.healthintersections.com.au

New requirements from endoscopy (was Re: GUI-directives/hints again (Was: Developing usable GUIs))

was been absent...? > > ok, so absence / negation is a common requirement in endoscopy... > > > > So it looks like some qualifiers may change the existence of core concepts ? > so perhaps we need some means to tag them during modelling. It looks like > these are ?physical? properties and not ?man-made? concepts. > > I think you mean that the possibility of reporting absence (when it can make > sense) depends on the morphological feature? > > - thomas > > > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > -- Grahame Grieve, CTO A: Suite 8a / 17 Burgundy St, Heidelberg VIC 3083 P: + 61 3 9450 2230 M: + 61 411 867 065 F: + 61 3 92450 2299 E: grahame at kestral.com.au W: http://www.kestral.com.au

Because it's only healthcare IT that is so screwed up....

http://laforge.gnumonks.org/weblog/2010/11/12/#20101112-history_of_a52_withdrawal ;-) Grahame

ISO 21090

> This is really great news. I'm glad you think so. Cause the more I think about it, the more pessimistic I get. > important technical agreed standards should still become > formal standards because, at least here in Europe, they > can be incorporated in laws. y. but is that what we have here? H

More on ISO 21090 complexity

yeah, Peter, thanks. You'd think that when I write that, I'd have the wit to actually check the date huh? Grahame On Wed, Nov 24, 2010 at 5:46 PM, Peter Gummer wrote: > On 24/11/2010, at 17:42, Grahame Grieve wrote: > >> hi Tom >> >> I can only presume this

More on ISO 21090 complexity

hi Tom I can only presume this email actually predated our other discussion > a) a response to some (undoubtedly real) needs by the hL7v3 design group, > and are modelled according to the hL7v3 architecture, not some other > architecture. which architecture is, everything completely denormalised

ISO 21090

what we propose better?) Grahame On Wed, Nov 24, 2010 at 9:24 AM, Heath Frankel wrote: > > Heath > >> -Original Message- >> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- >> bounces at openehr.org] On Behalf Of Grahame Grieve >>

ISO 21090

Hi All I have been having a long discussion with Tom off the list about ISO 21090, and we've come to agreement about the general picture. When I teach ISO 21090 tutorials, and I get to the implementation part, the first thing I say is that the data types are completely denormalised, and that I wo

  1   2   >