Question about Composition.category

[Ian McNicoll]

Hi Pablo

The only current allowed values are event and persistent. I am not quite
sure what process might mean in this context. This was clearly some
philosophical musing when the spec was written but I have not come across a
need for this when modelling so far. I have requested a change to allow a
persistent composition to have a context attribute , currently disallowed.
Episodic care such as hospital admission does throw up the need for
persistent compositions to carry the context of the episode but persist
throughout that episode. eg a problem list for the current admission.

Ian

Dr Ian McNicoll
Clinical modelling consultant Ocean Informatics
Mobile +44 (0) 775 209 7859
Skype imcnicoll

On 3 Oct 2012, at 00:00, pablo pazos pazospablo at hotmail.com wrote:

 Hi all,

As usual I'm reviewing the specs  the openEHR terminology.
I understand the event and persistent values for the Composition.category
property.
There is also a process value, but I don't understand the difference
between event and process. The specs are not clear here:

Indicates what broad category this Composition is belogs to, e.g.
?persistent? - of longitudinal validity, ?event?, ?process? etc.

Any thoughts?

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos http://twitter.com/ppazos

___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121003/669b9c96/attachment.html

Issue (probably known) with ADL Workbench

[Peter Gummer]

pablo pazos wrote:

 Hi Ian, Peter was right, the issue was because I've installed ADLWB 
 v1.4.1.595 in my notebook.
 
 I downloaded the ADLWB from here: 
 http://wiki.oceaninformatics.com/confluence/display/TTL/ADL+Workbench+Releases
 And this page lead my to the old download page: 
 http://wiki.oceaninformatics.com/confluence/display/TTL/ADL+Workbench
 
 That last link is the first result when adl workbench is searched using 
 google. Maybe that page could be updated to link the new ADLWB download page: 
 http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html


Maybe google is doing that because the proper download page (on openehr.org) 
has a heading of AWB Home and a title of ADL 1.5 Workbench. I guess google 
gets as confused by acronyms as I do ;-)

I've edited the ADL Workbench page that you found on the Ocean wiki. The 
Current Release now links to the openehr.org download page.

Thanks for pointing this out, Pablo.

Peter

lessons from Intermountain Health, and starting work on openEHR 2.x

[pablo pazos]

+1 I think you're about to hit the right spot, it seems to be very near to THE 
solution for interoperability  reuse at a model level.
Learning from the Internet approach (the biggest example of interoperability in 
the world, that actualy works) the multi-component or multi-layered idea seems 
the right idea: having a common core for layer 1, a bussiness layer with EHRs, 
... seems just right.
Another big advantage of this approach is the gradual implementation 
capability: I can implement  certify a layer 1 implementation, then implement 
layer 2, ...

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

Date: Wed, 3 Oct 2012 23:19:28 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: lessons from Intermountain Health, and starting work on openEHR
2.x


  

  
  
On 03/10/2012 23:02, Thomas Beale
  wrote:



  
  On 13/09/2012 10:15, David Moner
wrote:

  
  Hi,



2012/9/13 Erik Sundvall erik.sundvall at liu.se

   It would
be great if e.g most of the future ISO 13606 version could
be a true subset of openEHR instead of the current confusing
situation. 



This is something I discussed with Thomas some time ago, it
would be one of the best harmonisation solutions, but probably
with a slightly different interpretation. Since 13606 has more
generic classes (eg. the generic ENTRY can represent all of
OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead of 13606
being a subset of openEHR I think that openEHR should be a
specialized model of 13606. Obviously this would require a deep
analysis and changes of the models, but that could be the idea.
  
  

  I don't care about the linguistics of subset / specialisation etc,
  I just care about getting one model 

  

  - thomas




although - it will probably come out to have multiple entry points.
The 13606 model is about what makes sense in EHR Extract messages.
We built and implemented a more recent version of that, using
lessons from 13606 - the openEHR EHR Extract. There are undoubtedly
a lot of lessons from 13606 Extract use out there (there must be
because nearly everyone implements the standard by changing, so that
says something!).



However, other parts of openEHR are concerned with the logical
semantics of in situ EHRs, not just messages travelling between
systems. So I think there could be a common core, an EHR part and an
EHR Extract part. Having one standard for that would be hugely
useful for industry.



- thomas



  


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121003/6a07e5fc/attachment.html