Meaningful Use and Beyond - O'Reilly press - errata

[Seabury Tom (NHS CONNECTING FOR HEALTH)]

Crowdsourcing = Errata submission perhaps here
http://oreilly.com/catalog/errata.csp?isbn=0636920020110

Of the reviews I read there was reference to 'rushed' missing chapters, and 
poor proof reading.

Tom Seabury

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: 12 February 2012 13:01
To: openehr-technical at openehr.org
Subject: Re: Meaningful Use and Beyond - O'Reilly press - errata


It would be interesting to see what US-based list members think of what Michael 
has quoted below. Is openEHR really seen as 'controversial' in the US? 
(Controversy can be good - at least it means debate).

The quote below about David Uhlman being CTO of openEHR in 2001 is certainly 
incorrect - I imagine it is supposed to read 'OpenEMR', going by what I see 
here in Wikipedia (in any case, 
openEHR has never had a 'CTO' position). That's a surprisingly bad fault in 
O'Reilly editing; worse, the author page for David 
Uhlman on the O'Reilly website repeats 
the same error. This 
review on the 
same website seems to confirm a complete lack of review or editing of the 
original manuscript. O'Reilly obviously is missing basic mechanisms for quality 
control.

But the more interesting question is: are the opinions in this book about 
openEHR representative of a US view?

- thomas

On 12/02/2012 11:22, Michael Osborne wrote:
I read the recently released O'Reilly book "Meaningful Use and Beyond" on 
Safari books today and found the following errors
and some quite blatantly false statements about OpenEHR.

Firstly is the claim by one of the authors, David Uhlman, that he was CTO of 
openEHR in 2001
 - a claim which Thomas Beale denies.

David Uhlman is CEO of ClearHealth, Inc., which created and supports 
ClearHealth,
the first and only open source, meaningful use-certified, comprehensive, 
ambulatory
EHR David entered health-care in 2001 as CTO for the OpenEHR project.
 One of the first companies to try commercializing open source healthcare 
systems
, OpenEHR met face first with the difficult realities of bringing proven 
mainstream
technologies into the complicated and some-
times nonsensical world of healthcare.

Secondly, a nonsensical statement about openEHR in the book...
p.161
OpenGALEN and OpenEHR are both attempts to promote open source ontology con-
cepts. Both of the projects have been maturing but some view these as 
unnecessary
additions or alternatives to SNOMED+UMLS. However, they are available under open
source licensing terms might make them a better alternative to SNOMED for 
certain
jurisdictions.

And this, p163...

OpenEHR is a controversial approach to applying knowledge engineering principles
to the entire EHR, including things like the user interfaces. You might think 
of Open-
EHR as an ontology for EHR software design. Many health informaticists disagree 
on
the usefulness of OpenEHR. Some believe that HL7 RIM, given its comprehensive
nature, is the highest level to which formal clinical knowledge managing needs 
to go.

I'm beginning to lose all respect for O'Reilly press. It's been all downhill 
since the camel book.

Cheers
Michael Osborne



--
Michael Osborne




___

openEHR-technical mailing list

openEHR-technical at openehr.org

http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere
For more information and to find out how you can switch, visit 
www.connectingforhealth.nhs.uk/nhsmail


-- next part --
An HTML attachment was scrubbed...
URL: 

constraint binding error

[Seabury Tom (NHS CONNECTING FOR HEALTH)]

I see this as an opportunity for some joint work on specification of 
terminology binding, in the intersection of interests between the openEHR 
community and for one: IHTSDO.

I hope the following notes are both helpful and true, corrections are most 
welcome!
[Specialists language from the SNOMED CT technical lexicon is in '' marks]

The identification of bindable 'components' from SNOMED CT is certainly via 
ReferenceSet IDs (not yet part of the standard but very soon will be) via 
SubsetIDs

For SubsetIDs I would expect the {URI/URN etc.} to include a 'Version'
For Concepts the 'ConceptID' should of itself be adequate
For query specifications - mentioned somewhere in this thread - the only way to 
identify these will in the future be via an 'intensional' ReferenceSet 
definition, but to be meaningful this may (in some cases must) be used in 
conjunction with the named Edition of SNOMED CT against which this will be run.

For enumerated ReferenceSet members (not the query but a results set of a 
query) then the ReferenceSetID would be needed.

In all the above cases it is necessary to consider if the named 'Edition' and 
'Release' of that 'Edition' may need to be included.  The proposed uses of 
'Module' Identifiers is a further topic.

The 'Releases' are identified such as "UK Edition"
Releases are identified in ways that are decided by each SNOMED CT 'National 
Release Center' such as the effective date, but this is not a formal convention.

[Anyone wanting the finer points of detail for IHTSDO standards and common 
practice for issuance and use of : Namespaces, Editions, Release Centres, 
ModuleIDs and other such metadata are invited to join, say, the Special 
Interest Groups in IHTSDO.

Overall, in this intersection of interests between multiple information models 
(say HL7 and UK's LRA), and multiple terminology and classification schemes 
(say SNOMED CT and ICD and..) makes this topic one where working-up rather than 
handing-down a solution is most likely to happen and succeed.

Tom Seabury

-Original Message-
From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of 
michael.law...@csiro.au
Sent: 21 February 2011 03:47
To: openehr-technical at openehr.org
Subject: Re: constraint binding error


Surely spaces should not be an issue here as these strings do not really 
identify anything.  Instead, one should be using SCTIDs as in:
terminology:Snomed?v=2002?s=135394005

Further issues include:

 *   the version should be specified using an ISO 8601 basic representation of 
MMDD (or MMDDThhmmss Z for development versions),
 *   "Snomed" is insufficient - is this the International release, or SNOMED 
CT-AU or ... My understanding of Release Format 2 (see 7.4.4.13 in the 
Technical Implementation Guide) indicates that the moduleId (also an SCTID) is 
the appropriate thing to use, and
 *   one may also (almost always) wish to use a ReferenceSet for terminology 
binding. These are also designated by an SCTID (and would require a moduleId 
and version as well)

This would then give us something like:

terminology:SNOMED?m=3250602136107&v=20101130&s=135394005

On 21/02/11 12:22 PM, "Peter Gummer"  
wrote:

Diego Bosc? wrote:

> and we have also to deal with spaces!
> 

Spaces are illegal in URIs. The correct form for the subset would be:

subset=Antiallergenic%20drugs%20(product)

- Peter
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical


___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical




This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere
For more information and to find out how you can switch, visit 
www.connectingforhealth.nhs.uk/nhsmail

Representing binary values with DV_BOOLEAN

[Seabury Tom (NHS CONNECTING FOR HEALTH)]

Hi Thomas,

At the point you state 'we can't prevent medical researchers from creating 
questionnaires with purely boolean answers' I recognised a critical 
distinction, it is one we know quite well: The distinction between how data 
entry/review elements are built into clinical applications - the front end 
design - and the abstract model which these interfaces must map to.

Taking the idea of a clinical researcher developing some informatics product - 
then they would ideally (re)use an abstract model (with its bound reference 
terminology) without re-modelling any of that, but then develop whatever screen 
designs then need, and merely define what on-screen values map to which things 
in the abstract model.

I don't think this distinction is contentious, but I think it is often assumed 
rather than stated.

I guess there are few if any points in a full abstract model of medicine or 
healthcare more generally where the careful attention to an abstract model 
design would lead to the use of Boolean values.  Ian McNichol's contribution is 
useful here, putting this question into the context of prior work on clinical 
statement patterns.

Tom Seabury

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Thomas Beale
Sent: 09 February 2011 17:30
To: openehr-technical at openehr.org
Subject: Re: Representing binary values with DV_BOOLEAN

On 09/02/2011 15:05, pablo pazos wrote:
I agree with you Thomas but there's always some implicit semantics, I mean: 
when there is no data, it is taken as false, but what happen if the person who 
do the questionnaire do not try to make this question false? May be he/her 
didn't want to answer, and this false could have value/semantics in clinical or 
legal fields.

Hi Pablo,

my point is that in some cases, researchers construct questionnaires for 
healthcare use that will have some purely boolean answers, and they simply 
won't use responses containing missing answers, i.e. they will only use clean 
data. A question like 'have you ever had children' for example in such a 
questionnaire can be modelled as Boolean if the researcher wants simply to 
divide the population into two - women who gave birth, and women who never did. 
Any response like 'don't know' would be discarded in such a study. I am not 
saying that this is good study design, or anything else (it isn't my area), but 
we can't prevent medical researchers from creating questionnaires with purely 
boolean answers, if that is what their statistical computing model requires.

- thomas




This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere
For more information and to find out how you can switch, visit 
www.connectingforhealth.nhs.uk/nhsmail


-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)

[Seabury Tom (NHS Connecting for Health)]

I cannot claim to be an implementer of openEHR but I am still interested to 
understand the proposed use of Tables.
Can anyone point me to a place where this is already explained with examples, 
the abstract discussion is a little hard to follow.

My simple reading of this is that what are currently trees would instead be 
expressed as a sparsely populated arrays - is that the point?

Tom Seabury
NHS Data Standards & Products

From: openehr-technical-bounces at openehr.org 
[mailto:openehr-technical-boun...@openehr.org] On Behalf Of Erik Sundvall
Sent: 10 November 2010 16:16
To: For openEHR technical discussions
Subject: Re: openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and 
ENTRY/OBSERVATION (Was: ISO 21090 data types too complex?)

Tom, did I really express myself in such an unclear way or did you not read 
properly? Or did you respond to the wrong thread somehow? Perhaps i 
misinterpret your tone and arguments so please clarify if you have problems 
with the following:

1. tables, clusters etc

I did not suggest that we should avoid having a single fixed way of defining 
table structures in openEHR. I suggested using a new attribute to indicate if a 
cluster is conceptually/graphically to interpreted as a table, list etc. 
instead of using separate classes for this purpose. Of course we need strict 
definitions of allowed values for this attribute (an enumeration or a list in 
the openEHR terminology, just as in other parts of openEHR presently). Of 
course specifications should include exactly how to interpret the clusters as 
rows and columns.

Ian and Sam indicate that this would also have the benefit of allowing tables 
anywhere in a cluster hierarchy instead of only at top level. Do you have any 
objection against this provided that it is introduced in a well defined manner 
as described in the previous paragraph?

Your argumentation sounds like somebody suggested that tables are not needed in 
openEHR at all or that they should be defined in random different ways.

2. Observations etc.

I suggested that ISO 13606 gets extended with the openEHR ENTRY subclasses. 
Here I did not suggest changes to openEHR. (Even though I tried to say the 
class names can be confusing if you for some reason strongly believe that a 
technical class name only can be used for exactly what your own perception of 
that English word means.) Perhaps your OBSERVATION examples are just your way 
of expressing that you support my idea and why it is important to have the 
ENTRY subclasses to encourage consistency.

The part about automatically converting openEHR ENTRY subclass structures to 
13606, was definitely not a suggestion to remove them from openEHR. Instead it 
was more of an enquiry if it was at all possible in a non-destructive way. If 
it is, then openEHR archetype modeling, queries etc could after auto-conversion 
be used somewhat safely in a setting where you only have 13606 available.

Best regards,
Erik Sundvall
erik.sundvall at liu.se 
http://www.imt.liu.se/~erisu/  Tel: +46-13-286733



This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSI recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere
For more information and to find out how you can switch, visit 
www.connectingforhealth.nhs.uk/nhsmail


-- next part --
An HTML attachment was scrubbed...
URL: