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

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

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

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

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

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

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 <bert.verh...@rosa.nl> wrote: > >> On 20-11-17 02:58, Grahame Grieve wrote: >> Gunther says that the server had crashed, a

Re: UCUM

I won’t pass that on ;-) Grahame > On 20 Nov 2017, at 9:09 pm, Thomas Beale <thomas.be...@openehr.org> 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

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

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 >

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 <bert.verh...@rosa.nl> wrote: > On 14-11-17 16:39, Grahame Grieve wrote: > >> either you end up falling

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

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

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

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

Re: openEHR and terminology servers

Daniel Karlsson <daniel.karls...@liu.se >>> > wrote: >>> >>>> 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 b

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

Re: SV: More generic reference model

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

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

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

ase edit your Subject 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

Re: UCUM code in body temperature archetype

I have to check a FHIR Quantity and > instantiate different kinds of RM structures depending on the units code > system. > > - thomas > On 18/05/2016 17:58, Grahame Grieve wrote: > > Hi > > You missed my point. I assume that the content model will differentiate > between

Re: UCUM code in body temperature archetype

n 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:54, Grahame Grieve

Re: UCUM code in body temperature archetype

differentiate them Grahame > On 18 May 2016, at 9:41 PM, Thomas Beale <thomas.be...@openehr.org> 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 wa

Re: UCUM code in body temperature archetype

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

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

Re: UCUM code in body temperature archetype

ctor, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > >> On 18 May 2016 at 10:11, Grahame Grieve <graha...@gmail.com> wrote: >> That's overkill - just have two fields, human and computable units. >> >> Grahame >> >>> On 18 May 20

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,

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

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

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

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 acknowledgements

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 FHIR

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

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,

Trying to understand the openEHR Information Model

On Mon, Apr 15, 2013 at 11:25 PM, Bert Verhees bert.verhees at rosa.nl 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 most enterprise systems, records tend

Trying to understand the openEHR Information Model

. 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 they are. Generally, current location, current medication lists, summary lists

Trying to understand the openEHR Information Model

of that last as the worst possible outcome. Grahame On 16/04/2013, at 4:43 AM, Bert Verhees bert.verhees at rosa.nl 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 what if every

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

Feedback on an archetype governance issue please

of time. So principles of governance are of high priority, not just reacting to management of one specific model in isolation. Within the Australian context, Grahame Grieve has collaborated to update the current OBSERVATION.lab-test archetype -http://www.openehr.org/knowledge/OKM.html

Feedback on an archetype governance issue please

it with a reference to the new archetype. Regards, Colin Sutton From: openehr-technical-bounces at lists.openehr.org [openehr-technical-bounces at lists.openehr.org] On Behalf Of Grahame Grieve [grahameg at gmail.com] Sent: Saturday, 28 July 2012 7

Feedback on an archetype governance issue please

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 July 2012 10:55 AM To: For openEHR technical discussions

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 to a

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 limited summary

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

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!) Our

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 the

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 instances of

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 very

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 mjosborne1 at gmail.com 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

Units, Quantities, etc

, 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, vials, strips etc? There are examples of counting

Units, Quantities, etc

, at 9:25 PM, Thomas Beale thomas.beale at oceaninformatics.com 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 well any mathematical

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 sam.heard at oceaninformatics.comwrote: Sorry about the Eiffel slur J Cheers, Sam ** ** *From:* openehr-technical-bounces at

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 the

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

openEHR / FHIR data types cross analysis

-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 To: For openEHR technical discussions Subject: Re: openEHR / FHIR data types cross analysis I just wasn't thinking what I wrote this. In FHIR

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

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,

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

openEHR / FHIR data types cross analysis

, Grahame by XML. Most developers will probably sit somewhere in between 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

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 thomas.beale at oceaninformatics.com 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, and some

Units, Quantities, etc

-- 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 grahame at healthintersections.com.au wrote: Are discrete units only encountered in administrative directives? Do you prohibit people from making

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

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 lmoretti at noemalife.com wrote:

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 lmoretti at noemalife.com wrote: In cardiology, left ventricular mass (LVM) is often indexed to better identify left ventricular hypertrophy. Possible

Unable to express an unit of measurements in UCUM syntax

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, Moretti Leonardo lmoretti at noemalife.com wrote: In cardiology, left ventricular mass (LVM) is often indexed to better identify left ventricular

Unable to express an unit of measurements in UCUM syntax

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 grahame at healthintersections.com.au wrote: There's some question about whether such a funky unit is a proper unit. It does look

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 lmoretti at

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

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's

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

Use of Identifiers in archetypes

instance in DICOM speak.) Best wishes Nick --- On *Tue, 18/1/11, Grahame Grieve grahame at kestral.com.au* wrote: From: Grahame Grieve grahame at kestral.com.au Subject: Use of Identifiers in archetypes To: For openEHR technical discussions openehr-technical at openehr.org Date: Tuesday, 18

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

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

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? How

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

ISO 21090

, Heath Frankel heath.frankel at oceaninformatics.com wrote: Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Grahame Grieve Sent: Tuesday, 23 November 2010 11:54 PM To: For openEHR technical

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.

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 peter.gummer at oceaninformatics.com wrote: On 24/11/2010, at 17:42, Grahame Grieve wrote: hi Tom I can only presume this email

More on ISO 21090 complexity

Hi William Thanks for the kind words. It seems to me that we could define a mapping from openehr to iso 21090. I certainly designed it that way. The mapping is not perfect, but it's good enough to be useful except for corner cases. I just have to find the time to write it up properly, but that

More on ISO 21090 complexity

hi Tom It might be just me thinking that some of the 21090 types are not that simple no, they're not simple. That's not the relevant question. Instead, it's how well designed they are. I could design a set of simple types that met the requirements, but the profusion of resulting types would

More on ISO 21090 complexity

Thanks Vince and hence possibly not worth coding. However, as Grahame notes, it does reflect some real world instances where Grahame conceded (somewhat reluctantly) to the clinicians. this kind of makes it sounds as though I needed to concede! Even if I hadn't conceded, I was going to be

ISO 21090 data types too complex?

hi All A roll up of comments: 1. ISO 21090 is often (always?) profiled It seems remarkable to me that people think it's a problem that ISO 21090 needs to be profiled. Who would've guessed that a full standard that meets many requirements is simpler to implement if you profile out the features

ISO 21090 data types too complex?

hi Tom The only kind of 'profile' I know of elsewhere in other standards is of the kind 'we only implement x, y but not z'. which is the kind I'm talking about The answers Grahame gave me last time I discussed how to profile 21090 for 13606 use are here, about half-way down. rather

ISO 21090 data types too complex?

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

ISO 21090 data types too complex?

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

ISO 21090 data types too complex?

hi Tom I'm not going to get into a long debate here about modeling philosophy. I'll respond with brief points to each of yours, and then I'll shut up. Other people can take it further if they want. they might well be; my original question was: is this the only possible reaction (these data

Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc

In all other industries, the quality of standards is measured initially against public safety and then against criteria of effectiveness and economic qualities. it seems you mean, by market testing. If not, do you have an example? In all other industries that i know of, standards are

Articles on Healthcare, Complexity, Change, Process, IT and the role of openEHR etc

/2010 22:32, Grahame Grieve wrote: Well, your specific comments certainly don't back your general statement up. Looking at the question of the other industries, what specific standard would you point to as an example we should follow, and how was it developed? - safety goggles and other personal

Demographics Archetypes

Because when I went to check the review generally, the review wasn't listed nor was the review cycle. (both are available for address) Grahame On Tue, Oct 27, 2009 at 8:16 PM, Sebastian Garde sebastian.garde at oceaninformatics.com wrote: Grahame Grieve wrote: hi Two of the demographics

Demographics Archetypes

hi Two of the demographics archetypes are open for review : postal address and person name. I appear to be the only one who has commented on either, but the system seems to have lost my review of the person name archetype? I have mainly focused on interoperability with ISO 21090 (healthcare

Documentation Desparation

+1 Grahame Sent from my iPhone On Sep 25, 2009, at 6:23 PM, Koray Atalag koray at cs.auckland.ac.nz wrote: Hi All, I really appreciate the mental exercise to achieve a better documentation; however I must say I am really surprised to watch the recent discussions like this one

Archetyping links

(rm_type_name, archetyped parent archetype ID, archetype path) rather than the runtime URI of the target itself. Perhaps this is what you meant. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Grahame Grieve

Archetyping links

Hi Heath Doesn't this imply that a URI's are like codes that are references to some concept - that there's the same interest in controlling the concepts that they point to, and a similar delegation of control as with terminologies (as in, early vs late binding, implementation provision issues)?

  1   2   >