Empty string for DV_TEXT

2010-06-26 Thread Ian McNicoll
Hi Leo,

An important principle under-pinning openEHR is that 'empty' data is not
normally recorded, which is consistent with general clinical practice
information recording.

On this basis, I am not sure I can see the use case for recording  i.e.
Empty text. If a text data entry field is left blank, this would simply not
be recorded in openEHR data. If the field is mandatory, either the user is
forced to make some sort of entry or perhaps is allowed to select one of the
null values as you suggest.

Regards,

Ian

Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
ian at mcmi.co.uk

Clinical Analyst  Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland



On 25 June 2010 16:07, Moretti Leonardo lmoretti at noemalife.com wrote:

 In
 http://www.openehr.org/releases/1.0.2/architecture/rm/data_types_im.pdf,
 DV_TEXT is defined as a text item. Among Invariants (page 29), I found
 that this data type is valid if it is not empty (Value_valid: value /=
 void and then not value.is_empty and then not(value.has(CR) or
 value.has(LF))).

 Does this mean empty string is not a valid value for DV_TEXT? If so, why
 empty string cannot be a valid value? An empty string could be
 meaningful, with a different semantic than null value! Many textual
 information could be an empty string (comments, descritpions..). An
 empty string means that the value is exactly a void string, a null value
 means that the information is unknown, not taken, not asked!

 Regards
 leo

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

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


Decision Support Providers

2010-06-26 Thread Ian McNicoll
There is 'Virtual EMR' project going on in HL7 do to exactly this sort of
work i.e a relatively simple interface/ service against which decision
support cab operate consistently -
http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_(vMR)

The big problem they will face, as ever, is defining the detailed clinical
content in a manageable and scalable fashion.

I think the openEHR approach to content definition has definite advantages.

Ian

Dr Ian McNicoll
office / fax  +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com
ian at mcmi.co.uk

Clinical Analyst  Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland



On 25 June 2010 16:24, Shannon Tony (Leeds Teaching Hospitals NHS Trust) 
tony.shannon at nhs.net wrote:

 FYI..

 A thought provoking post from John Halamka on decision support providers as
 service.

 http://geekdoctor.blogspot.com/2010/06/decision-support-service-providers.html
 Some of you might have complementary/alternative views as to how this might
 work within an openEHR enabled landscape...

 Rong
 Would you like to comment?
 Your recent work covered some of this key territory..

 Regards,

 Tony


 

 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


 


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

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100626/3675df9b/attachment.html


Medinfo 2010 openEHR workshop

2010-06-26 Thread Ian McNicoll
 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


 

 --
 Dr Heather Leslie
 MBBS FRACGP FACHI
 Director of Clinical Modelling
 Ocean Informatics
 Phone (Aust) +61 (0)418 966 670
 Skype - heatherleslie
 Twitter - @omowizard

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



 

 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


 


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

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


Decision Support Providers

2010-06-26 Thread Thomas Beale
On 26/06/2010 13:57, Ian McNicoll wrote:
 There is 'Virtual EMR' project going on in HL7 do to exactly this sort 
 of work i.e a relatively simple interface/ service against which 
 decision support cab operate consistently - 
 http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_(vMR) 
 http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_%28vMR%29

 The big problem they will face, as ever, is defining the detailed 
 clinical content in a manageable and scalable fashion.

 I think the openEHR approach to content definition has definite 
 advantages.

 *
 *

If you look at the domain model on which the vMR is designed 
(http://wiki.hl7.org/index.php?title=Image:HL7vMR_vMR_Domain_Analysis_Model_v2010-03-22.zip)
 
you will see that it is a very fixed model of clinical concepts.  I am 
not sure how they expect that queries for changed versions of these 
concepts or different concepts be done. The vMR job is actually the kind 
of thing openEHR is really designed to do well, with the following elements:

* standard reference model
* standard way of representing any clinical or other domain concept
  - archetypes  templates
* standard way of querying the data - AQL, a-path or other
  archetype-based approaches
* service interface for making fine-grained changes to data (some
  specification proposals at
  http://www.openehr.org/wiki/display/spec/vEHR+Service+Specification)

GELLO or something similar then has a place 'above the line' for 
representing guidelines that need to be executed against the EHR.

- thomas beale

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100626/4f09daca/attachment.html


Decision Support Providers

2010-06-26 Thread William E Hammond
Hi Thomas,

I am now back at Duke in a full time capacity.  The work within HL7 is
being lead by Ken Kawamoto from Duke, a colleague of mine.  Duke has one fo
the best clinical research enterprises in the world - the Duke Clinical
Research Institute and the new Duke Translational Medical Institute, where
the Duke Center for Health Informatics is based.  We have asignificant
weffort committed to defining detailed clinical content.  I'd say let's
postpone the decision (as ever) for a couple of years and see if we are as
bad as you think.

Actullay, we have an effort similar to Evelyn's and look forward to working
with her.

W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics


   
 Thomas Beale  
 thomas.beale at oce 
 aninformatics.com  To 
  openehr-technical at openehr.org   
 Sent by:   cc 
 openehr-technical 
 -bounces at openehr. Subject 
 org   Re: Decision Support Providers  
   
   
 06/26/2010 11:57  
 AM
   
   
 Please respond to 
For openEHR
 technical 
discussions
 openehr-technica 
  l at openehr.org   
   
   




On 26/06/2010 13:57, Ian McNicoll wrote:
  There is 'Virtual EMR' project going on in HL7 do to exactly this
  sort of work i.e a relatively simple interface/ service against which
  decision support cab operate consistently -
  http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_(vMR)

  The big problem they will face, as ever, is defining the detailed
  clinical content in a manageable and scalable fashion.

  I think the openEHR approach to content definition has definite
  advantages.



If you look at the domain model on which the vMR is designed (
http://wiki.hl7.org/index.php?title=Image:HL7vMR_vMR_Domain_Analysis_Model_v2010-03-22.zip
) you will see that it is a very fixed model of clinical concepts.  I am
not sure how they expect that queries for changed versions of these
concepts or different concepts be done. The vMR job is actually the kind of
thing openEHR is really designed to do well, with the following elements:
  standard reference model
  standard way of representing any clinical or other domain concept -
  archetypes  templates
  standard way of querying the data - AQL, a-path or other
  archetype-based approaches
  service interface for making fine-grained changes to data (some
  specification proposals at
  http://www.openehr.org/wiki/display/spec/vEHR+Service+Specification)
GELLO or something similar then has a place 'above the line' for
representing guidelines that need to be executed against the EHR.

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





Decision Support Providers

2010-06-26 Thread Thomas Beale

Hi Ed,

I didn't say it was bad (it is probably very good) - I said it was 
'fixed'. Like CCR - which as far as I understand is very good domain 
modelling - but also pretty fixed. The debate here is about 'how' not 
'what'. If I was working on the vMR in HL7 right now, the first thing I 
would do would be to copy exactly the content you have modelled in the 
diagram I referred to - in to archetypes and templates. Then I would get 
for free:

* the ability to change it with no changes to any reference model
  (information remains valid)
* the ability to add completely new things, also without requiring
  any changes in the underlying information model
* the ability to query everything in a generic fashion using queries
  based directly on the domain models

This argument is the same as with all the *MIMs in HL7 - as a technology 
I don't think they work, but I don't question their content (in most 
cases I am not competent to do that). I would really love the 
opportunity to show you how nice this model could be if modelled in 
archetypes in an openEHR system. You would get just what you want with 
much greater flexibility. Please don't think I would seriously question 
Duke's clinical work. I just think you are working with the wrong IT;-)

regards

- thomas


On 26/06/2010 19:28, William E Hammond wrote:
 Hi Thomas,

 I am now back at Duke in a full time capacity.  The work within HL7 is
 being lead by Ken Kawamoto from Duke, a colleague of mine.  Duke has one fo
 the best clinical research enterprises in the world - the Duke Clinical
 Research Institute and the new Duke Translational Medical Institute, where
 the Duke Center for Health Informatics is based.  We have asignificant
 weffort committed to defining detailed clinical content.  I'd say let's
 postpone the decision (as ever) for a couple of years and see if we are as
 bad as you think.

 Actullay, we have an effort similar to Evelyn's and look forward to working
 with her.



*
*
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100626/2a8929f5/attachment.html


Decision Support Providers

2010-06-26 Thread William E Hammond
Actually, my e-mail was more of a hello.  I didn't think you were giving
Duke a hard time.  Our approach is similiar to what you are doing, however,
we are focusing at the atomic level.  Building from that is simply a
construct.  It will be i nteresting to find out what stays packaged and
what breaks out.  My approach is to make the data independent of the
construction.  If the data element is never dealth with without thw full
structure we will keep it packaged; else not.  I think we let our
experiences influence how we move forward.  But as you know, I try to pay
attention to what everyone is doin g so I can use the best approaches.

W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics


   
 Thomas Beale  
 thomas.beale at oce 
 aninformatics.com  To 
  openehr-technical at openehr.org   
 Sent by:   cc 
 openehr-technical 
 -bounces at openehr. Subject 
 org   Re: Decision Support Providers  
   
   
 06/26/2010 04:16  
 PM
   
   
 Please respond to 
For openEHR
 technical 
discussions
 openehr-technica 
  l at openehr.org   
   
   





Hi Ed,

I didn't say it was bad (it is probably very good) - I said it was 'fixed'.
Like CCR - which as far as I understand is very good domain modelling - but
also pretty fixed. The debate here is about 'how' not 'what'. If I was
working on the vMR in HL7 right now, the first thing I would do would be to
copy exactly the content you have modelled in the diagram I referred to -
in to archetypes and templates. Then I would get for free:
  the ability to change it with no changes to any reference model
  (information remains valid)
  the ability to add completely new things, also without requiring any
  changes in the underlying information model
  the ability to query everything in a generic fashion using queries
  based directly on the domain models
This argument is the same as with all the *MIMs in HL7 - as a technology I
don't think they work, but I don't question their content (in most cases I
am not competent to do that). I would really love the opportunity to show
you how nice this model could be if modelled in archetypes in an openEHR
system. You would get just what you want with much greater flexibility.
Please don't think I would seriously question Duke's clinical work. I just
think you are working with the wrong IT;-)

regards

- thomas


On 26/06/2010 19:28, William E Hammond wrote:
  Hi Thomas,

  I am now back at Duke in a full time capacity.  The work within HL7
  is
  being lead by Ken Kawamoto from Duke, a colleague of mine.  Duke has
  one fo
  the best clinical research enterprises in the world - the Duke
  Clinical
  Research Institute and the new Duke Translational Medical Institute,
  where
  the Duke Center for Health Informatics is based.  We have
  asignificant
  weffort committed to defining detailed clinical content.  I'd say
  let's
  postpone the decision (as ever) for a couple of years and see if we
  are as
  bad as you think.

  Actullay, we have an effort similar to Evelyn's and look forward to
  working
  with her.



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