from:"Vincent McCauley"

Use of Identifiers in archetypes

2011-01-18 Thread Vincent McCauley

HL7 Australia will issue companies unique OID roots based on the HL7 branch
At present this is a free service

Dr Vincent McCauley MB BS, Ph.D
CEO, McCauley Software Pty Ltd www.mccauleysoftware.com
Chair, IHE Australia www.ihe.net.au
Treasurer, Medical Software Industry Association www.msia.com.au
p: +61298186493
f:  +61298181435

Jan. 2011 HL7 International Meeting: Sydney www.HL7.org.au/Sydney2011
  - Original Message - 
  From: Grahame Grieve 
  To: For openEHR technical discussions 
  Cc: Dewinder.Bhachu 
  Sent: Tuesday, January 18, 2011 8:39 PM
  Subject: Re: Use of Identifiers in archetypes


  Thanks Nick

  The question here really isn't about the semantics of the DICOM identifiers,
  though I thank you for reviewing those. The question is about how these 
  interact with an openEHR system and with other users of the archetype

  One interesting aspect concerning the OIDs is that though they are supposed
  to be globally unique, unless you have a oid root -- issuing system 
registry,
  you still need to track the issuing system (and I've never heard of such a 
  registry in practice)

  Grahame



  On Tue, Jan 18, 2011 at 8:24 PM, Nick Brown nbrown.mimic at btinternet.com 
wrote:

  Hi Grahame

  DICOM UIDs are globally unique ISO OIDS expressed in a specified text 
format. Also specified in an ISO standard called GUSI (Globally Unique String 
Identifiers).  So storing them as ASCII text strings of max length 64 bytes is 
actually how DICOM uses them.

  Within a department each four digit identifiers called Accession  
numbers are used as identifiers usually to identify a folder that holds the 
results arising from a specific request for an imaging procedure to be 
performed.  When they get to  they start again at 0001.

  The IHE SWF Profile specifies a way to use DICOM and HL7 date 
elements to manage the process of creating results as a result of a request.  
It used DICOM UIDs to identify various data objects including any image data 
objects that are produced.  DICOM has its own way of searching for images which 
requires a set of UIDs to identify the image and where it can be found.  These 
were originally designed for use within a department but are now being used for 
communication between departments.  

  All data DICOM data object have to use the image data object 
structure even reports or notes.

  Hope this helps

  I am copying the supplier co-chair of the British Institute of  
Radiology (BIR) Medical Imaging and Radiation oncology committee who is a past 
director of an organsiation called PACSnet and is a key expert on these matters.

  BTW so far 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 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 January, 2011, 4:31


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 are
required to deal with the interoperability aspects of the imaging 
exam
report (i.e. PACS reigsters images with RIS, RIS provides report to
EHR, EHR tracks identifiers so it can provide links to RIS/PACS
resources as required). In particular, in several places there's 
slots
for various DICOM UIDs. To me, these are IT issues, not clinical
issues, so they shouldn't be part of the archetype design (on the 
basis
that archetypes are *clinica* knowledge)- but I do know that we
absolutely need these identifiers. Is there a policy about this?
Note that I ask this question with wider issues about whether IT and
interoperability concerns should be explicitly represented in 
archetypes.

The second question is that there seemed to be some operating
guidance to archetype designers to use the Text data type rather 
than
the Identifier type for these fields talked about above on the 
basis that
they are foreign identifiers. There didn't seem to be particular
consensus on where this policy came from (and I don't want to point
fingers...) but it seems pretty nuts to me. These things should be
identifiers, and we should insist on tracking the issuer of them 
(though
I couldn't care less about

More on ISO 21090 complexity

2010-11-18 Thread Vincent McCauley

Grahame, Tom

Given the enormous respect I have for both of you and your deep technical 
knowledge in this domain
I hesitate to offer an opinion.

However, I have followed with great interest the evolution of the ISO 
dataypes from a small Standards Australia
Technical working Committee, all the way through HL7 and ISO.

From the point of view of a clinical datatype implementer who has to write 
actual code, the ISO dataypes provide a level of detail
that is both required and sufficient. They are definitely not simple in 
their definition but are mostly simple
in terms of concept representation.
The atom at one time looked simple and remains so in concept, though in 
fact having considerable underlying complexity.
The level of detail required depends on your use case which seems to be a 
major contributor to your divergence of opnion.

 In addition, there are some known use cases where the value set
 that a user or system was offered when choosing a code affects
 the interpretation of the code.

 The last sentence above indicates that the meaning of a code stored in 
 data
 might depend on how it was chosen. This would break the basic 
 immutability
 of meaning of codes in a code system. I wonder how we would compute with
 such data?
As you correctly observe Tom, this makes these particular codes 
non-computable
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. Usage (or 
lack of it) will determine
whether this has any actual value, but this issue probably needs to be 
highlighted in BIGGER LETTERS.

Regards
Vince

Dr Vincent McCauley MB BS, Ph.D
CEO, McCauley Software Pty Ltd www.mccauleysoftware.com
Chair, IHE Australia www.ihe.net.au
Treasurer, Medical Software Industry Association www.msia.com.au
p: +61298186493
f:  +61298181435

Jan. 2011 HL7 International Meeting: Sydney www.HL7.org.au/Sydney2011
- Original Message - 
From: Grahame Grieve grah...@kestral.com.au
To: For openEHR technical discussions openehr-technical at openehr.org
Sent: Thursday, November 18, 2010 4:28 PM
Subject: Re: 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
 not be simple to implement. So the long term question is not how
 simple the types are, but how you can work with them. I do recognise
 that the simplicity of the types is related to that, but there is more to
 it than just that.

 The ISO 21090 types are designed using a different philosophy and
 design pattern to what you use - they are *dense*. This is not to
 everybody's liking, but does have more benefits the further you get into
 implementation. It certainly has the problem that the initial engagement
 with the data types requires more investment before favourable
 outcomes start to occur

 We could discuss who this benefits if you want, but the saying that
 they just aren't simple is... too simple

 This is the data structure of a CD, with the HL7v3 message attributes in

 I guess you'll continue to dismiss them as hl7 v3 message
 attributes, but you miss the point by doing so - they are a response
 to a set of use cases that are not v3 - or even messaging - specific.
 They are in a different place to where you would like to have them,
 but that's about the above discussion

 I would have thought a more obvious method would be to define a
 type with a text field in it

 I don't think it's more obvious. It's certainly possible, but then I have
 terminology policy differences represented as different types in
 my engineering layer - rather a drawback from at least my point
 of view. I'd say more, but I think that's enough to demonstrate that it's
 not obvious. To determine which was better would be a long discussion,
 and we'd need to start by determining the scope of better for what?

 with the GUI making the relevant coding widgets available in the correct 
 way

 uh? What's the GUI got to do with it? For the ISO 21090 data types,
 this is not in scope. I understand that this is in scope for openEHR,
 because you automatically build UI from model's choice of data
 type, and that's why you'll continue to use openEHR data types for that.
 fine, makes sense.

 Note that I merged displayName and originalText, as this seems
 to be a modelling confusion

 or you could actually read the documentation that makes the differences
 very clear. In particular, note the restrictions on the use and 
 implications
 of displayName. I will say that originalText is semantic in nature - 
 inherent
 to the actual meaning, whereas displayName is distinctly interoperability
 related - and pretty much irrelevant in an openEHR context.

 In addition, there are some known use cases

Normal and other ranges

2006-08-29 Thread Vincent McCauley

The normal range is often dependent on patient age and sex and sometimes on
other patient state context
(especially for hormone levels) e.g pregnant, pre/peri/post menopausal, day
of menstrual cycle
etc

Regards
Vince

Dr Vincent McCauley

- Original Message - 
From: Rodrigo Filgueira rfil...@fing.edu.uy
To: openehr-technical at openehr.org; openehr-clinical at openehr.org
Sent: Sunday, August 27, 2006 6:19 AM
Subject: Normal and other ranges


 I see DV_ORDERED can optionally have specified normal and other ranges.
 While the other ranges are said to be dependant on the measuring context.
 normal range it seems to me, coud be defined as allways the same?
 I'm thinking about laboratory resullts.

 Anyway, is there a way to define this ranges in Archetypes?
 Or should a decission support module be responsible for this?

 thank you

Pathology numeric values not supported in DV_Quantity

2006-03-03 Thread Vincent McCauley

In my system there is an implied difference between ~ (approximate) and
I(inaccurate)

~ = this value is approximate but correct (and can be used for clinical
management/decision support/graphing etc)
whereas I = not to be relied on, usually with some accompanying reason.

Regards
Vince
- Original Message -
From: Thomas Beale
To: openehr-technical at openehr.org
Sent: Friday, March 03, 2006 5:26 AM
Subject: Re: Pathology numeric values not supported in DV_Quantity

Grahame Grieve wrote:
hi

I don't think that the concept of , etc should
be conflated with the concept of approximately
and doubtful in the model. the approximate and doubtful always raise the
issue of why and how and so I think that should be a matter for the archetype
to resolve. However and etc, should be a data type thing.

Grahame

Grahame, you are right - to express 5 (inaccurate) we need two flags...

I can't think of great names of the top of my head, but how about:

a.. value_qualifier - the attribute that carries the , , = etc
b.. value_status - an attribute that carries some other possible flags,
e.g. ?, ~, others?
I am suggesting that Vince's '~' is more like a data quality marker than an
indicator of how to read the value...'?' means inaccuratepossibly wildly?
Are '~' and '?' really different? If the second flag was just to say accurate /
inaccurate then we could just use a Boolean. That would probably cover 95% of
needs and be simple at the same timeVince - any comments on that?

I think we are close to a solution here.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060303/b146c3f9/attachment.html

RFC CR-000024 - Revert meaning to String - ARB deadline 23 july 2004

2004-07-12 Thread Vincent McCauley

Hi Thomas,

1. I think node_id rather than meaning for the name of this data would be
clearer.

2. A compromise suggestion to address Dipak's issue (which I think is
important) as well as reduce XML bloat:
Change the datatype to just a string but introduce a new section at the
start of the XML package which has a list of name/value pairs of form:
archetype references
  archetypeID at \archetypeID
  archetypeName An archetype formal name \archetypeName
/archetype references

one pair for each archetype referenced in the following XML package.

This would also be helpful for software to pre-locate all required
archetypes (e.g. when XML is initially received)
prior to further processing the XML.

Regards
Vince

Dr Vincent McCauley
McCauley Software Pty Ltd

- Original Message - 
From: Thomas Beale tho...@deepthought.com.au
To: Openehr-Technical openehr-technical at openehr.org
Sent: Saturday, July 10, 2004 8:36 AM
Subject: RFC CR-24 - Revert meaning to String - ARB deadline 23 july
2004



 Dear all,

 here is another important CR to consider in the next few weeks.

 CR-24 - Revert meaning to String. See

http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR-24
.txt.
 This CR is about the meaning attribute defined on the class LOCATABLE
 (see Common Model, Archetype package, at

http://www.openehr.org/repositories/spec/latest/publishing/architecture/ref
erence_model/common/im/REV_HIST.html).
 This attribute is one of the most important in the whole reference model
 - it is effectively the node id of every node in an archetype, and it is
 what gets imprinted into data, so that the latter can be reconnected
 with its archetypes. It also has a second purpose: it is coded in the
 archetype, giving it a normalised meaning in multiple languages, e.g
 systolic pressure, whereas as the node name might have been set by the
 user to sys BP or whatever. Currently, the attribute is of type
 DV_TEXT, meaning it could be a DV_CODED_TEXT as well (see the data types
 reference model for these types -

http://www.openehr.org/repositories/spec/latest/publishing/architecture/ref
erence_model/data_types/im/REV_HIST.html).
 Given that every single node in data will contain this item, it has been
 proposed by Sam, and now more recently by the DSTC that it should be
 reverted to just a String expressing the code (it must be an at code,
 of the kind you see in the archetypes), because to use a DV_CODED_TEXT
 means there is a DV_CODED_TEXT object, a CODE_PHRASE object, with the
 latter containing 2 Strings. The DSTC have shown that in the XML of the
 data, this causes quite a bit of bloat. Sam Heard has always contended
 that we should just used the code as a String; the pracical consequence
 of this is that you must have archetypes present to interpret the node
 id. Dipak Kalra has always contended that it should be present as the
 full coded term, so that the normalised meaning is available in the data
 (well, in one language at least), without referring to the archetype.

 It is also important to realise that the expression of the 'meaning'
 attribute as a simple string such as 'at0001', 'at0045.1' etc (codes
 derived from the archetypes) provides an easy way to support path based
 querying in XML data, using Xpath. A path of the form
 .../events[@id=at0014]/... can find the node marked with  the arhceytpe
 node id (= meaning) 'at0014'; a concatenation of such patterns enables
 nodes to found anywhere in large trees of XML data.

 It has also been argued that the name of the attribute - 'meaning'
 should be changed to e.g. 'node_id', or even just 'id' - whcih would not
 harm the comprehension of archetypes, and would be more obvious in data.

 reactions?

 - thomas beale


 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org




-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Data Security was: Basic EHR functionality

2004-03-11 Thread Vincent McCauley

I would strongly support the concept that logging
of access (hand in hand with significant penalties)
should be the underlying principal to deter
inappropriate access to the EHR.

This is already used in other high security domains (police etc).

Regards
Vince

Dr Vincent McCauley MB BS, Ph.D
CEO McCauley Software Pty Ltd
Vice President Medical Software Industry Association

- Original Message - 
From: Thomas Beale tho...@deepthought.com.au
To: Gavin Brelstaff gjb at crs4.it
Cc: Openehr-Technical openehr-technical at openehr.org
Sent: Wednesday, March 10, 2004 23:26
Subject: Re: Data Security was: Basic EHR functionality


 Gavin Brelstaff wrote:

  Thomas Beale wrote:
 
 
  A well known study in Harvard medical school (I think) showed that
  putting the message Do not inappropriately access patient data - all
  your accesses are being logged on clinician screens a few times a
  day resulted in a drop to near 0 of inappropriate access. No other
  technology was used
  - thomas
 
 
  There must be a downside to do that too - discouraging access by those
  who have urgent need while being undertrained on the system - it would
  sure scare me off  - and that would effectively reduce medic-medic
  communication rather than promote it.  Sure security is important
  but don't forget it is always compromise [Bruce Schneier].

 I actually suspect the key to this is: whatever the security measures,
 we must assume that someday, one day, health data of you or me, or a
 politician or an actress will be hacked and sent to the Mirror or Sun
 (gutter tabloid press in Britain, for US readers!), or simply posted on
 a website. What will be the acceptable costs of preventative measures
 against this? When it happens, what will be the acceptable outcome? For
 the latter: it has to be at least that perpetrators' accesses were
 logged (assuming they weren't so smart that they bypassed logging and
 all other access detection systems); it has to be that the victim is
 informed of the information theft; and there have to be legislative
 measures which are severe enough that stories do not get published in
 the Mirror or on the web. Stopping a story in a newspaper is possible in
 most countries; stopping the posting of information on the web is going
 to be much harder, but if the identities of the information thieves can
 be logged, then something can be done. Perhaps publishing another's
 health record can be made so severe a crime that it just isn't worth it
 for some would-be hackers? That leaves us with hackers with personal or
 particular motives, e.g. insurance companies, private investigators,
 family members, political partiesagain, it seems to me that the
 greatest deterrent to actually using stolen health information is the
 sure knowledge that your illegal accesses were logged somehow, not that
 you were prevented getting in in the first place; then you know that any
 use you make of the information, once detected will lead to severe action.

 - thomas beale


 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org




-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Pathology requirements CONTRIBUTION - 2 versions at once

2003-10-27 Thread Vincent McCauley

I think there is a need for both superceded and exclude from automatic
processing.

Wherever the haemolysed marker ends up in the archetype/EHR it won't be
the only such beast.
Some other examples are clotted and clumped for full blood counts,
incorrectly collected (specimen in wrong type of tube etc e.g not a
fluoride tube for a blood glucose), warmed (where specimen has to be keep
cold for correct results),
cooled where specimen has to be kept at body temp. (cold agglutinins etc)
and so on ...

Regards
Vince

- Original Message - 
From: Thomas Beale tho...@deepthought.com.au
To: Openehr-Technical openehr-technical at openehr.org
Sent: Monday, October 27, 2003 18:54
Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once


 Vincent McCauley vincem at mccauleysoftware.com,

  Hi Thomas,
  The issue here is that Pathology labs will produce a numeric result for
say
  Potassium
  but when it is high willl look at the specimen, decide it is haemolysed
and
  actually
  report Haemolysed as the result. The Lab will store two results, the
  numeric value e.g. 7.0
  and the reported result Specimen haemolysed.
  The value 7.0 should never be returned as the result to a query show me
all
  potassium results
  but has to be recorded in the Labs EHR for the patient.
  How should this be modelled?

 If there is a lifecycle or other marker on Entries then the marker can be
set to an
 appropriate value, either superseded as I suggested before, or perhaps
 something like exclude from automatic processing as Sam has suggested.
 Whatever the marker, this result will still be visible to queries that
ignore this
 marker (i.e. queries that get results for display on the screen), and the
result
 will still be available as a part of the record until such time as someone
decides
 to do a repeat test to replace it, in which case it remains a previous
version of a
 new correct result.

 Probably in the archetypes for blood tests there should be place to put
 the haemolysed classifier next to the value. Not sure exactly where this
 should go at the moment...

 - thomas

 
  Regards
  Vince
 
  Dr Vincent McCauley
  CEO McCauley Software Pty Ltd
 
  - Original Message - 
  From: Christopher Feahr chris at optiserv.com
  To: Thomas Beale thomas at deepthought.com.au; Openehr-Technical
  openehr-technical at openehr.org
  Sent: Monday, October 27, 2003 01:26
  Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once
 
   Hi Thomas,
   I'm not sure I like the notion of superceded.  Is the first test an
   error?  If so, the first result should simply be marked wrong and
voided
   or removed.  If the first result just looked a little goofy to the
   clinician, but there was nothing to indicate with certainty that it
was
   erroneous... and the second result comes back with more reasonable-
 looking
   values... perhaps both results should be left in the record.  The
   time-stamps will suggest to the clinician that the later one probably
   supercedes the earlier, goofy-looking result.
  
   (Did I understand your scenario correctly?)
   Regards,
   -Chris
  
   At 07:26 PM 10/24/2003 +1000, Thomas Beale wrote:
   Sam Heard sam.heard at bigpond.com, wrote:
   
 CONTRIBUTION - 2 versions at once

 There is a particular problem with results that are deemed to be
  incorrect
 as the specimen is damaged - haemolysed blood samples being the
most
  common
 (See textural results to quantities thread). If the machine read
data
  is to
 be preserved in openEHR then this would need to be over written
with
  the
 correct result and both compositions saved at the same time -
  otherwise
some
 other agent might base some process on the interim situation where
the
first
 composition is saved even for a microsecond. We think this relates
to
 machine processed data - but keeping medical student entries might
be
  dealt
 with in some environments in the same manner.
   
   I don't see the problem here. This is the classic version control
  situation
   which the model deals with. The preliminary result comes into the EHR
and
  is
   recorded as an ENTRY in some COMPOSITION. This is the result that is
  available
   for say a couple of days. Presumably it should be marked
PRELIMINARY!
  in
   red...one might argue that there is a need for an attribute to
support
  this
   (in old GEHR days, there was the idea of a Nota Bene field). Anyone
who
  makes
   a clinical decision on this result is safe, as long as it is accepted
  that any
   actions at all are allowed based on preliminary results.
   
   When the true resulst comes in two lays later, it replacs the
original as
  a
   new version of the same COMPOSITION. Accessors of the EHR now see
 the
  latest
   version (not marked preliminary...), and things go on as normal.
   
   
   I think a problem that could occur is if lab A does a test and sends
the
   result in (and it goes in the EHR), then a clinician

Pathology requirements TEXTURAL RESULTS TO QUANTITIES

2003-10-24 Thread Vincent McCauley

I think the fact that some results are a mean calculated by a human
is a red-herring.
In fact nearly all numerical analyte values from automated machines
are a mean of a number of estimates - part of the internal quality control
is that the
standard deviation of these estimates is acceptable - this is just hidden
under the hood.

Some systems certainly record a value of 0, instead of, or in a addition to,
zero RBC per HPF.

How many HPF's are examined and acceptable values for the SD
when done manually are all part of the analysis technique used
and not generally stored in the patients paper record, let alone EHR.

Regards
Vince

Vincent McCauley MB BS, Ph.D

- Original Message - 
From: Tim Churches tc...@optushome.com.au
To: Tim Churches tchur at optushome.com.au
Cc: Sam Heard sam.heard at bigpond.com; Openehr-Technical
openehr-technical at openehr.org
Sent: Thursday, October 23, 2003 17:25
Subject: Re: Re: Pathology requirements TEXTURAL RESULTS TO QUANTITIES


 Tim Churches tchur at optushome.com.au wrote:
 
  Sam Heard sam.heard at bigpond.com wrote:
  
   TEXTURAL RESULTS TO QUANTITIES
 
  ?TEXTUAL?
 
  This raises the general issue of how mixed categorical/ordinal/scalar
  quantities
  are handled eg (made up example) haematuria: Trace-x RBC/ml - Gross
 
  haematuria.

 Sorry, brain-fade. I meant x RBC/HPF (per high power field) or similar.
This is an
 example of a sampled result i.e. a random sample of portions of a
specimen
 are examined and a mean is reported. The mean is quantitative, but is just
a
 point estimate of the central tendency of an underlying probability
density
 function. Thus it may have a std dev or confidence intervals associated
with it.
 Also, in this circumstance zero doesn't really mean zero and is generally
not
 reported as such: if no RBC were seen in any HPF, then it will be reported
 as No RBC seen, not as mean RBC/HPF = 0. Generalising this, scalars
 which parameterise a probability distribution are different from scalars
which are
 precise quantities - or are they? Hmmm.

 Tim C


  Conceivably some use might be made of the numbers, as
  opposed
  to the ordinal categorical extrema?
 
  Tim C
  -
  If you have any questions about using this list,
  please send a message to d.lloyd at openehr.org

 -
 If you have any questions about using this list,
 please send a message to d.lloyd at openehr.org




-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Pathology requirements UNITS