Small question about commits and AUDIT_DETAILS.system_id

[pablo pazos]

I found an issue mentioning the system_id but I don't know if it's related with 
this thread (don't understand 100% the change description), also it says that 
is closed: http://www.openehr.org/issues/browse/SPEC-165

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

Date: Fri, 5 Sep 2014 18:30:02 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: Small question about commits and AUDIT_DETAILS.system_id


  

  
  


  Pablo,

  

  you may have already done this, but please make sure there is an
  issue on the issue
tracker to capture this. If you include various email
  responses in the 'description' section that will help.

  

  I actually think that the 'system' should refer to a domain name,
  not a 'soft name'. But in the long term, neither may be reliable.

  

  - thomas

  

  On 05/09/2014 18:06, pablo pazos wrote:



  
  
  Hi! Thanks for your answers.



It is a little tricky but from Thomas comments, I think
  that the system is not a technical term, but is more related
  to an organizational term. For example, if I use the same
  system / service to hold EHRs from 2 different hospitals, I
  really have 2 system ids instead of one. So the system_id
  doesn't depend on the technical architecture, but depends on
  how the business is organized. Is that correct?
  

  
  Again, the description from the specs doesn't help to
understand this (Identity of the system where the change
was committed, so it depends on what a system is for us).
  

  
  For the next version of the specs I think we can update
that description and maybe give a couple of examples.
  

  
  What do you think?



-- 

Kind regards,

Eng. Pablo Pazos Guti?rrez

http://cabolabs.com




  Date: Thu, 21 Aug 2014 09:47:35
  +0100

  From: thomas.beale at oceaninformatics.com

  To: openehr-technical at lists.openehr.org

  Subject: Re: Small question about commits and
  AUDIT_DETAILS.system_id

  

  

Heath,



this is correct, you were not wrong for 10 y ;-)



We don't record the name or type or id of the
application, and I am not sure even now if that would be
of any use. I can't see that it would be. The system_id
is for exactly the purpose that Heath as explained here.



- thomas





On 21/08/2014 00:27, Heath Frankel wrote:

  
  


  Hi

  Thomas  Pablo,
  I
  am finding the words in the this discussion
  ambiguous, and the specification does help to
  clarify. Here is my interpretation of
  AUDIT_DETAILS.system_id.
   
  I
  have an EHR service, which is used by two
  different application, one is a hospital system
  and another a mobile application that may not be
  related to the hospital system but share the same
  EHR service. When the hospital system and mobile
  application commits something they are using the
  same system_id, the system_id of the EHR service.
  If there is an exchange of data between this EHR
  service and another organisations EHR service via
  an EHR extract, the system ID will be used in the
  other organisations EHR service to identify that
  the commit was performed in the original
  organisations system_id. 
   
  Therefore,

  the system_id identifies the system that is
  assigning version identifiers in the EHR
  repository, i.e. the AUDIT_DETAILS.system_id
  matches the system_id component of the
  version.uid. This is important for distributed
  versioning.
   
  So

  in Pablo?s scenario, it is one system of multiple
  components with multiple components sharing the
  same EHR service, the mobile and the EMR would use
  the same system_id

Small question about commits and AUDIT_DETAILS.system_id

[pablo pazos]

Thanks Heath.
Can others comment on this to have a unified view and specific definition of 
the system id?
I think i have 3 different definitions right now, and one contradicts the other 
:)
Maybe the system_id hasn't a specific definition so might be used differently 
by different implementations. (?)
In the end is just an id, does it matter if it's attached to a system or 
service or if it's something related to an organization or if it's a host 
domain?
What do you think?

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: RE: Small question about commits and AUDIT_DETAILS.system_id
Date: Sun, 7 Sep 2014 23:25:43 +








Hi Pablo,

No I don't agree. The point I tried to explain was that the system is the EHR 
repository, not an application. So if there is one or more applications using a 
repository at one or more organisations the is just one system id.



In an Australian jurisdiction I have a repository that is used by multiple 
instances of 5 applications at 100 diff healthcare facilities managed by gov't 
and non gov't organisations. There is only one system id for the repository.



Heath








 Original Message 

Subject: RE: Small question about commits and AUDIT_DETAILS.system_id

From: pablo pazos pazospa...@hotmail.com

To: openeh technical openehr-technical at lists.openehr.org

CC: 




Hi! Thanks for your answers.



It is a little tricky but from Thomas comments, I think that the system is 
not a technical term, but is more related to an organizational term. For 
example, if I use the same system / service to hold EHRs from 2 different 
hospitals, I really have 2 system
 ids instead of one. So the system_id doesn't depend on the technical 
architecture, but depends on how the business is organized. Is that correct?



Again, the description from the specs doesn't help to understand this 
(Identity of the system where the change was committed, so it depends on what 
a system is for us).



For the next version of the specs I think we can update that description and 
maybe give a couple of examples.



What do you think?



-- 

Kind regards,

Eng. Pablo Pazos Guti?rrez

http://cabolabs.com





Date: Thu, 21 Aug 2014 09:47:35 +0100

From: thomas.be...@oceaninformatics.com

To: openehr-technical at lists.openehr.org

Subject: Re: Small question about commits and AUDIT_DETAILS.system_id





Heath,



this is correct, you were not wrong for 10 y ;-)



We don't record the name or type or id of the application, and I am not sure 
even now if that would be of any use. I can't see that it would be. The 
system_id is for exactly the purpose that Heath as explained here.



- thomas





On 21/08/2014 00:27, Heath Frankel wrote:




Hi Thomas  Pablo,
I am finding the words in the this discussion ambiguous, and the specification 
does help to clarify. Here is my interpretation of AUDIT_DETAILS.system_id.
 
I have an EHR service, which is used by two different application, one is a 
hospital system and another a mobile application that may not be related to
 the hospital system but share the same EHR service. When the hospital system 
and mobile application commits something they are using the same system_id, the 
system_id of the EHR service. If there is an exchange of data between this EHR 
service and another
 organisations EHR service via an EHR extract, the system ID will be used in 
the other organisations EHR service to identify that the commit was performed 
in the original organisations system_id.

 
Therefore, the system_id identifies the system that is assigning version 
identifiers in the EHR repository, i.e. the AUDIT_DETAILS.system_id matches the
 system_id component of the version.uid. This is important for distributed 
versioning.
 
So in Pablo?s scenario, it is one system of multiple components with multiple 
components sharing the same EHR service, the mobile and the EMR would use
 the same system_id.
 
Has my interpretation been wrong for 10 years? If so, then we need clarity 
added to the specification.
 






___ openEHR-technical mailing list 
openEHR-technical at lists.openehr.org 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org







___
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/20140908/655d1448/attachment.html

Commits and Contributions

[pablo pazos]

Hi Heath,

What do you mean by commit uid, is that the CONTRIBUTION.uid?

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: RE:  Commits and Contributions
Date: Sun, 7 Sep 2014 23:32:58 +








The commit uid is generated by the ocean EHR client, this is consistent with a 
git commit. All this is is a GUID so easy to do. Although I set the commit time 
on the client, I override this on server.



Heath








 Original Message 

Subject: Commits and Contributions

From: pablo pazos pazospa...@hotmail.com

To: openeh technical openehr-technical at lists.openehr.org

CC: 




Hi, I'm working on EHRServer, trying to improve how the XML is committed and 
processed to simplify querying.



Right now I have a web app that commits a list of VERSIONs to the EHRServer. 
That service is based on the Ocean's commitContribution service 
http://www.openehr.org/wiki/display/spec/Ocean+Informatics+EHR+Service+Interface



The CONTRIBUTION instance for the committed VERSIONs is created by the 
EHRServer, but the VERSIONs come in XML format. Looking at the openEHR XSDs, 
each VERSION needs an OBJECT_REF to a CONTRIBUTION. Since the CONTRIBUTION is 
created by the EHRServer,
 the VERSION XML doesn't have the OBJECT_REF, so it's invalid against the 
openEHR XSDs.






What can I do?



1. Create the CONTRIBUTION at the client side and commit both, CONTRIBUTION and 
VERSIONs.
2. Add dummy XML to each VERSION just to pass the XSD validation.
3. Modify the openEHR schemas to add minOccurs=0 to the version.contribution 
element.
4. Other?






Why I think these solutions are not so good:



1. IMO the role of the server is to create the CONTRIBUTION, because it's like 
a log for the commit, also the Ocean's service doesn't receive a CONTRIBUTION 
object.

2. I don't like adding stuff I will not use but seems the less problematic 
solution.
3. For me this is terrible, I want to play with the openEHR rules, not make my 
own, but it is just for the commit, so if I want to send compositions to an 
external system, that will be valid against the original openEHR XSDs because 
in the EHRServer I
 have the CONTRIBUTION.






What do you think? Do you have a better solution? Thanks!


-- 

Kind regards,

Eng. Pablo Pazos Guti?rrez

http://cabolabs.com





___
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/20140911/d376442e/attachment.html

Missing DV_PROPORTION validity rule?

[pablo pazos]

Hi, I'm adding support to more datatypes to EHRServer and was surprised that 
the DV_PROPORTION specs doesn't define that the denominator should be != 0.
Is this on purpose?Is _infinite_ a valid value for DV_PROPORTION.magnitude()?Or 
is just a missing validity rule?

thanks!

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com   
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140929/7875ec00/attachment.html

Small question about commits and AUDIT_DETAILS.system_id

[pablo pazos]

I've created the issue on JIRA:
http://www.openehr.org/issues/browse/SPECPR-99

Hope this helps to clarify the use of the system_id :)

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: colin.sut...@ctc.usyd.edu.au
To: openehr-technical at lists.openehr.org
Subject: Re: Small question about commits and AUDIT_DETAILS.system_id
Date: Mon, 8 Sep 2014 17:34:55 +






Instead of system_id, should it be called the EHR_service_id or the 
repository_id?
To be meaningful, should there be a reference service to allocate a unique id 
to each service/repository, or should the system_id be a URL?



Colin






On 9 Sep 2014, at 2:06 am, pablo pazos pazospablo at hotmail.com wrote:



Thanks Heath.



Can others comment on this to have a unified view and specific definition of 
the system id?



I think i have 3 different definitions right now, and one contradicts the other 
:)



Maybe the system_id hasn't a specific definition so might be used differently 
by different implementations. (?)



In the end is just an id, does it matter if it's attached to a system or 
service or if it's something related to an organization or if it's a host 
domain?



What do you think?



-- 

Kind regards,

Eng. Pablo Pazos Guti?rrez

http://cabolabs.com





From: heath.fran...@oceaninformatics.com

To: openehr-technical at lists.openehr.org

Subject: RE: Small question about commits and AUDIT_DETAILS.system_id

Date: Sun, 7 Sep 2014 23:25:43 +



Hi Pablo,

No I don't agree. The point I tried to explain was that the system is the EHR 
repository, not an application. So if there is one or more applications using a 
repository at one or more organisations the is just one system id.



In an Australian jurisdiction I have a repository that is used by multiple 
instances of 5 applications at 100 diff healthcare facilities managed by gov't 
and non gov't organisations. There is only one system id for the repository.



Heath








 Original Message 

Subject: RE: Small question about commits and AUDIT_DETAILS.system_id

From: pablo pazos pazospa...@hotmail.com

To: openeh technical openehr-technical at lists.openehr.org

CC: 




Hi! Thanks for your answers.



It is a little tricky but from Thomas comments, I think that the system is 
not a technical term, but is more related to an organizational term. For 
example, if I use the same system / service to hold EHRs from 2 different 
hospitals, I really have 2 system
 ids instead of one. So the system_id doesn't depend on the technical 
architecture, but depends on how the business is organized. Is that correct?



Again, the description from the specs doesn't help to understand this 
(Identity of the system where the change was committed, so it depends on what 
a system is for us).



For the next version of the specs I think we can update that description and 
maybe give a couple of examples.



What do you think?



-- 

Kind regards,

Eng. Pablo Pazos Guti?rrez

http://cabolabs.com





Date: Thu, 21 Aug 2014 09:47:35 +0100

From: thomas.be...@oceaninformatics.com

To: openehr-technical at lists.openehr.org

Subject: Re: Small question about commits and AUDIT_DETAILS.system_id





Heath,



this is correct, you were not wrong for 10 y ;-)



We don't record the name or type or id of the application, and I am not sure 
even now if that would be of any use. I can't see that it would be. The 
system_id is for exactly the purpose that Heath as explained here.



- thomas





On 21/08/2014 00:27, Heath Frankel wrote:




Hi Thomas  Pablo,
I am finding the words in the this discussion ambiguous, and the specification 
does help to clarify. Here is my interpretation
 of AUDIT_DETAILS.system_id.
 
I have an EHR service, which is used by two different application, one is a 
hospital system and another a mobile application that
 may not be related to the hospital system but share the same EHR service. When 
the hospital system and mobile application commits something they are using the 
same system_id, the system_id of the EHR service. If there is an exchange of 
data between this EHR
 service and another organisations EHR service via an EHR extract, the system 
ID will be used in the other organisations EHR service to identify that the 
commit was performed in the original organisations system_id.
 
Therefore, the system_id identifies the system that is assigning version 
identifiers in the EHR repository, i.e. the AUDIT_DETAILS.system_id
 matches the system_id component of the version.uid. This is important for 
distributed versioning.
 
So in Pablo?s scenario, it is one system of multiple components with multiple 
components sharing the same EHR service, the mobile
 and the EMR would use the same system_id.
 
Has my interpretation been wrong for 10 years? If so, then we need clarity 
added to the specification.
 






___ openEHR-technical mailing list 
openEHR-technical at 
lists.openehr.orghttp

ADL 2 Workbench update - alpha of next release available

[pablo pazos]

Hi Thomas,
Does it have ADL 1.5 / 2 editing capabilities?

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

Date: Tue, 3 Feb 2015 11:14:34 +
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: ADL 2 Workbench update - alpha of next release available


  

  
  


There are Windows, Linux and Mac builds of the next release 2.0.6 of
the ADL WB available
  here, which contain:


  single file templating support (make sure your clone of
adl-archetypes is up to date, see the library adl2_template

  
  rewritten export feature (Archetypes  Export)
  performance improvements

- 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/20150203/ea4fa022/attachment.html

ADL 2 Workbench update - alpha of next release available

[pablo pazos]

I will have some free time next week, do you want me to beta test it and create 
a small report for you? (bugs, improvements , etc).
-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

Date: Tue, 3 Feb 2015 15:29:53 +
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: ADL 2 Workbench update - alpha of next release available


  

  
  
On 03/02/2015 15:17, pablo pazos wrote:



  
  
  Hi Thomas,



Does it have ADL 1.5 / 2 editing capabilities?


  



partial. You can create a new archetype, template, specialised
archetype by right-click on the appropriate node in the explorer of
the library you are in. You can then either a) use the ADL source
tab and/or b) right-click on the new archetype/template in the
explorer and do 'edit' (the orange icon) and then in the definition
view, some right click operations work. It's pretty alpha, and is
being slowly worked on.



- 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/20150203/7b08f45b/attachment.html

UITemplates for openEHR / towards generic UI definition and automatic generation

[pablo pazos]

Thanks Ricardo, BTW here is the paper: 
https://www.academia.edu/9882392/Generaci%C3%B3n_autom%C3%A1tica_de_interfaces_de_usuario_para_sistemas_de_informaci%C3%B3n_cl%C3%ADnicos_basados_en_una_metodolog%C3%ADa_multi-nivel

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: ricardo.jc.corr...@gmail.com
Date: Tue, 30 Dec 2014 08:04:47 +
Subject: Re: UITemplates for openEHR / towards generic UI definition and
automatic generation
To: openehr-technical at lists.openehr.org; openehr-implementers at 
lists.openehr.org

Great work Pablo.

A ter, 30/12/2014, 03:23, pablo pazos pazospablo at hotmail.com escreveu:



Hi all,
As some might know I did some work around openEHR and UI generation for medical 
records in the EHRGen app. Last year we finished a project at Facultad de 
Ingenier?a (http://www.fing.edu.uy/) to improve the solution provided by EHRGen 
to generate UI forms. The solution was a very rudimentary XML UI definition and 
a generator just for web desktop (big screens). Now this solutions has been 
improved a lot, defining a very generic, technology agnostic UITemplate model 
with a lot of possible customizations, with an XML expression.
We have published a paper on this that was presented at INFOLAC2014 
(http://infolac2014.org/), and I've the project's documentation. All of this is 
in Spanish only, sorry :(
That project also involved the specification of mappings with specific 
technologies and the creation of a UI generator. Feeding the generator with a 
UITemplate in XML and a mapping file, generates UI artifacts that can be 
integrated into openEHR EHR/EMR developments. With these mappings, we can 
generate HTML5, XHTML, XAML (.Net) or SwiXML (Java Swing) user interfaces, and 
with more extensions/mapping files, the generator can create virtually any UI 
artifact (declarative UI). For example to generate HTML-based screens for 
mobile devices or native mobile screens using a declarative syntax.
Then artifacts should be processed and rendered: HTML is processed by a web 
browser, XAML y processed by Visual Studio to generate win forms or web forms, 
SwiXML specifications are processed by http://www.swixml.org/, etc.
I'm working on an specification of the UITemplate model, and later I'll add the 
XML serialization of the model (XSDs included). This will be in English.
For anyone interested on this topic, I kindly ask you to review this doc and 
comment if you find any errors, not so clear descriptions, questions and maybe 
UI requirements not contemplated by the model. All the feedback is very 
welcome! (please consider this is work in progress)
https://docs.google.com/document/d/1BLpr5lVdSb86G3EIhplMNBaT34QgNqIGJdFRd5P4APM/edit?usp=sharing


Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com   
___

openEHR-technical mailing list

openEHR-technical at lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
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/20150102/041f771c/attachment.html

MedInfo 2015 openEHR tutorials

[pablo pazos]

Hi all, I'm also finalizing the proposal for the clinical database workshop, 
please review it here:
https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554760
If anyone wants to modify or add anything, just add a comment on the wiki.

The deadline is next week, please hurry up if you want to review the contents.
Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

 From: skoba at moss.gr.jp
 Date: Thu, 8 Jan 2015 01:45:04 +0900
 Subject: Re: MedInfo 2015 openEHR tutorials
 To: openehr-implementers at lists.openehr.org
 CC: openehr-technical at lists.openehr.org; openehr-clinical at 
 lists.openehr.org
 
 Hi colleagues,
 
 Can I finalize this developers' workshop proposal?
 https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554784
 
 Today is just before one week to the workshop deadline.
 
 Shinji KOBAYASHI
 
 2014-12-18 20:52 GMT+09:00 Shinji KOBAYASHI skoba at moss.gr.jp:
  Hi colleagues,
 
  I am preparing to submit openEHR developers' workshop in this openEHR wiki 
  page.
  https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554784
  If you got interested in participating this workshop, please add your
  name and brief summary(100-200 words) of your project on this wiki
  until Dec 31 2014. Anyone can join this workshop, if you have working
  on development around openEHR.
  Thank you for your concern about this workshop and contributing on
  wiki. I am looking forward to meeting you in Sao Paolo.
 
  Shinji KOBAYASHI
 
  2014-10-30 17:21 GMT+09:00 Luis Marco luismarco at gmail.com:
  Hi Pablo,
  I will be in Medinfo therefore we can coordinate together the Spanish
  language resources ;-)
  Regards,
  Luis
 
  2014-10-29 17:14 GMT+01:00 pablo pazos pazospablo at hotmail.com:
 
  Hi Sam,
 
  I think right now the tutorial organization is happening in a very organic
  way: people are sharing they proposals so others can collaborate or detect
  possible overlaps.
 
  If we need a group to centralize coordination or communication with
  MedInfo organizers/chairs, I would propose the people interested no giving
  tutorials that is mentioned here:
  http://www.openehr.org/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2C+Brazil
 
 
  On my part, I don't have resources to have an stand (flight + hotel +
  conference fee is not cheap for us), but if I can help in any way, e.g. 
  the
  community can use me as an spanish speaker interlocutor, I'll be more than
  happy to help and add my grain of sand.
 
 
  About training, I'm doing a small survey to see what people think about
  the proposals already discussed on the lists. My goal is to curate that 
  and
  to reach a new level of discussions beyond ideas. I don't have Heather
  Grain's email, I'll gladly send her my little survey (Already sent to
  Heather L and Evelyn).
 
  Cheers,
  Pablo.
 
  --
  Kind regards,
  Eng. Pablo Pazos Guti?rrez
  http://cabolabs.com
 
  
  From: sam.heard at openehrfoundation.org
  To: openehr-clinical at lists.openehr.org
  Subject: Re: MedInfo 2015 openEHR tutorials
  Date: Sun, 26 Oct 2014 04:50:10 +
  CC: openehr-technical at lists.openehr.org;
  openehr-implementers at lists.openehr.org
 
  Thanks Pablo
 
  Good feedback. It has been difficult to keep up with everything and I am
  in no way trying to impede any activity. I believe this is the first
  International Medinfo in a country where openEHR is up and running.
 
  My wish is to have a group that coordinate the effort. If you feel you
  have this in hand, lets make sure it is public and people know who to go 
  to.
 
  Are there any plans to have an openEHR stand? This could enable a group of
  companies to promote what they are doing?
 
  Evelyn Hovenga and Heather Grain have been working with Heather Leslie
  regarding accrediting training?. have you talked to them? Do we need a 
  group
  coordinating this?
 
  Cheers Sam
 
  Dr Sam Heard
  Chairman, openEHR Foundation
 
  From: pablo pazos
  Sent: ?Thursday?, ?23? ?October? ?2014 ?4?:?57? ?PM
 
  To: For openEHR clinical discussions
  Cc: For openEHR technical discussions, For openEHR implementation
  discussions
 
  Hi Sam,
 
  I think we are coordinating this already :) IMO that's the point of having
  the wiki pages and asking colleagues to add content, proposals and 
  comments.
 
  I think the idea of a key note is great, and I want to collaborate in any
  way I can, but... as you an others may know, I asked several times for
  endorsement and support (not talking about money) from the foundation on 
  the
  training side, to standardize the contents, to have a formal way of
  certification, and spread the standard, but the board went silent. I'm 
  very
  pragmatic and I don't know why this is so difficult, for me this is 
  treated
  in a very political way and should be something technical.
 
  With that being said, for me, talking about training under the foundation
  banner is at least weird

MedInfo 2015 openEHR tutorials

[pablo pazos]

(resending this because it was rejected by the lists, sorry if you received 
this twice)
Hi all, I'm also finalizing the proposal for the clinical database workshop, 
please review it 
here:https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554760If 
anyone wants to modify or add anything, just add a comment on the wiki.The 
deadline is next week, please hurry up if you want to review the 
contents.Thanks!-- Kind regards,Eng. Pablo Pazos Guti?rrezhttp://cabolabs.com
-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

 From: skoba at moss.gr.jp
 Date: Thu, 8 Jan 2015 01:45:04 +0900
 Subject: Re: MedInfo 2015 openEHR tutorials
 To: openehr-implementers at lists.openehr.org
 CC: openehr-technical at lists.openehr.org; openehr-clinical at 
 lists.openehr.org
 
 Hi colleagues,
 
 Can I finalize this developers' workshop proposal?
 https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554784
 
 Today is just before one week to the workshop deadline.
 
 Shinji KOBAYASHI
 
 2014-12-18 20:52 GMT+09:00 Shinji KOBAYASHI skoba at moss.gr.jp:
  Hi colleagues,
 
  I am preparing to submit openEHR developers' workshop in this openEHR wiki 
  page.
  https://openehr.atlassian.net/wiki/pages/viewpage.action?pageId=4554784
  If you got interested in participating this workshop, please add your
  name and brief summary(100-200 words) of your project on this wiki
  until Dec 31 2014. Anyone can join this workshop, if you have working
  on development around openEHR.
  Thank you for your concern about this workshop and contributing on
  wiki. I am looking forward to meeting you in Sao Paolo.
 
  Shinji KOBAYASHI
 
  2014-10-30 17:21 GMT+09:00 Luis Marco luismarco at gmail.com:
  Hi Pablo,
  I will be in Medinfo therefore we can coordinate together the Spanish
  language resources ;-)
  Regards,
  Luis
 
  2014-10-29 17:14 GMT+01:00 pablo pazos pazospablo at hotmail.com:
 
  Hi Sam,
 
  I think right now the tutorial organization is happening in a very organic
  way: people are sharing they proposals so others can collaborate or detect
  possible overlaps.
 
  If we need a group to centralize coordination or communication with
  MedInfo organizers/chairs, I would propose the people interested no giving
  tutorials that is mentioned here:
  http://www.openehr.org/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2C+Brazil
 
 
  On my part, I don't have resources to have an stand (flight + hotel +
  conference fee is not cheap for us), but if I can help in any way, e.g. 
  the
  community can use me as an spanish speaker interlocutor, I'll be more than
  happy to help and add my grain of sand.
 
 
  About training, I'm doing a small survey to see what people think about
  the proposals already discussed on the lists. My goal is to curate that 
  and
  to reach a new level of discussions beyond ideas. I don't have Heather
  Grain's email, I'll gladly send her my little survey (Already sent to
  Heather L and Evelyn).
 
  Cheers,
  Pablo.
 
  --
  Kind regards,
  Eng. Pablo Pazos Guti?rrez
  http://cabolabs.com
  
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150111/c159f3dc/attachment.html

CRUD Restlet

[pablo pazos]

But the recommendations you posted are built over false arguments, like the #1. 
in my list on the previous message.
Also, the date of the post you reference is from ~ 2003 ...

IMO the bad news is you will not be able to use a lot of APIs that follow 
principles and conventions you don't like, like the EHRScape ;)

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

Date: Sun, 18 Jan 2015 20:41:35 +0100
From: bert.verh...@rosa.nl
To: pazospablo at hotmail.com; openehr-technical at lists.openehr.org
Subject: Re: CRUD Restlet


  

  
  
The point for me is separation of
  transport layer and application layer, and each domain has its own
  errorhandling.

  

  I have made my choice. And it seems I am not the only one on the
  world with this choice, which is good news

  

  thanks

  Bert

  

  

  pazospablo at hotmail.com schreef op 18-1-2015 om 19:52:



  
  
The
  recommendations seem a little weak for me.



1. Most REST
  services can not be accessed just by typing the url in the
  browser. What about security tokens? Or header values? Or
  sending PUT, POST, PATCH or DELETE?



2. No
  serious developer will use just the browser and not any other
  tools. This is plain dumb. We use a bunch of tools for dev and
  test, from packet sniffers and REST testers, to javascript
  consoles and log analyzers.



3. REST
  services should be documented, so the developer knows for sure
  what 404 means in each case and has the correct urls for every
  resource :)






Sent from my LG Mobile
  
  
--
  Original message--
From: Bert
  Verhees
Date: Sun,
  Jan 18, 2015 9:46 AM
To: openehr-technical at lists.openehr.org;
Subject:Re:
  CRUD Restlet
For information:



See the recommendations by Ethan Cerami:
Specialties: Cancer genomics, bioinformatics, scientific
computing, software engineering, project management.

https://www.linkedin.com/in/ecerami

http://www.oreilly.com/pub/au/806



Read:


http://archive.oreilly.com/pub/post/restful_error_handling.html#__federated=1



Quoting: 



Conclusion:


  Human Readable Error Messages: Part of the major
appeal of REST based web services is that you can open any
browser, type in the right URL, and see an immediate
response -- no special tools needed. However, HTTP error
codes do not always provide enough information. For example,
if we take option 1 above, and request and invalid book ID,
we get back a 404 Error Code. From the developer
perspective, have we actually typed in the wrong host name,
or an invalid book ID? It's not immediately clear. In Option
3 (DAS), we get back a blank page with no information. To
view the actual error code, you need to run a network
sniffer, or point your browser through a proxy. For all
these reasons, I think Option 4 has a lot to offer. It
significantly lowers the barrier for new developers, and
enables all information related to a web service to be
directly viewable within a web browser.
  Application Specific Errors: Option 1 has the
disadvantage of not being directly viewable within a
browser. It also has the additional disadvantage of mapping
all HTTP error codes to application specific error codes.
HTTP status codes are specific to document retrieval and
posting, and these may not map directly to your application
domain. For example, one of the DAS error codes relates to
invalid genomic coordinates (sequence coordinate is out of
bounds/invalid). What HTTP error code would we map to in
this case? 
  Machine Readable Error Codes: As a third criteria,
error codes should be easily readable by other applications.
For example, the XooMLe application returns back only human
readable error messages, e.g. Invalid Google API key
supplied. An application parsing a XooMLe response would
have to search for this specific error message, and this can
be notoriously brittle -- for example, the XooMLe server
might simply change the message to Invalid Key Supplied.
Error codes, such as those provided by DAS are important for
programmatic control, and easy creation of exceptions. For
example, if XooMLe returned a 1001 error code

Question on Stack Overflow re openEHR Persistence using RoR Active Record

[pablo pazos]

This is one of my students :D doing our Clinical Database Design with openEHR 
course. He is trying to use Rails to solve an assigment, but I'm not a Rails 
expert, so anyone with Rails knowledge might help him better than me.

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

 From: ian at freshehr.com
 Date: Mon, 19 Jan 2015 23:17:01 +
 Subject: Re: Question on Stack Overflow re openEHR Persistence using RoR  
 Active Record
 To: openehr-technical at lists.openehr.org
 
 Rails Multi Table Inheritance, Polymorphic association or Single Table
 Inheritance?
 
 I'm trying to implement the OpenEHR reference model in Rails
 (ActiveRecord), but I'm finding some problems, since it works with a
 lot of different of different classess, ...
 
 http://stackoverflow.com/q/27909328/3973688?sem=2
 
 Anyone want to help?
 
 Ian
 Dr Ian McNicoll
 mobile +44 (0)775 209 7859
 office +44 (0)1536 414994
 skype: ianmcnicoll
 email: ian at freshehr.com
 twitter: @ianmcnicoll
 
 Director, freshEHR Clinical Informatics
 Director, openEHR Foundation
 Director, HANDIHealth CIC
 Hon. Senior Research Associate, CHIME, UCL
 
 ___
 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/20150119/e5aff641/attachment.html

C-CDA was created because they do not know openEHR? :)

[pablo pazos]

Just for the sake of discussion, 

See slides 22 and 23:
http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertification.pdf

As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple 
approaches for documenting template requirements began to diverge threatening 
interoperability?
IG = Implementation Guide
So my wild guess is they created a new artifact with the same problems the 
current artifacts have, like the need for an IG, instead of doing a little 
research and find a better solution like using archetypes to model and 
consolidate CDA templates.

Does anyone know more about CCDA? Do you think this is a good area of work for 
openEHR in the US? I mean, maybe we (as a community) can propose an 
openEHR-based solution or make some kind of statement, for documental 
consolidation than having another implementation guide + CDA templates.
What do you think?

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com   
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/2d54f561/attachment.html

C-CDA was created because they do not know openEHR? :)

[pablo pazos]

Great input, thanks!

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

Date: Tue, 20 Jan 2015 10:42:54 +0800
From: edwin_ue...@163.com
To: openehr-technical at lists.openehr.org
Subject: Re:C-CDA was created because they do not know openEHR? :)

Dear sir,
let me share a litttle thought of mine about this CCDA thing
dating back to 2000, CDA is created and used in some places in USA and in 
2005 it is evoved to Release 2, in that time ,there is not only one CDA for the 
clinical document representation in USA,for some continuity of care and 
specially for patient transfer between different facilities there is a standard 
named CCR, after some kinds of fighting,they all agreed to use CDA as the basic 
format or model to solve the continuity of care problem ,which became the most 
widely used across the whole world CCD(Continuity of Care Document) in 2007,in 
this CCD they defined different kinds of templates for vital signs and chief 
complaint and so on.after then IHE,HITSP and HL7 they create  a bunch of other 
IG for different use cases, for example public health section .these all 
existing IGs contain a number of templates(section level and entry level ) 
inherit the constraints defined in the original CCD standards and inconsistency 
between these templates bring them a new level interoperability problem.in 
order to solve this mess they came to the idea to create a unified template 
library based on these efforts these SDO and agency have  done.
at last I want to say  maybe CDA is not that widely used across the 
world,openEHR is definitely less.
kind regards



--
???15901958021

At 2015-01-20 10:19:24, pablo pazos pazospablo at hotmail.com wrote:
 


Just for the sake of discussion, 

See slides 22 and 23:
http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertification.pdf

As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple 
approaches for documenting template requirements began to diverge threatening 
interoperability?
IG = Implementation Guide
So my wild guess is they created a new artifact with the same problems the 
current artifacts have, like the need for an IG, instead of doing a little 
research and find a better solution like using archetypes to model and 
consolidate CDA templates.

Does anyone know more about CCDA? Do you think this is a good area of work for 
openEHR in the US? I mean, maybe we (as a community) can propose an 
openEHR-based solution or make some kind of statement, for documental 
consolidation than having another implementation guide + CDA templates.
What do you think?

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com   



___
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/20150120/738be8a0/attachment.html

CRUD Restlet

[pablo pazos]

Hi Heath, I follow a similar approach on EHRServer with some particularities: 
queries are created using a UI, then stored, and then executed from clients 
using the UID of the query (instead of the name). There is a REST endpoint that 
allow clients to list all the queries available on the server, then execute one.
In the near future we will add some authorization filters so the query list 
will return just the queries each specific client can use. Also 
importing/exporting queries will be in place by UI and by a REST endpoint.
-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
CC: openehr-technical at lists.openehr.org
Subject: Re: CRUD Restlet
Date: Tue, 20 Jan 2015 22:30:47 +






The approach I took with my FHIR like API was to have a named query with know 
parameters and result columns. This could be registered internally using AQL or 
hard coded. This all comes from FHIR principles as they allow registering 
queries and then executing
 them.



Regards



Heath



On 20 Jan 2015, at 7:39 am, Thomas Beale thomas.beale at 
oceaninformatics.com wrote:






On 19/01/2015 21:01, Diego Bosc? wrote:



Sad to see that go away, I liked the idea of reusing well known formats for 
everything.


Regarding REST, I assume that nothing stops you to provide a method called 
query with the actual AQL query as a parameter :D





sure - but that forces the app programmer to develop AQL queries. Now, serious 
programmers and system builders have to do this, but it's not unreasonable to 
minimise it, especially for common cases, and to help devs who may not be PhDs 
in openEHR, AQL, archetypes
 etc. So where can we help them? Well the FHIR approach is trying to hit that 
kind of sweet spot. The ideal version of FHIR or a FHIR-like approach, that we 
can work on in openEHR is to be able to generate directly from the archetype 
model-base FHIR profiles
 (and probably even some resources). 



- thomas






2015-01-19 21:58 GMT+01:00 Thomas Beale 
thomas.beale at oceaninformatics.com:





I would agree with Isabel.



Not everything is a resource, or should be seen as a resource. If you just want 
to pull back a lump of data, that could be a 'resource', and for that a REST 
service based on FHIR or some other API will make sense. Resource-oriented 
stateless services are suited
 to some kinds of applications, mostly readers in my view.



A service for talking directly to an EHR data store (i.e. a CDR) could be 
designed as a REST service in theory, but it's not that well matched to the 
kind of service interface of pattern of calls that will be made (especially if 
distributed queries and commits
 are to be supported).



The interesting question is: what style of service should be used for e-health 
business entities, like active care plans, managed medication lists, and order 
management, which all need much more complex APIs than just 'get'? FHIR is not 
designed for this kind
 of thing, and it's questionable whether REST is either. The APIs in these 
cases need to be carefully designed, and could easily be stateful / 
session-oriented - especially if they manage a shared resource that multiple 
agents may try to update simultaneously.
 In any case, I don't see statefulness or not as the decider on what kind of 
protocol you want; structure is a bigger decider.



I think it's easy to fall into the trap of thinking a single latest / 
fashionable protocol is good for all layers of a complex architecture. That's 
very unlikely to be true. I see no problem with an complete solution having 
REST, SOAP, binary RPC and other
 kinds of interfaces.



- thomas














___

openEHR-technical mailing list

openEHR-technical at lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org




___
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/20150120/14e410aa/attachment.html

RE: EHRServer is on the cloud

[pablo pazos]

Hi everyone!

Small update on EHRServer status:

1. We are very close to the v0.2 milestone, that implies a huge improvement on 
testing and improvements on core functionality. 
https://github.com/ppazos/cabolabs-ehrserver/milestones 

2. The v0.2 guide is here: http://cabolabs.com/docs/en/EHRServer_v0.2.pdf

Please let me know if you have questions, comments of recommendations. I 
already saw some of you added issues on the GitHub repo, thanks for that! And 
please continue to help me: https://github.com/ppazos/cabolabs-ehrserver/issues

Remember you can test the current dev branch here: 
http://cabolabs-ehrserver.rhcloud.com/ehr-0.1/


Thanks again,
Pablo.



-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: pazospa...@hotmail.com
To: k.ata...@auckland.ac.nz; openehr-clini...@lists.openehr.org
Subject: Re: EHRServer is on the cloud
Date: Mon, 1 Jun 2015 19:35:50 +







Thanks Koray, you are very welcome!
BTW, yesterday I've deployed an initial EHR directory management, that can 
associate versioned compositions to folders. Just need to polish the ui a 
little.
Also I'm working on updating the EHRServer guide, will be available soon.
Sent from my LG Mobile


-- Original message--From: Koray AtalagDate: Mon, Jun 1, 2015 08:07To: 
For openEHR clinical discussions;Subject:RE: EHRServer is on the cloudWell done 
Pablo – great perseverance and hard work! Can’t wait to try it for myself… 
Cheers, -koray From: openEHR-clinical 
[mailto:openehr-clinical-boun...@lists.openehr.org]On Behalf Of 
pazospa...@hotmail.com
Sent: Monday, 1 June 2015 3:44 a.m.
To: Sam Heard; openehr-clini...@lists.openehr.org
Subject: Re: EHRServer is on the cloud Thanks Sam, that would be awesome! I 
dont have a lot of OPTs to test, neither realistic data for those. It would be 
great if you can help me in those areas. My idea is to build some OPTs that 
represent a very simple clinical scenario, like a GP visit. I have starter with 
a very basic Encouter OPT. I can create a aimple EMR to input data for those 
OPTs and commit to the EHRServer, then create queries over the integrated data 
in the EHR. What do you think? Kind regarda,Pablo. Sent from my LG Mobile-- 
Original message--From: Date: Sun, May 31, 2015 08:18To: For openEHR 
clinical discussions;Subject:Re: EHRServer is on the cloudHi Pablo This is a 
welcome addition to the openEHR community effort. You have been a great 
proponent of this approach and I can see that you have made a lot of progress 
towards realising an open source service. I am sure this will capture interest 
from a lot of technical people.  I am inclined to join your effort with input 
from the clinical perspective and I hope you will keep me informed of any 
developments or issues you would value clinical input. Cheers, Sam From: pablo 
pazos
Sent: ‎Friday‎, ‎29‎ ‎May‎ ‎2015 ‎9‎:‎16‎ ‎AM
To: For openEHR technical discussions,For openEHR implementation 
discussions,For openEHR clinical discussions Dear friends, I'm happy to share 
with you that our openEHR EHRServer is on the cloud: 
http://cabolabs-ehrserver.rhcloud.com/ehr-0.1/ This is a pre-beta version, with 
no security. Anyone can play with it. Some background info: EHRServer is an 
open source, service oriented, openEHR data repository, with archetype-based 
querying capabilities. It can store any kind of openEHR data without the need 
of changing the source code or the database schema. About the technologies, 
EHRServer is built over Grails Framework, using Groovy and Java programming 
languages. The instance on the cloud is using a MySQL database.  If you want to 
send some data and try to query it, consider these steps: - upload the OPT 
first, so the data you commit later is indexed and available for querying- OPTs 
should be compliant with this XSD: 
https://github.com/ppazos/cabolabs-ehrserver/blob/master/xsd/OperationalTemplate.xsd-
 some OPTs are already loaded: 
https://github.com/ppazos/cabolabs-ehrserver/tree/master/opts- use the commit 
service, see more services: https://github.com/ppazos/cabolabs-ehrserver- 
committed data is sent in XML format following this XSD: 
https://github.com/ppazos/cabolabs-ehrserver/blob/master/xsd/Version.xsd- 
examples of the XML format for the commit service: 
https://github.com/ppazos/cabolabs-emrapp/tree/master/committed If you need 
examples of apps that commit data to the server, please check: 
https://github.com/ppazos/EHRCommitter (small testing 
tool)https://github.com/ppazos/cabolabs-emrapp (very basic EMR) And with this 
app you can execute queries: https://github.com/ppazos/EHRClientPHP (testing 
tool in PHP)  If you want to collaborate or if you face any issues: 
https://github.com/ppazos/cabolabs-ehrserver/issues If you have any questions, 
feel free to contact me.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com
___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http

EHRServer is on the cloud

[pablo pazos]

Dear friends,
I'm happy to share with you that our openEHR EHRServer is on the cloud: 
http://cabolabs-ehrserver.rhcloud.com/ehr-0.1/
This is a pre-beta version, with no security. Anyone can play with it.
Some background info:
EHRServer is an open source, service oriented, openEHR data repository, with 
archetype-based querying capabilities. It can store any kind of openEHR data 
without the need of changing the source code or the database schema. About the 
technologies, EHRServer is built over Grails Framework, using Groovy and Java 
programming languages. The instance on the cloud is using a MySQL database.

If you want to send some data and try to query it, consider these steps:
- upload the OPT first, so the data you commit later is indexed and available 
for querying- OPTs should be compliant with this XSD: 
https://github.com/ppazos/cabolabs-ehrserver/blob/master/xsd/OperationalTemplate.xsd-
 some OPTs are already loaded: 
https://github.com/ppazos/cabolabs-ehrserver/tree/master/opts- use the commit 
service, see more services: https://github.com/ppazos/cabolabs-ehrserver- 
committed data is sent in XML format following this XSD: 
https://github.com/ppazos/cabolabs-ehrserver/blob/master/xsd/Version.xsd- 
examples of the XML format for the commit service: 
https://github.com/ppazos/cabolabs-emrapp/tree/master/committed
If you need examples of apps that commit data to the server, please check:
https://github.com/ppazos/EHRCommitter
 (small testing tool)https://github.com/ppazos/cabolabs-emrapp (very basic EMR)
And with this app you can execute queries:
https://github.com/ppazos/EHRClientPHP (testing tool in PHP)

If you want to collaborate or if you face any issues: 
https://github.com/ppazos/cabolabs-ehrserver/issues
If you have any questions, feel free to contact me.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: openEHR @ StackExchange

[pablo pazos]

@all please try to upvote answers by openEHR community members on 
openEHR/EHR/EMR/... related questions, that's a good way to increase reputation 
(just received two upvotes, so I guess someone here already started that, also 
I upvoted Koray and Erik's answers).

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

 From: k.ata...@auckland.ac.nz
 To: openehr-technical@lists.openehr.org
 Subject: RE: openEHR @ StackExchange
 Date: Tue, 26 May 2015 04:08:30 +
 
 One needs at least 1500 reputations to introduce a new tag (obviously openEHR 
 doesn't exist yet).
 
 
 Cheers,
 
 -koray
 
 -Original Message-
 From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
 On Behalf Of Thomas Beale
 Sent: Monday, 25 May 2015 11:41 p.m.
 To: openehr-technical@lists.openehr.org; For openEHR clinical discussions
 Subject: Re: openEHR @ StackExchange
 
 On 25/05/2015 12:16, Diego Boscá wrote:
  I would assume it can be both: a question could be just about specs 
  (just the openEHR tag) or about any specific implementation (e.g.
  openEHR and java)
 
 
 yep - that's how I think it would work.
 
 - thomas
 
 ___
 openEHR-technical mailing list
 openEHR-technical@lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
 ___
 openEHR-technical mailing list
 openEHR-technical@lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: EHRServer is on the cloud

[pablo pazos]

Thanks Bert,
I will be deploying new features for the next couple of weeks, stay tunned!Then 
I'll try to improve the docs and provide some sample client code.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Date: Fri, 29 May 2015 09:39:53 +0200
From: bert.verh...@rosa.nl
To: openehr-technical@lists.openehr.org
Subject: Re: EHRServer is on the cloud


  

  
  
Very nice, Pablo, thanks for sharing

  

  Bert

  

  On 29-05-15 01:46, pablo pazos wrote:



  
  Dear friends,



I'm happy to share with you that our openEHR EHRServer is
  on the cloud: http://cabolabs-ehrserver.rhcloud.com/ehr-0.1/



This is a pre-beta version, with no security. Anyone can
  play with it.



Some background info:



EHRServer is an open source, service oriented, openEHR data
  repository, with archetype-based querying capabilities. It can
  store any kind of openEHR data without the need of changing
  the source code or the database schema. About the
  technologies, EHRServer is built over Grails Framework, using
  Groovy and Java programming languages. The instance on the
  cloud is using a MySQL database.






If you want to send some data and try to query it, consider
  these steps:



- upload the OPT first, so the data you commit later is
  indexed and available for querying
- OPTs should be compliant with this XSD: 
https://github.com/ppazos/cabolabs-ehrserver/blob/master/xsd/OperationalTemplate.xsd
- some OPTs are already loaded: 
https://github.com/ppazos/cabolabs-ehrserver/tree/master/opts
- use the commit service, see more services: 
https://github.com/ppazos/cabolabs-ehrserver
- committed data is sent in XML format following this XSD: 
https://github.com/ppazos/cabolabs-ehrserver/blob/master/xsd/Version.xsd
- examples of the XML format for the commit service: 
https://github.com/ppazos/cabolabs-emrapp/tree/master/committed



If you need examples of apps that commit data to the
  server, please check:



https://github.com/ppazos/EHRCommitter
   (small testing tool)
https://github.com/ppazos/cabolabs-emrapp (very
  basic EMR)



And with this app you can execute queries:



https://github.com/ppazos/EHRClientPHP (testing
  tool in PHP)






If you want to collaborate or if you face any issues: 
https://github.com/ppazos/cabolabs-ehrserver/issues



If you have any questions, feel free to contact me.

  

  -- 

  Kind regards,

  Eng. Pablo Pazos Gutiérrez

  http://cabolabs.com
  
  

  
  

  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: openEHR archetypes and views - clarification

[pablo pazos]

Hi Liron,
I think the MindMap used in the CKM (http://ckm.openehr.org/) is a flash 
rendered of the FreeMind mindmap format .mm. I don't know of any publicly 
available tool to render the ADL to mm directly. You might need to do the 
transformation yourself from ADL to XML (mm) and use the flash rendered. AFAIK, 
modelling tools don't provide the visual mindmap.
User interface has nothing to do with archetypes, so you will not find any 
information about how to render information on a screen in the openEHR specs. I 
did a lot of work around openEHR and UIs, you might find these papers useful:
https://www.academia.edu/9882392/Generaci%C3%B3n_autom%C3%A1tica_de_interfaces_de_usuario_para_sistemas_de_informaci%C3%B3n_cl%C3%ADnicos_basados_en_una_metodolog%C3%ADa_multi-nivelhttps://www.academia.edu/9882453/EHRGen_Generador_de_Sistemas_Normalizados_de_Historia_Cl%C3%ADnica_Electr%C3%B3nica_Basados_en_openEHR

The openEHR information model allows to represent any kind of information, and 
you can chose the best way of displaying it, like a table, a chart, etc. For 
example, on our EHRServer (https://www.youtube.com/watch?v=D-hs-Ofb8SY) when 
you query for numeric data i JSON format, it will display a chart. I have a 
version in the cloud if you want to try it.
Consider that openEHR templates are not templates for UI, those doesn't tell 
you how to display the data, just tell you which data is part of a clinical 
document. For example, on the UI you might need to display data from many 
documents, so you might need to define your UI Template and apply it to the 
result of a query to the EHR.
About data, you will need to produce your own. If you have an archetype (ADL) 
or operational template (OPT) it is easy to create a process that goes through 
it and generates random data with the correct type (text, date, quantity, etc.).
Hope that helps!


-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: liron_ka...@hotmail.com
To: openehr-technical@lists.openehr.org
Subject: openEHR archetypes and views - clarification
Date: Wed, 20 May 2015 13:20:24 +
























Hello,

 
Question clarification:
 

 

1)   
Most
of the system screen are about patient overview, meaning presentation of various
data, rather than forms. Though I have identified the archetype to used, I am 
puzzled
how can I built a template which is non-form (or in another words how can I
view the template in non-form format ? )


2)   
In
continuation which question 1, is there any way to run a template which will
produce a demo data ?


3)   
Is
there any way to have a mind map via one of the modeling tools ?(such as ADL
,AE ? )

 

Thanks
in advance, 

 

Liron.







From: liron_ka...@hotmail.com
To: openehr-technical@lists.openehr.org
Subject: openEHR archetypes and views
Date: Wed, 20 May 2015 13:01:37 +




Hello,

 

I am in the learning process of openEHR as part of my thesis work at Orebro 
university, Sweden, and I would like to ask quite simple questions which I came 
across but , couldn’t find any document which deal in the subject.

 

1)Is there any way to get a  mind map view for the archetypes/ templates 
via one of the modeling tools ? (for  ex the ADL)

2)My goal is to model a system via archetype. For ex: a screen which 
present a patient overview. The screen represent data and does not contain any 
form. I couldn’t find any document which explain how to deign/represent a 
non-form template (scree). Is there a way to do so?

 

Thanks in advance,

Liron   
  

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Template Designer - remove slot

[pablo pazos]

Hi Thomas, trying to create an issue I got this error
Assignee: The default assignee does NOT have ASSIGNABLE permission OR 
Unassigned issues are turned off.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Date: Sat, 16 May 2015 20:39:16 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical@lists.openehr.org
Subject: Re: Template Designer - remove slot


  

  
  
On 04/05/2015 16:11, pablo pazos wrote:



  
  
  Awesome, I'll add this to the TD JIRA. Do anyone
remember where that JIRA is?



-- 



Here is a new
  tracker for the TD - please add it here.



- thomas



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Term set for DV_PARSABLE.formalism

[pablo pazos]

I think we can put the formalisms we know in the terminology, but being 
flexible to allow local formalisms, like using local for the terminology_id. 
If we don't do that, we'll need to maintain the terminology for every new 
formalism.
Not sure about having two fields, it seems the role of both is the same. We can 
do that with parameters or suffixes on MIME types (the structure allows that): 
https://en.wikipedia.org/wiki/Internet_media_type
With CODE_PHRASE we can cover both cases, defined and non-defined MIME types.

If the MIME type is String, we lose control over the values, I'm considering 
trying to process something I receive and not understanding that String. With 
terminology = local, I know that I may not have the code (if local is another 
system), but for a MIME type from IANA I will have it. Also this allow us to 
define our own openEHR types without the need of registering those at IANA, 
like ADL or OPT (e.g. text/opt+xml).


-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: Term set for DV_PARSABLE.formalism
To: openehr-technical@lists.openehr.org
From: thomas.be...@oceaninformatics.com
Date: Tue, 28 Jul 2015 19:38:40 +0100


  

  
  
On 28/07/2015 18:49, pablo pazos wrote:



  
  
  If that's the case, we lose the coding system /
terminology of the mime types that are defined.



It would be better to make DV_PARSABLE.formalism of type
  CODE_PHRASE instead of String and use local for the
  terminology_id of those formalisms that doesn't have a mime
  type.



  



well actually we could do that and put all those other formalisms
into the openEHR terminology.



The original idea was to allow (encourage) MIME types as strings,
and then outside of MIME, any other formats just as their own short
string, e.g. 'mp5' (imagine it exists), or 'adl'. 



There are a lot of formats that are essentially text/plain, but the
format is actually parseable, e.g. glif3, most programming languages
and so on. So 'text/plain' isn't that useful a thing to know.



I wonder if we have to give in and have two fields, one that is a
MIME type field (the current one) and a second field that has a term
defining the semantic format, mostly applicable when the MIME type
field is text/plain, text/xml and other text types.



- thomas



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Term set for DV_PARSABLE.formalism

[pablo pazos]

If that's the case, we lose the coding system / terminology of the mime types 
that are defined.
It would be better to make DV_PARSABLE.formalism of type CODE_PHRASE instead of 
String and use local for the terminology_id of those formalisms that doesn't 
have a mime type.
thoughtS?

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Date: Mon, 27 Jul 2015 08:23:49 +0200
Subject: Re: Term set for DV_PARSABLE.formalism
From: yamp...@gmail.com
To: openehr-technical@lists.openehr.org
CC: openehr-implement...@lists.openehr.org

Probably was left this way to deal with the ones that don't have an official 
mime, like adl
El 27/7/2015 7:11, pablo pazos pazospa...@hotmail.com escribió:



Reading the specs I realize that there isn't a term set for 
DV_PARSABLE.formalism and it is a free text attribute.
Since stuff like XML, JSON, CSV, etc. are in fact modeled by DV_PARSABLE, and 
those have a MIME type associated (text/xml, application/json, text/csv, ...), 
shouldn't we define a term set for that attribute like we have for 
DV_MULTIMEDIA.media_type? (of course this attribute is CODE_PHRASE and not 
String like formalism).

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   

___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

2 constraint bindings in ADL - 1 referenceSetUri in OPT

[pablo pazos]

Hi,
I have created a testing archetype with two constraint bindings:
... ELEMENT[at0004] occurrences matches {0..1} matches {-- Terminology 
ref 
 value matches {
 DV_CODED_TEXT matches {
 defining_code matches 
{[ac0001]}-- ref
  } 
  }...
constraint_definitions =   [es] =   items = 
   [ac0001] =   
text = ref  description = ref   

constraint_bindings =  [SNOMED-CT] =items = 
   [ac0001] = 
terminology:SNOMED-CT?subset=motivo_de_consulta  
  [AOD2000] =  items = 
   [ac0001] = terminology:AOD2000?subset=sdfgsd 
 

If I use this archetype in the Template Designer and export the OPT, I get just 
one URI:
children xsi:type=C_COMPLEX_OBJECT
rm_type_nameDV_CODED_TEXT/rm_type_name
occurrences  ...
/occurrencesnode_id /   
 attributes xsi:type=C_SINGLE_ATTRIBUTE  
rm_attribute_namedefining_code/rm_attribute_name
  existence...  
/existence  children 
xsi:type=C_CODE_REFERENCE
rm_type_nameCODE_PHRASE/rm_type_name
occurrences  ...  
  /occurrencesnode_id / 
   
referenceSetUriterminology:SNOMED-CT?subset=motivo_de_consulta/referenceSetUri
  /children
/attributes  /children

Is this a TD bug? I'm using TD 2.6.1214Beta.
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Term set for DV_PARSABLE.formalism

[pablo pazos]

Reading the specs I realize that there isn't a term set for 
DV_PARSABLE.formalism and it is a free text attribute.
Since stuff like XML, JSON, CSV, etc. are in fact modeled by DV_PARSABLE, and 
those have a MIME type associated (text/xml, application/json, text/csv, ...), 
shouldn't we define a term set for that attribute like we have for 
DV_MULTIMEDIA.media_type? (of course this attribute is CODE_PHRASE and not 
String like formalism).

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Template Designer: Error exporting OPT that contains the ACTION.procedure archetype

[pablo pazos]

Hi, I need to create an OPT that contains the ACTION.procedure archetype, but 
when exporting the OPT I get this error:
Failed to export operational template. openEHR-EHR-ACTION.procedure.v1.adlERROR 
- line 1: parse error [last token = V_IDENTIFIER]line 1: In 'archetype' clause; 
expecting archetype id (model_issuer-ref_model_class.concept.version) [last 
token = V_IDENTIFIER] (Parse failed) (ADL_INTERFACE.parse_archetype)

When I include the archetype in my COMPOSITION template, I can see all the 
nodes there, so I don't know what's wrong with parsing the ADL, because is 
parsed to show the tree inside the template.

One thing: the ADL exported from the CKM has an uid in the archetype clause, it 
seems that is giving the TD a hard time:
archetype (adl_version=1.4; uid=82e79f18-76b9-4b5c-a930-1115eecbc4b7)   
openEHR-EHR-ACTION.procedure.v1


-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Template Designer problem when selecting Value Set on DV_TEXT node

[pablo pazos]

Hi, 
I have a text node and  was testing different ways of constraining that node 
from the Template Designer.
I've found that if I select the node, then on the node properties panel go to: 
Value Set  On the window, under the Terminology Service tab, select Snomed 
and check the Select full terminology, then save the OET. That constraint 
doesn't appear in the OET file.
If I go to the Generic Valueset tab on the same window, and input a 
Terminology Name and a Subset name, then save the OET, that constraint appears 
in the OET. Also, the node type changes from DV_TEXT to DV_CODED_TEXT, 
something I reported in other issue that I couldn't set the constraint on 
DV_TEXT to allow only DV_CODED_TEXT instances. So setting the Generic Valueset 
seems to be an implicit way of declaring that node as DV_CODED_TEXT from the TD.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Template Designer: Error exporting OPT that contains the ACTION.procedure archetype

[pablo pazos]

Hi Ian, my TD is 2.6.1214Beta.
AFAIK there isn't a newer release publicly available.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: i...@freshehr.com
Date: Fri, 24 Jul 2015 18:07:14 +0100
Subject: Re: Template Designer: Error exporting OPT that contains the   
ACTION.procedure archetype
To: openehr-technical@lists.openehr.org

Hi Pablo,
What is the version of TD that you are using? There is a new beta in 
development that may fix this issue.
Ian
On Thu, 23 Jul 2015 at 07:09, pablo pazos pazospa...@hotmail.com wrote:



Hi, I need to create an OPT that contains the ACTION.procedure archetype, but 
when exporting the OPT I get this error:
Failed to export operational template. openEHR-EHR-ACTION.procedure.v1.adlERROR 
- line 1: parse error [last token = V_IDENTIFIER]line 1: In 'archetype' clause; 
expecting archetype id (model_issuer-ref_model_class.concept.version) [last 
token = V_IDENTIFIER] (Parse failed) (ADL_INTERFACE.parse_archetype)

When I include the archetype in my COMPOSITION template, I can see all the 
nodes there, so I don't know what's wrong with parsing the ADL, because is 
parsed to show the tree inside the template.

One thing: the ADL exported from the CKM has an uid in the archetype clause, it 
seems that is giving the TD a hard time:
archetype (adl_version=1.4; uid=82e79f18-76b9-4b5c-a930-1115eecbc4b7)   
openEHR-EHR-ACTION.procedure.v1


-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   
___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

CKM error for translator email

[pablo pazos]

Sometimes the translator email field appears empty after being recorded. 
Today it happened that after recording the email and starting translating some 
fields, the email appeared empty, then I saw that the accreditaion field had 
the email value.
Now, after saving a partial translation, and starting again with the 
translation, the email is empty again, but a weird thing happened: now my email 
is a field name. See 
http://s13.postimg.org/e5mbrpusn/Clinical_Knowledge_Manager.jpg
Also, I detected on one archetype that I translated, my email wasn't there, but 
I carefully add my email to every archetype I translate.
Any ideas of what's wrong?Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Maven Archetype – About

[pablo pazos]

I would use "...enable developers quickly in a way consistent with best 
practices employed by your [EHR] project ..." :D

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: k.ata...@auckland.ac.nz
To: openehr-technical@lists.openehr.org
Subject: Maven Archetype – About
Date: Thu, 12 Nov 2015 23:19:33 +









http://maven.apache.org/archetype/


Interesting definition (though not related to our models)

Cheers,

-koray





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: VERSION.lifecycle_state options

[pablo pazos]

There is a nice thing in HL7 (yes, that is possible! :), when they define 
state or categorization data, associated with an HL7 terminology set (values 
should be chosen from a given set, can't be defined by the implementer), they 
also offer a modifier. In the modifier the implementer can set it's own term 
set / codes.
If you have more than one status matching one code on the standard code set, 
use modifier to establish the difference. Is a nice way of extension and allows 
a great deal of flexibility.
What do you think about having a lifecyce_state_modifier attribute for 
VERSION? (just thinking out loud)

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: openehr-technical@lists.openehr.org
CC: openehr-technical@lists.openehr.org
Subject: Re: VERSION.lifecycle_state options
Date: Thu, 9 Jul 2015 22:53:10 +






EHR Access control setting might be the way to apply these kin do policies 
also, but I do understand you want something universally understood, not just 
local policy. I am hoping we might be able to get to something like this when 
we start looking at EHR
 access settings.



Regards



Heath



On 10 Jul 2015, at 6:23 am, Ian McNicoll i...@freshehr.com wrote:






Hi Sebastian,



You could control this in a shared environment by using a coded text item in 
Attestation/reason.



I think this might work better than a 'standard' gneric lifecycle state since 
it allows you to very specifically identify the exact policy/legislation 
involved.



Ian













Dr Ian McNicoll

mobile +44 (0)775 209 7859

office +44 (0)1536 414994

skype: ianmcnicoll

email: i...@freshehr.com

twitter: @ianmcnicoll




Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.

Director, HANDIHealth CIC

Hon. Senior Research Associate, CHIME, UCL













On 9 July 2015 at 21:36, Sebastian Iancu 
sebast...@code24.nl wrote:



Hi Erik,



I see where are you pointing to - that 'attestations' can indeed be one 
solution to the problem. However I see this more as an application-level 
functionality/feature; it can be (or not) interpreted the same way by a 3rd 
openEHR system that might get that data.
 I feel safer having (also) the options of a 'final-like' state flag of the 
version.




Best regards,

Sebastian







On 7/9/2015 9:32 PM, Ian McNicoll wrote:






Hi Erik,



That's seems a pretty good solution to me.



Ian


On Thu, 9 Jul 2015 at 12:53, Erik Sundvall erik.sundv...@liu.se wrote:



Hi!



Is a new type of VERSION.lifecycle_state
the best to solve the described use-case? Won't the correcting a typo change 
or we forgot a thing use-cases etc still always be there even for things 
written as binding contracts? 




Is it perhaps enough to have the final plan fixed/fixated by applying digital 
signatures on the VERSION using the ATTESTATION
 class, thus marking the contractual agreement with digital signatures so 
that nothing be changed without the system (and/or users) noticing it. 



The application can then, for the type of change-sensitive documents described 
by Sebastian, perform signature checks and show warnings or refuse to update 
info unless the change is signed by the same persons or organisations that 
signed the previously
 signed version.



To me it seems natural that binding contracts and signatures belong together.



Heath's use-case something to indicate a version was moved distinct from 
deleted won't be solved by signatures though, so
https://openehr.atlassian.net/browse/SPECPR-83 is still valid.










Best regards,

Erik Sundvall 
Ph.D. Medical Informatics. Information Architect. Tel:
+46-72-524 54 55 (or 010-1036252 in Sweden)

Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/ 

Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/















On Thu, Jun 11, 2015 at 10:30 AM, Sebastian Iancu 
sebast...@code24.nl wrote:


Hi,



I can rephrase my question: How can I indicate that a version should not be 
changed under any circumstances? How have other openEHR implementations 
handling this issue (if ever occurred)?



The use case I have is in mental-care in NL is that care providers are setting 
up a care plan (which consists of many type of documents, anamnesis, goals, 
planned schedule for evaluations, planned interventions, actions, etc). During 
the initial phase of documenting
 and planning most of these are in draft-mode (they are complete, but perhaps 
need approvals, reviews or some are sometimes just considered as proposals), 
but at some point in time some of them they need to be fixated, any later 
change should be forbidden.
 It is like a contractual relation between care providers and/or patient, it 
requires some sealed papers.



Whats the best way to handle this? I'm not convinced this is a 
modeling/archetype/template issue, I rather think is something

RE: difference and relationship between openEHR and EN13606

[pablo pazos]

Dear Gerard, IMO communication includes the interfaces, I didn't excluded 
them :D

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: difference and relationship between openEHR and EN13606
From: gf...@luna.nl
Date: Wed, 26 Aug 2015 14:03:18 +0200
To: openehr-technical@lists.openehr.org

Dear Pablo,
According to the scope statement: the 13606 is for the creation of the 
EHR-EXtract for communication between IT-systemsandfor the definition of the 
Information Viewpoint in Interfaces with system services.
Gerard

Gerard Freriks+31 620347088gf...@luna.nl


On 26 aug. 2015, at 13:50, pazospa...@hotmail.com wrote:





Hi, 
I would say that the main difference is that 13606 is for data communication 
and openEHR is for EHR architecture, both based on archerypes.
For detailed differences just look at both information models, you will see 
that 13606 IM is much simple.
About the specs, 13606 has 5 chapters, including communication and security, 
and openEHR specs don't have those.
The best way of knowing the differences is just to download the specs of both 
and compare them.
Hope that helps,Cheers,Pablo.
Sent from my LG Mobile


-- Original message--From: 王海生Date: Wed, Aug 26, 2015 06:14To: 
openehr-technical@lists.openehr.org;Subject:difference and relationship between 
openEHR and EN13606dear all ,
how could i  explain to someone difference and relationship between openEHR 
and EN13606 
thx 
--
王海生15901958021


夏日畅销榜大牌美妆只要1元___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Advantage of ISO

[pablo pazos]

Again: you are explicitly ignoring availability and freedom to use arguments, 
the main point here...
This is my last message on this discussion, I'll continue doing something more 
productive :)

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: Advantage of ISO
From: gf...@luna.nl
Date: Fri, 4 Sep 2015 08:19:35 +0200
CC: openehr-technical@lists.openehr.org
To: pazospa...@hotmail.com

I shared with you my definitions and my argument.This provided my context.
In principle: definitions are universal in nature and generally applicable in 
many contexts.

Gerard
On Sep 3, 2015, at 3:33 PM, pazospa...@hotmail.com wrote:





Definitions are context dependant, but that's not the point... you ignored 
the true argument about availavility and constraints/freedom to use.
Sent from my LG Mobile


-- Original message--From: Gerard Freriks (privé)Date: Thu, Sep 3, 2015 
04:07To: For openEHR technical discussions;Subject:Re: Advantage of ISOI think 
that definitions are generally valid.


On Sep 3, 2015, at 8:38 AM, pablo pazos <pazospa...@hotmail.com> wrote:I think 
that definition doesn't apply to a standard / spec. IMO when we talk about 
standards, we focus on the ability to use it and let others use it, and the 
constraints / freedoms in that area, not in who is the owner.-- Kind 
regards,Eng. Pablo Pazos Gutiérrezhttp://cabolabs.com

  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Advantage of ISO

[pablo pazos]

I think that definition doesn't apply to a standard / spec. IMO when we talk 
about standards, we focus on the ability to use it and let others use it, and 
the constraints / freedoms in that area, not in who is the owner.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: gf...@luna.nl
Subject: Re: Advantage of ISO
Date: Thu, 3 Sep 2015 07:29:59 +0200
To: openehr-technical@lists.openehr.org

What do I misunderstand?
The definition of ‘proprietary’ according to GOOGLE  is 
clear.proprietaryprəˈprʌɪət(ə)ri/adjectiveadjective: proprietary1. relating to 
an owner or ownership."the company has a proprietary right to the 
property"behaving as if one owned something or someone."he looked about him 
with a proprietary air"2. (of a product) marketed under and protected by a 
registered trade name."proprietary brands of insecticide"Originlate Middle 
English (as a noun denoting a member of a religious order who held property): 
from late Latin proprietarius ‘proprietor’, from proprietas (see property).
On the openEHR website we all can read about the Legal Status.And that is 
clear, also.OpenEHR specs are owned by the company that is owned by UCL, only.


Gerard
On Sep 3, 2015, at 2:07 AM, Ian McNicoll <i...@freshehr.com> wrote:Hi Bert,
I am certainly conscious of rumours. Some of these are due to general suspicion 
of open source licensing (and we can, I think, do more to alleviate this)  but 
I am afraid some of anxiety is also caused by inaccurate and misleading 
information "openEHR is proprietary",  regularly stated by a small number of 
individuals. I have had to ask for these to be corrected in a number of 
documents e.g. The SemanticHealthNet report where it was agreed by the 
principal authors, including Dipak, to be incorrect.
Since a significant number of companies and national organisations now make use 
of openEHR specifications or artefacts, these statements are being regarded as 
commercially hostile and the Foundation Boards both agree that legal action 
should now be taken where the authors are not prepared to promptly correct this 
inaccuracy.
Leaving that aside. I am not convinced that ISO is a good home for openEHR. The 
specifications, development and revision process in ISO remain completely 
closed and quite at odds withopenEHR principles but I would be interested in 
other's views. 
I do think that some sort of association with a formal standards body would 
help alleviate some of the anxieties you mention (though these are imaginary) 
but I am not sure that ISO would be my first choice as it is currently 
constructed. I will raise the issue of whether to submit AOM2 with the 
Management Board.
I am interested in other people's opinions.
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.orgDirector, freshEHR 
Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 1 September 2015 at 16:48, Bert Verhees <bert.verh...@rosa.nl> wrote:
On 01-09-15 17:16, Bert Verhees wrote:


I have written a text (reply to Erik) in Stackoverflow, describing why it will 
be good for OpenEHR if AOM2.0 will become an ISO-standard in the context of 
ISO13606 renewal.



http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve/
 




I must add, it is not that I suspect anyone of having secret IP on OpenEHR.

I have no reason to suspect this.



But I know people who have such suspicions, and having the AOM-part as an ISO 
standard, surely will fight these rumors.



I think it will help OpenEHR-implementations to have more customers.



Bert



___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Party-actor-folder relationships in hierarchy

[pablo pazos]

Hi Dmitry, OBJECT_ID can point to the uid inherited from LOCATABLE, but as you 
can see in the model 
(http://openehr.org/releases/1.0.2/architecture/rm/common_im.pdf page 13), uid 
is optional. I wouldn't like to have my references rely on an optional 
attribute. I didn't designed the model, but that seems reasonable to me.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

> From: barano...@yandex.ru
> To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org
> Subject: Re: Party-actor-folder relationships in hierarchy
> Date: Fri, 27 Nov 2015 11:11:06 +0300
> 
> > Hi Dmitry,
> >
> > Consider that the folder structure is defined for each EHR, and can vary 
> > vary between ehrs inside the same company.
> > I would use LINK to link the org to the ehr folder struct.
> 
> (ORGANIZATION as LOCATABLE).links[0] points to a folder/versioned folder 
> through URI? 
> 
> Thank you Pablo, good idea. Hard to guarantee referential integrity, but...
> Why is it no class to link two entities using theirs OBJECT_ID? :)
> 
> -- 
> Regards, Dmitry
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: ADL validity rules on CKM

[pablo pazos]

Thanks for the input Sebastian,
Are all of those internal to the CKM?Is there any plan to document them in some 
place to have all the rules together?
Maybe there are a lot of internal rules that we don't know of and would be 
useful to have them documented. (Maybe a task for the clinical models program?)
Thanks!
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: sebastian.ga...@oceaninformatics.com
To: openehr-technical@lists.openehr.org
Subject: RE: ADL validity rules on CKM
Date: Tue, 14 Jun 2016 06:45:42 +









Hi Pablo,
 
ICARM: This is the “softer” form of VCARM – i.e. it is just a piece of 
information that while there is no corresponding attribute in the model, there 
is a functional property that is commonly constrained.
 Typical examples are offset and is_integral. These are frequently constrained. 
There was a big debate a (longer) while about whether this is correct/good 
practice or not and I don’t think this has been 100% resolved. For CKM – as 
well as the
 Java Archetype Validator - we decided to inform the user, but not report this 
as a VCARM.
 
VUI: This is the error type to report that a unit in a DV_QUANTITY are not 
valid UCUM units as required by the specs.

I believe that you are right that there is no explicit error type named for 
this in the specs…so while this directly validates the specs, the naming VUI 
(Validation Unit Invalid) is arbitrary at
 present. 
 
WLIC: This is just an internal CKM warning to indicate that the licence for the 
archetype as specified in the ADL differs from the default licence configured 
in CKM.
 
Hope this helps, regards
Sebastian
 



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of pablo pazos

Sent: Dienstag, 14. Juni 2016 05:44

To: openeh technical <openehr-technical@lists.openehr.org>

Subject: ADL validity rules on CKM


 

Hi all,

 


I'm making a small summary of all the ADL validity rules, taking the ADL 1.4  
(1.0.2) spec as my source: 
http://openehr.org/releases/1.0.2/architecture/am/adl.pdf


 


On the CKM I opened the Audiogram Result archetype that has some validity 
problems and the rules are: ICARM,
 VUI and WLIC.


 


The problem is I can't find where those rules are defined. Are those only 
defined in the CKM or is there an spec of those (maybe a newer one)?


 


Thanks!



-- 

Kind regards,

Eng. Pablo Pazos Gutiérrez

http://cabolabs.com







___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: ADL validity rules on CKM

[pablo pazos]

Hi Thomas,
I think it would be very useful to have a centralized list of validity rules 
with a reference to the source (specs, CKM, other specific tool, good practice, 
local rule, etc.).
As a developer, that would help me to use those rules in software.
And as a clinical modeler I can check those rules while designing an archetype 
or a template (manually or using a tool).
The spec rules should be on specs (doh!) but I think we might need something 
more dynamic that we can use to add / maintain rules from all the current 
sources, like a github repo for rules (can be a page on the openEHR wiki o the 
wiki on a github repo).

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: ADL validity rules on CKM
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Wed, 15 Jun 2016 12:03:13 +0100


  

  
  
Hi Pablo,

only a few rules were specified in ADL/AOM 1.4 - you can see them
  in the ADL1.4 spec - I think you will find the newer
HTML version easier to use. They were not collected in an
  easy to read list, but I think we could do this easily enough by
  constructing an index of the relevant paragraph type, and
  inserting that into the document. I'll see what is possible in
  Asciidoctor.



In ADL2, it is the AOM2
spec that provides the validity rule definitions.



I'm not sure what the total set Sebastian uses is, but I suspect
  it includes some of the AOM2 rules, i.e. those that would have the
  same meaning for ADL1.4 archetypes.

We should improve how these rules are represented in the specs
  potentially, and a minor update to the ADL1.4 spec could be used
  to update the effective rule set for ADL 1.4

- thomas





On 14/06/2016 07:54, pablo pazos wrote:



  
  Thanks for the input Sebastian,




  Are all of those internal to the CKM?
  Is there any plan to document them in some place to have
all the rules together?
  

  
  Maybe there are a lot of internal rules that we don't
know of and would be useful to have them documented. (Maybe
a task for the clinical models program?)
  

  

  



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

ADL Workbench exceptions when opening the audiogram archetype

[pablo pazos]

ess_underlying_toolkit_event_queue @6<031EE884>   
  Routine failure.  
Fail---EV_APPLICATION_IMP
  process_event_queue @2  <031EE884>  (From 
EV_APPLICATION_I)   Routine failure.
  
Fail---EV_APPLICATION_HANDLER
process_application_event_queue @1<0322048C>
 Routine failure.  
Fail---EV_APPLICATION_HANDLER
launch @4  <0322048C>   
  Routine failure.  
Fail---GUI_APP_ROOT
internal_launch_application @3<03211E64>  (From EV_APPLICATION) 
 Routine failure.  
Fail---GUI_APP_ROOT
launch @2   <03211E64>  
(From EV_APPLICATION)  Routine failure.  
Fail---GUI_APP_ROOT
make_and_launch @8  <03211E64>  
   Routine failure.  
Fail---GUI_APP_ROOT
root's creation <03211E64>  
   Routine failure.  
Exit---
I will try another version of the ADLWB.
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: ADL Workbench exceptions when opening the audiogram archetype

[pablo pazos]

<031A20CC>  (From 
EV_APPLICATION_I)   Routine failure.
  
Fail---EV_APPLICATION_HANDLER
process_application_event_queue @1<031E06D0>
 Routine failure.  
Fail---EV_APPLICATION_HANDLER
launch @4  <031E06D0>   
  Routine failure.  
Fail---GUI_APP_ROOT
internal_launch_application @3<031B96AC>  (From EV_APPLICATION) 
 Routine failure.  
Fail---GUI_APP_ROOT
launch @2   <031B96AC>  
(From EV_APPLICATION)  Routine failure.  
Fail---GUI_APP_ROOT
make_and_launch @5  <031B96AC>  
   Routine failure.  
Fail---GUI_APP_ROOT
root's creation <031B96AC>  
   Routine failure.  
Exit---


-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: pazospa...@hotmail.com
To: openehr-technical@lists.openehr.org
Subject: ADL Workbench exceptions when opening the audiogram archetype
Date: Tue, 14 Jun 2016 01:15:37 -0300




Hi,
I downloaded the ADLWB Windows (32-bit) 2.0.6.2844  from 
http://www.openehr.org/downloads/ADLworkbench/home
And downloaded the audiogram result archetype from here: 
http://ckm.openehr.org/ckm/#showArchetype_1013.1.44
That archetype has some validity warnings and I wanted to see those warnings 
using the ADLWB, but when I tried to open the archetype, the ADLWB throws:

 Thread exception 
*In thread   Root thread0x0 
(thread 
id)***---Class
 / Object  RoutineNature of exception   
Effect---ARCHETYPE_LIBRARY_INTERFACES
item @1<033486AC>   
  Assertion violated.   
Fail---ARCHETYPE_LIBRARY_INTERFACES
item @1<033486AC>   
  Routine failure.  
Fail---GUI_LIBRARY_TOOL
use_current_library @3  <0338B930>  
(From SHARED_ARCHETYPE_LIBRARIES)   
Routine failure.  
Fail---GUI_LIBRARY_TOOL
current_library @2  <0338B930>  
(From SHARED_ARCHETYPE_LIBRARIES)   
Routine failure.  
Fail---GUI_LIBRARY_TOOL
open_adhoc_archetype @8<0338B930> Routine 
failure.  
Fail---EV_NOTIFY_ACTION_SEQUENCE
call @21   <03379B94>  (From 
ACTION_SEQUENCE) Routine failure.  
Fail---EV_NOTIFY_ACTION_SEQUENCE
call @3<03379B94>  (From 
EV_LITE_ACTION_SEQUENCE)   Routine 
failure.  
Fail---EV_MENU_ITEM_IMP
on_activate @2  <03379AD4>  
   Routine failure.  
Fail---EV_MENU_BAR_IMP
 menu_item_clicked @4<03377584>  
(From EV_MENU_ITEM_LIST_IMP)   Routine 
failure.  
Fail

Specs about ACTIVITY.timing still unclear

[pablo pazos]

Hi,
I was reviewing the latest specs and, compared with 1.0.2 where ACTIVITY.timing 
usage is not so clear, I think we still need to improve that specific point.
1. timing description is too focused on medication
"Many Instructions will have only one Activity, usually describing a medication 
to be administered and its timing..."
A treatment or procedure instruction can also be repeated, like do 
physiotherapy 3 times a week, ultrasound application daily for 10 repetitions, 
etc. (you can notice I sprained an ankle not so long ago).

2. specific codes / syntax to be used
I think for the sake of completeness we need to include this in the specs. I 
reviewed the time specification from the data_types spec v1.0.2 and I'm not 
sure we are defining the syntax we need for ACTIVITY.timing.
On HL7 specs I've seen a lot of commonly used codes that I don't know if those 
are defined in any standard or if those are just common medical vocabulary, I 
mean: ac, pc, bid, tid, qid, qhs, q4h, q8h, q12h, prn, 
Maybe we can include those as part of the specs

3. the timing field description references HL7 GTS and ISO 8601
>From HL7 v3 specs, the XML form is clear enough and it has a XSD that defines 
>the GTS, but the literal expression (the string code) is not so obvious (AFAIK 
>the rules to create it are not formally defined). What I'm not sure of is if 
>we can use the XML form (*might* complicate XSD validation or the literal 
>form). From v3:
  Table 46: Examples for Literal Expressions for Generic Timing 
SpecificationsLiteral ExpressionMeaningM09 D15 H16 N30 S34.12September 15 at 
4:30:34.12 PM as the intersection of multiple periodic intervals of times 
(calendar patterns)M0915163034.12September 15 at 4:30:34.12 PM as one simple 
periodic interval of time (calendar pattern)M01; M03; M07January, March, and 
July (a union of three periodic intervals of time)M04..09 M/2Every second month 
from April to September (April, June, August)J1; J2; J4Monday, Tuesday, 
ThursdayW/2 J2every other Tuesday (intersection of every other week and every 
Tuesday)1999 WY15the 15th calendar week in 1999 (period code is optional for 
the highest calendar unit)WM2 J6Saturday of the 2nd week of the monthM05 WM2 
J6Saturday of the 2nd week of MayM05 DM08..14 J7Mother's day (second Sunday in 
May.)J1..5 H0800..1600Monday to Friday from 8 AM to 4 PMJ1..4 H0800..1600;
J5 H0800..1200Monday to Thursday 8 AM to 4 PM and Friday 8 AM to 12 noon.[10 d] 
H/8Three times a day over 10 days (each time a 60 minutes interval).H0800..1600 
\J3Every day from 8 AM to 4 PM, except Wednesday.(M0825..31 J1)..M0831The last 
calendar week of August.JHNUSMEM..JHNUSLBRThe season from the U.S. holidays 
Memorial Day to Labor Day
And about ISO, I think we are talking about the "repeating intervals" form 
(https://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals). If that is 
corrent, we should say that on the spec (the referenc to ISO 8601 is vague). On 
the other hand, the ISO specification is not publicly available, so we are 
referencing a closed spec from an open spec. That's why I think we should 
define the syntax in our specs to avoid referencing closed specs.
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: INTERVAL_EVENT questions about the correctness of the specs

[pablo pazos]

Done: https://openehr.atlassian.net/browse/SPECPR-197
I added this to the PR description: PP: is it possible to record a mean and a 
max value no the same EVENT.data? e.g. mean syst BP and max syst BP in an 
interval of time. Since there is only one math_function, for that we'll need a 
completely separated EVENT that occurs at the same time and has the same width. 
Is this the only way of representing this case? 

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: INTERVAL_EVENT questions about the correctness of the specs
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Fri, 17 Jun 2016 21:15:12 +0100


  

  
  






On 17/06/2016 04:55, pablo pazos wrote:



  
  Hi,



I'm preparing some materials for a course and I was
  reviewing the HISTORY/EVENT package.



On the INTERVAL_EVENT field descriptions I noted that those
  might not be 100% correct or clear. Before raising an issue on
  JIRA I wanted to know what you think.



INTERVAL_EVENT.width: Length of the interval during which
  the state
  was true.



- since state can be modeled in two ways, inside the
  OBSERVATION and inside the EVENT, I think the description
  should not include the "during which the state was true" since
  not every instance will have a state in the EVENT.


  



this is badly worded documentation... it actually means the value of
the event, i.e. EVENT.data, and it rather casually uses the word
'state' in its informal English usage meaning the
state/value/status/situation of something. But EVENT of course has a
'state' attribute, so, quite confusing. The proper wording would be
'the time interval during which the values recorded under 'data' are
true and, if set, the values recorded under 'state' are true.




  


  

  INTERVAL_EVENT.math_function: Mathematical function of the
  data of this
  event, e.g. “maximum”, “mean” etc. Coded
  using openEHR Terminology group “event
  math function”.



- my interpretation of that is we use that function to
  summarize a list of numeric values into one value to be
  recorded. The problem I see is: this only works if the
  observation is numeric. I think we need to make the
  description clearer about what the function is, how should be
  used and also what is the domain / range of that function
  (maybe say that only applies to datatypes from the quantity
  package).
  



agree.




  



- another possible issue (not sure about this) is that the
  EVENT.data is a structure, so we can have many data points
  there, on that case, how is the math_function related to all
  the data points? What happens if one data point is the "max"
  value and other the "avg", we have just one math_function and
  2 data points.


  



the assumption is that the math function applies meaningfully to
whatever data are there - so it's the application designer's
responsibility to get this right. Normally, the math function is
understood to apply to each data point, e.g. if it is 'mean' and
there are 'systolic' and 'diastolic', then they are assumed to be
both means (probably not terribly clinically useful but you get the
idea).



All of this documentation could be improved - can you raise a PR for
it - we can fix it in RM Release-1.0.4...



- thomas



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: ADL Workbench exceptions when opening the audiogram archetype

[pablo pazos]

Thanks Thomas,
I would say that is a common use case when you are creating archetypes, since 
the validation rules are not in the AE, I create the adl using AE but see the 
validation errors on the ADLWB.
Also, I would consider not everyone has git installed. Think of a modeling 
workshop with doctors :)
Considering that, I would say we need the File > Open to work for prototyping, 
testing and training.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: ADL Workbench exceptions when opening the audiogram archetype
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Fri, 17 Jun 2016 21:03:52 +0100


  

  
  
Pablo,

I'll look into what is going wrong there, but that's not the
  normal way to use the Workbench to look at CKM archetypes (it's
  still a bug obviously;). It will work if you follow the instructions
here - then  you can look at all CKM archetypes.

- thomas





On 17/06/2016 03:27, pablo pazos wrote:



  
  From that version (Windows (64-bit)   2.0.6.2902 build)
I get this exception opening the same archetype downloaded from
the CKM (http://ckm.openehr.org/ckm/#showArchetype_1013.1.44) 



It sees none of these versions I tested can open this
  archetype. Might be an issue with the archetype itself or with
  the CKM export. But as I said, the archetype is opened OK in
  the Archetype Editor. I'm blocked here :)



What I do is: File > Open (select 1.4) > Select
  the openEHR-EHR-OBSERVATION.audiogram.v1.adl archetype >
  Exception is thrown

  

   Thread exception
*
  In thread   Root thread0x0 (thread
id)
  
***
  
---
  Class / Object  RoutineNature of
exception   Effect
  
---
  ARCHETYPE_LIBRARY_INTERFACES
  item @1
  <065CFA88>
Assertion violated.   Fail
  
---
  ARCHETYPE_LIBRARY_INTERFACES
  item @1
  <065CFA88> Routine
failure.  Fail
  
---
  GUI_LIBRARY_TOOLuse_current_library @3  
   
  <05FC97E8>  (From
SHARED_ARCHETYPE_LIBRARIES)
 Routine
failure.  Fail
  
---
  GUI_LIBRARY_TOOLcurrent_library @2  
   
  <05FC97E8>  (From
SHARED_ARCHETYPE_LIBRARIES)
 Routine
failure.  Fail
  
---

  



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Issues setting constraints to INSTRUCTIONS in the Archetype Editor

[pablo pazos]

Hi, 
I created an INSTRUCTION archetype, under Definition > Current Activity there 
is a checkbox "ordered" that seems not to be working since when I check it I 
see the same on the ADL:
activities cardinality matches {0..*; unordered} 


This is a question really, since INSTRUCTION.narrative is DV_TEXT, it can also 
be DV_CODED_TEXT (looking at the specs I couldn't find anything against it). If 
this is correct, shouldn't the AE provide a feature to set the narrative as 
coded text?

BTW, I'm using v2.2.905 Beta.

Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

INTERVAL_EVENT questions about the correctness of the specs

[pablo pazos]

Hi,
I'm preparing some materials for a course and I was reviewing the HISTORY/EVENT 
package.
On the INTERVAL_EVENT field descriptions I noted that those might not be 100% 
correct or clear. Before raising an issue on JIRA I wanted to know what you 
think.
INTERVAL_EVENT.width: Length of the interval during which the state
was true.
- since state can be modeled in two ways, inside the OBSERVATION and inside the 
EVENT, I think the description should not include the "during which the state 
was true" since not every instance will have a state in the EVENT.


INTERVAL_EVENT.math_function: Mathematical function of the data of this
event, e.g. “maximum”, “mean” etc. Coded
using openEHR Terminology group “event
math function”.
- my interpretation of that is we use that function to summarize a list of 
numeric values into one value to be recorded. The problem I see is: this only 
works if the observation is numeric. I think we need to make the description 
clearer about what the function is, how should be used and also what is the 
domain / range of that function (maybe say that only applies to datatypes from 
the quantity package).
- another possible issue (not sure about this) is that the EVENT.data is a 
structure, so we can have many data points there, on that case, how is the 
math_function related to all the data points? What happens if one data point is 
the "max" value and other the "avg", we have just one math_function and 2 data 
points.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Issues setting constraints to INSTRUCTIONS in the Archetype Editor

[pablo pazos]

Thanks Ian,
Maybe if narrative can't be coded text, we might want to add that clarification 
to the specs or, as you suggest, use string as type.
What do members of the SEC think about this?

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: i...@freshehr.com
Date: Fri, 17 Jun 2016 21:13:03 +0100
Subject: Re: Issues setting constraints to INSTRUCTIONS in the Archetype Editor
To: openehr-technical@lists.openehr.org

Hi Pablo,
The ordered checkbox actually applies to the ITEM_TREE within the activity








INSTRUCTION[at] matches {   -- Care Plan

  activities cardinality matches {0..*; unordered} matches {

ACTIVITY[at0001] occurrences matches {0..1} matches {   -- Activity

action_archetype_id matches {/openEHR-EHR-ACTION\.care_plan\.v1/}

description matches {

ITEM_TREE[at0004] matches { -- Tree

 items cardinality matches {0..*; ordered} matches {

ELEMENT[at0017] 
occurrences matches {0..1} matches {-- Care Plan Name



What is your use-case for strict ordering of activities?



With regard to 'narrative' - that should definitely just be free text - it is 
intended as a pure narrative representation of the key parts of the instruction 
as a 'sanity check' for complex orders. It should not be CODED_TEXT, and 
arguably just 'string'.
Ian


Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.orgDirector, freshEHR 
Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 17 June 2016 at 20:50, pablo pazos <pazospa...@hotmail.com> wrote:



Hi, 
I created an INSTRUCTION archetype, under Definition > Current Activity there 
is a checkbox "ordered" that seems not to be working since when I check it I 
see the same on the ADL:
activities cardinality matches {0..*; unordered} 


This is a question really, since INSTRUCTION.narrative is DV_TEXT, it can also 
be DV_CODED_TEXT (looking at the specs I couldn't find anything against it). If 
this is correct, shouldn't the AE provide a feature to set the narrative as 
coded text?

BTW, I'm using v2.2.905 Beta.

Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   

___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

New EHRServer v0.5 and roadmap

[pablo pazos]

Hi all!
I'm very excited to share the good news with all my openEHR friends here.
We have released EHRServer v0.5! This version is what we could call "feature 
complete", so it includes all the minimum features of a real openEHR server, 
the latest ones related to securing the API, and before that, supporting 
multi-tenancy.
I'll release user documentation and a full REST API documentation in the next 
couple of days, and will record a demo in English on YouTube via Hangout. I 
made a demo in Spanish not so long ago: 
https://www.youtube.com/watch?v=84YiNfkLGMA
Also, we have a staging server to test the EHRServer*, you are very welcome to 
try it and give us some feedback to continue improving the tool: 
https://cabolabs-ehrserver.rhcloud.com/ehr
* You can create an account and start using it.
Note: the server is not so fast, but is usable.

I'm working hard on v0.6 right now, hopefully we'll have a release before 
February. This version will include fixes to the UI, REST API, and security 
checks, more testing, testable REST API docs, among other things. The focus 
will be on robustness, security, and consistency more than adding new features. 
We can call the EHRServer v0.6 a "production ready" system.
I started to meet with some friends and colleagues interested on using the 
EHRServer as an open-source openEHR backend. My next focus will be on building 
pilot projects with some companies, to let them try the EHRServer and see if it 
fits their needs and gathering information to improve it. If anyone is 
interested, please give me a ring or ping my by email!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: New EHRServer v0.5 and roadmap

[pablo pazos]

HI all!
Small updates:
1. I have made a small addition to the EHRServer Guide to explain how to use 
the Authentication token in API calls
See http://cabolabs.com/software_resources/EHRServer_v0.5.pdf page 14

2. Next Friday I'll do an online demo in English, everyone is welcome to assist 
to the live demo and we can have a small conversation or Q/A session after.
https://plus.google.com/events/cbk5sh0lq6ujnsjhrmob8nvl860

3. If you want to test the query builder buy don't have time to create data 
commits using the API, you have a committer app available. This is a small app 
I created for internal testing purposes. You can login using you EHRServer 
credentials, click on OPTs, fill data (dummy data is generated) and commit it 
to the EHRServer, then create your queries and see what happens :D
Before doing that, you should create one patient for your organization, so you 
can commit data to his/her EHR.
http://committer-ehrserver.rhcloud.com/committer

BTW, anyone tried to access EHRServer from a mobile phone? I tried hard to make 
it look good on mobile devices. Also the committer app should look ok on mobile 
devices, in fact on my free time I commit data to the server from my phone, to 
simulate real usage and see if the server can handle the load and if the 
queries are fast.

If you have any questions, just let me know!
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: pazospa...@hotmail.com
To: openehr-technical@lists.openehr.org; openehr-implement...@lists.openehr.org
Subject: New EHRServer v0.5 and roadmap
Date: Thu, 14 Jan 2016 02:42:16 -0300




Hi all!
I'm very excited to share the good news with all my openEHR friends here.
We have released EHRServer v0.5! This version is what we could call "feature 
complete", so it includes all the minimum features of a real openEHR server, 
the latest ones related to securing the API, and before that, supporting 
multi-tenancy.
I'll release user documentation and a full REST API documentation in the next 
couple of days, and will record a demo in English on YouTube via Hangout. I 
made a demo in Spanish not so long ago: 
https://www.youtube.com/watch?v=84YiNfkLGMA
Also, we have a staging server to test the EHRServer*, you are very welcome to 
try it and give us some feedback to continue improving the tool: 
https://cabolabs-ehrserver.rhcloud.com/ehr
* You can create an account and start using it.
Note: the server is not so fast, but is usable.

I'm working hard on v0.6 right now, hopefully we'll have a release before 
February. This version will include fixes to the UI, REST API, and security 
checks, more testing, testable REST API docs, among other things. The focus 
will be on robustness, security, and consistency more than adding new features. 
We can call the EHRServer v0.6 a "production ready" system.
I started to meet with some friends and colleagues interested on using the 
EHRServer as an open-source openEHR backend. My next focus will be on building 
pilot projects with some companies, to let them try the EHRServer and see if it 
fits their needs and gathering information to improve it. If anyone is 
interested, please give me a ring or ping my by email!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: New EHRServer v0.5 and roadmap

[pablo pazos]

Thanks Seref, this is really kind of you. I agree that we need more open source 
implementation out there and I hope my little project help others to develop 
their own.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Date: Thu, 14 Jan 2016 20:30:10 +
Subject: Re: New EHRServer v0.5 and roadmap
From: serefari...@kurumsalteknoloji.com
To: openehr-technical@lists.openehr.org

Hi Pablo, Just wanted to say well done. I have not had the chance to look at 
your work, mainly because work and studies forced me to take a step back from 
open source efforts, but it is great to see the continuous progress you're 
making. It is very important that there is an open source implementation of 
openEHR out there that is actively developed. Don't worry about the performance 
either. If someone wants to use it and they think it is not fast, they should 
pay you to make it faster. 
I hope it gets adopted and you keep working on it. 
All the bestSeref

On Thu, Jan 14, 2016 at 5:42 AM, pablo pazos <pazospa...@hotmail.com> wrote:



Hi all!
I'm very excited to share the good news with all my openEHR friends here.
We have released EHRServer v0.5! This version is what we could call "feature 
complete", so it includes all the minimum features of a real openEHR server, 
the latest ones related to securing the API, and before that, supporting 
multi-tenancy.
I'll release user documentation and a full REST API documentation in the next 
couple of days, and will record a demo in English on YouTube via Hangout. I 
made a demo in Spanish not so long ago: 
https://www.youtube.com/watch?v=84YiNfkLGMA
Also, we have a staging server to test the EHRServer*, you are very welcome to 
try it and give us some feedback to continue improving the tool: 
https://cabolabs-ehrserver.rhcloud.com/ehr
* You can create an account and start using it.
Note: the server is not so fast, but is usable.

I'm working hard on v0.6 right now, hopefully we'll have a release before 
February. This version will include fixes to the UI, REST API, and security 
checks, more testing, testable REST API docs, among other things. The focus 
will be on robustness, security, and consistency more than adding new features. 
We can call the EHRServer v0.6 a "production ready" system.
I started to meet with some friends and colleagues interested on using the 
EHRServer as an open-source openEHR backend. My next focus will be on building 
pilot projects with some companies, to let them try the EHRServer and see if it 
fits their needs and gathering information to improve it. If anyone is 
interested, please give me a ring or ping my by email!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   

___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: New EHRServer v0.5 and roadmap

[pablo pazos]

@all the guide is ready!
http://cabolabs.com/software_resources/EHRServer_v0.5.pdf
Please let me know if you find any errors or if any part needs clarifications, 
thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: pazospa...@hotmail.com
To: openehr-technical@lists.openehr.org
Subject: RE: New EHRServer v0.5 and roadmap
Date: Thu, 14 Jan 2016 22:56:13 -0300




Thanks Seref, this is really kind of you. I agree that we need more open source 
implementation out there and I hope my little project help others to develop 
their own.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Date: Thu, 14 Jan 2016 20:30:10 +
Subject: Re: New EHRServer v0.5 and roadmap
From: serefari...@kurumsalteknoloji.com
To: openehr-technical@lists.openehr.org

Hi Pablo, Just wanted to say well done. I have not had the chance to look at 
your work, mainly because work and studies forced me to take a step back from 
open source efforts, but it is great to see the continuous progress you're 
making. It is very important that there is an open source implementation of 
openEHR out there that is actively developed. Don't worry about the performance 
either. If someone wants to use it and they think it is not fast, they should 
pay you to make it faster. 
I hope it gets adopted and you keep working on it. 
All the bestSeref

On Thu, Jan 14, 2016 at 5:42 AM, pablo pazos <pazospa...@hotmail.com> wrote:



Hi all!
I'm very excited to share the good news with all my openEHR friends here.
We have released EHRServer v0.5! This version is what we could call "feature 
complete", so it includes all the minimum features of a real openEHR server, 
the latest ones related to securing the API, and before that, supporting 
multi-tenancy.
I'll release user documentation and a full REST API documentation in the next 
couple of days, and will record a demo in English on YouTube via Hangout. I 
made a demo in Spanish not so long ago: 
https://www.youtube.com/watch?v=84YiNfkLGMA
Also, we have a staging server to test the EHRServer*, you are very welcome to 
try it and give us some feedback to continue improving the tool: 
https://cabolabs-ehrserver.rhcloud.com/ehr
* You can create an account and start using it.
Note: the server is not so fast, but is usable.

I'm working hard on v0.6 right now, hopefully we'll have a release before 
February. This version will include fixes to the UI, REST API, and security 
checks, more testing, testable REST API docs, among other things. The focus 
will be on robustness, security, and consistency more than adding new features. 
We can call the EHRServer v0.6 a "production ready" system.
I started to meet with some friends and colleagues interested on using the 
EHRServer as an open-source openEHR backend. My next focus will be on building 
pilot projects with some companies, to let them try the EHRServer and see if it 
fits their needs and gathering information to improve it. If anyone is 
interested, please give me a ring or ping my by email!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   

___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

EHRServer v0.7 is out!

[pablo pazos]

Dear friends,

Just wanted to send a quick message to the lists with exciting news: the 
openEHR EHRServer v0.7 was released!

Here you can find the code: 
https://github.com/ppazos/cabolabs-ehrserver/releases

And here the updated docs: http://cabolabs.com/en/projects

If you want to play with it, here is our staging server: 
https://cabolabs-ehrserver.rhcloud.com/ehr

I will do an online demo via Hangouts very soon, stay tuned!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Specs about ACTIVITY.timing still unclear

[pablo pazos]

Thanks for your message Ian,

IMO avoiding the implementation of ACTIVITY.timing raises the question of why 
that was introduced in the model and if we should keep it or not.

On the other hand, I think timing there can be a powerful tool for advanced 
systems that can use that info to manage / automate flows / processes.


The problem with timing is that it is difficult to specify in a generic way, 
and I have seen at least 3 kinds of proposals:

1. Computable expressions
2. Terminology based
3. Structure based


1. Computable expressions

+ idea: try to define a code that can be processed by software.
+ pro: everyone loves codes, systematized approach
+ con: expressions are too complex to be defined just by a code, makes this 
solution almost unrealistic.


2. Terminology based

+ idea: just define all the possible timing schemes and their definitions e.g. 
QID, Q4H, AC, PC, ...
+ pro: easy to use, easier to define and maintain than approach 1.
+ con: ?


3. Structure based

+ idea: define a structure (maybe a hierarchy in an UML model) to represent 
different timing expressions (like the HL7 time expressions datatypes or what 
Ian mentioned of creating a CLUSTER archetype)
+ pro: easy to specify in an OO model, extendable, easy to implement (the model 
can include state + behavior)
+ con: ?



I would like we consider to make a proposal on how to use timing on the openEHR 
specs, oriented to implementation, and not focused only on medication (current 
specs examples are just for medication).

1. We can extend our timing specification to be compatible with the HL7 / FHIR 
one (add/modify our datatypes). I think with this we don't need to make custom 
timing specs on archetypes.
2. Add to our terminology spec the most commonly used terms for timing, so we 
can use them as part of our timing specification.
3. Add more examples oriented to long term treatment, procedures, tests, etc. 
alongside with medication therapy in the specs, or maybe in a "timing addendum".

OR

Define to remove timing completely from the openEHR model and rely on 
archetyped timing on ACTIVITY.description.


-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: i...@freshehr.com
Date: Sat, 18 Jun 2016 08:41:13 +0100
Subject: Re: Specs about ACTIVITY.timing still unclear
To: openehr-technical@lists.openehr.org
CC: s...@lists.openehr.org

Hi Pablo,
I think it is fair to say that ACtivity.timing not used much (if at all). The 
various timing syntax options are far from standardised around the world.
.timing is also difficult since real-world timings are often nested and need to 
be associated with specific parts of the archetype.
The approach we have taken with Medication is to develop two timing Cluster 
archetypes.
Timing - daily, Draft Archetype [Internet]. openEHR Foundation, openEHR 
Clinical Knowledge Manager [cited: 2016-06-18]. Available from: 
http://openehr.org/ckm/#showArchetype_1013.1.2245

and
Timing - repetition, Draft Archetype [Internet]. openEHR Foundation, openEHR 
Clinical Knowledge Manager [cited: 2016-06-18]. Available from: 
http://openehr.org/ckm/#showArchetype_1013.1.2246

and have also allowed for a parseable dose string in the Medication order 
archetype.
Medication order, Draft Archetype [Internet]. openEHR Foundation, openEHR 
Clinical Knowledge Manager [cited: 2016-06-18]. Available from: 
http://openehr.org/ckm/#showArchetype_1013.1.1445

I have an outstanding task to show some examples of use in more complex 
medication orders.
Personally, I advise implementers to avoid ACTIVITY.timing.
I would be interested to know if/how others use it.
IanDr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.orgDirector, freshEHR 
Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 June 2016 at 03:26, pablo pazos <pazospa...@hotmail.com> wrote:



Hi,
I was reviewing the latest specs and, compared with 1.0.2 where ACTIVITY.timing 
usage is not so clear, I think we still need to improve that specific point.
1. timing description is too focused on medication
"Many Instructions will have only one Activity, usually describing a medication 
to be administered and its timing..."
A treatment or procedure instruction can also be repeated, like do 
physiotherapy 3 times a week, ultrasound application daily for 10 repetitions, 
etc. (you can notice I sprained an ankle not so long ago).

2. specific codes / syntax to be used
I think for the sake of completeness we need to include this in the specs. I 
reviewed the time specification from the data_types spec v1.0.2 and I'm not 
sure we are defining the syntax we need for ACTIVITY.timing.
On HL7 specs I've seen a lot of commonly used codes that I don't know if those 
are defined in any standard or if those are just common medical vocabulary, I 
mean: ac, p

Archetype OBSERVATION.data.summary

[pablo pazos]

Hi, I'm trying to archetype the HISTORY.summary structure of an OBSERVATION 
archetype but I can't find that on the archetype editor UI.
I'm using AE 2.2.905 Beta.
Any pointers are welcome.


A thing more related with usability, is that for an OBSERVATION, under the 
Definition > Data tab, there are the Structure and Events tabs. Adding nodes to 
the Structure is really adding nodes inside OBS > data > events, but I would 
expect to do that under the Events tab. On the Events tab I can set the type of 
event, add alternative event nodes, and set some constraints, but not the 
internal structure.
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Updated XSLT

[pablo pazos]

Hi,
I'm using the XSLT openEHR_RMtoHTML.xsl (found here 
https://openehr.atlassian.net/wiki/display/dev/openEHR+Composition+XML+to+HTML?focusedCommentId=32014341#comment-32014341)
 to format XML compositions into HTML in the EHRServer 
(https://github.com/ppazos/cabolabs-ehrserver).
Recently I added support to DV_IDENTIFIER and DV_DATE to the EHRServer and 
noticed those DVs weren't supported by the XSLT, so I added them: 
https://github.com/ppazos/cabolabs-ehrserver/commit/a97047aee7f418fe38b9c58d228742c992aca405
Feel free to grab it from my repo. If there is any official openEHR project 
that uses that XSLT, I can send a pull request. Just let me know.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

EHRServer whitepaper

[pablo pazos]

Dear friends,
I'm writing a small white paper about the EHRServer, and wanted to share the 
v0.1 with you first. Please let me know what you think, and if you find any 
errors, please let me know where.

https://drive.google.com/file/d/0B27lX-sxkymfbHNhZEN5RTlvUnc/view?usp=sharing
Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Template Designer alternatives

[pablo pazos]

HI all,
I tried the latest release of the TD and keeps having some constraints on 
modelling, like the impossibility of specifying that a DV_TEXT will be used as 
DV_CODED_TEXT on the data type option, or removing (0..0) slots that will not 
be used on the final OPT.
I'm wondering if are there any template designer alternatives to create 
operational templates, that allows to set DV_TEXTs as DV_CODED_TEXT only or 
setting the 0..0 occurrence to SLOT nodes.
Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Template Designer alternatives

[pablo pazos]

Is there an open source version? Until I have some funding can't buy any 
licenses. Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Date: Sun, 28 Feb 2016 08:43:23 +0100
Subject: Re: Template Designer alternatives
From: yamp...@gmail.com
To: openehr-technical@lists.openehr.org
CC: openehr-implement...@lists.openehr.org

LinkEHR has the ability to import and export OPT and OET. Once you import it is 
just treated as an archetype, so in principle any constraint can be defined. 
Regards 
El 28/2/2016 7:56, "pablo pazos" <pazospa...@hotmail.com> escribió:



HI all,
I tried the latest release of the TD and keeps having some constraints on 
modelling, like the impossibility of specifying that a DV_TEXT will be used as 
DV_CODED_TEXT on the data type option, or removing (0..0) slots that will not 
be used on the final OPT.
I'm wondering if are there any template designer alternatives to create 
operational templates, that allows to set DV_TEXTs as DV_CODED_TEXT only or 
setting the 0..0 occurrence to SLOT nodes.
Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   

___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: New EHRServer v0.5 and roadmap

[pablo pazos]

Hi! here is the video of the demo: https://youtu.be/aHRDR5Vg2Hc?t=2m10s

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: pazospa...@hotmail.com
To: openehr-technical@lists.openehr.org; openehr-implement...@lists.openehr.org
Subject: RE: New EHRServer v0.5 and roadmap
Date: Sun, 17 Jan 2016 00:54:03 -0300




HI all!
Small updates:
1. I have made a small addition to the EHRServer Guide to explain how to use 
the Authentication token in API calls
See http://cabolabs.com/software_resources/EHRServer_v0.5.pdf page 14

2. Next Friday I'll do an online demo in English, everyone is welcome to assist 
to the live demo and we can have a small conversation or Q/A session after.
https://plus.google.com/events/cbk5sh0lq6ujnsjhrmob8nvl860

3. If you want to test the query builder buy don't have time to create data 
commits using the API, you have a committer app available. This is a small app 
I created for internal testing purposes. You can login using you EHRServer 
credentials, click on OPTs, fill data (dummy data is generated) and commit it 
to the EHRServer, then create your queries and see what happens :D
Before doing that, you should create one patient for your organization, so you 
can commit data to his/her EHR.
http://committer-ehrserver.rhcloud.com/committer

BTW, anyone tried to access EHRServer from a mobile phone? I tried hard to make 
it look good on mobile devices. Also the committer app should look ok on mobile 
devices, in fact on my free time I commit data to the server from my phone, to 
simulate real usage and see if the server can handle the load and if the 
queries are fast.

If you have any questions, just let me know!
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: pazospa...@hotmail.com
To: openehr-technical@lists.openehr.org; openehr-implement...@lists.openehr.org
Subject: New EHRServer v0.5 and roadmap
Date: Thu, 14 Jan 2016 02:42:16 -0300




Hi all!
I'm very excited to share the good news with all my openEHR friends here.
We have released EHRServer v0.5! This version is what we could call "feature 
complete", so it includes all the minimum features of a real openEHR server, 
the latest ones related to securing the API, and before that, supporting 
multi-tenancy.
I'll release user documentation and a full REST API documentation in the next 
couple of days, and will record a demo in English on YouTube via Hangout. I 
made a demo in Spanish not so long ago: 
https://www.youtube.com/watch?v=84YiNfkLGMA
Also, we have a staging server to test the EHRServer*, you are very welcome to 
try it and give us some feedback to continue improving the tool: 
https://cabolabs-ehrserver.rhcloud.com/ehr
* You can create an account and start using it.
Note: the server is not so fast, but is usable.

I'm working hard on v0.6 right now, hopefully we'll have a release before 
February. This version will include fixes to the UI, REST API, and security 
checks, more testing, testable REST API docs, among other things. The focus 
will be on robustness, security, and consistency more than adding new features. 
We can call the EHRServer v0.6 a "production ready" system.
I started to meet with some friends and colleagues interested on using the 
EHRServer as an open-source openEHR backend. My next focus will be on building 
pilot projects with some companies, to let them try the EHRServer and see if it 
fits their needs and gathering information to improve it. If anyone is 
interested, please give me a ring or ping my by email!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  

___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Archetype relational mapping - a practical openEHR persistence solution

[pablo pazos]

ORM is not a problem with current tools. In fact frameworks like Hibernate and 
Grails make Object-Relational Mapping something enjoyable to work with. I think 
the problem with the described approach is the growth of the relational schema 
when your knowledge base grows.
But there are design challenges, ORM doesn't solve all the problems itself. 
IMHO, the object model that should be mapped to relational, if relational is 
chosen as DBMS, is not the raw openEHR IM. Simplifications over the IM are 
needed in order to prevent excessive JOINs and huge hierarchies. In fact I 
teach this in one of my courses and this was part of the tutorial we did on 
MEDINFO. For example, the OBJECT_REFs can be designed as simple relationships, 
because plays the role of a FK in the object model. There are many 
simplifications that can be done to reach an object model that is compatible 
with the openEHR model but more "relational friendly".

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Date: Mon, 25 Jan 2016 18:42:01 +0100
Subject: Re: Archetype relational mapping - a practical openEHR persistence 
solution
From: bert.verh...@rosa.nl
To: openehr-technical@lists.openehr.org

Another problem is you have to convert your object oriented model (which RM is) 
to a relational model, which becomes complex in converting templates/aql to 
SQL. I have been that way. More then five years ago I left it. It is difficult 
doable, if you want a full featured openehr kernel. I would never recommend 
going this way, unless someone has a really smart idea.
It can work for a light featured openehr light derived application model.
Best regards 

Bert
Op 25 jan. 2016 15:26 schreef "pazospa...@hotmail.com" <pazospa...@hotmail.com>:






I talked about this approach with a colleague from China during MEDINFO. 
The problem is your schema grows with your archetypes. Also, that storing data 
from many templates that don't use all the fields in the archetype, will 
generate sparse tables (lots of null columns). I told him it was easier to do 
an ORM from the IM, because the schema doesn't change and allows to store data 
from any archetype/template. But they already have a system working this way.
Sent from my LG Mobile


-- Original message--From: Ian McNicollDate: Mon, Jan 25, 2016 10:06To: 
For openEHR technical discussions;Subject:Archetype relational mapping - a 
practical openEHR persistence solutionInteresting paper from China
http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0
IanDr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.orgDirector, freshEHR 
Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: EHRServer whitepaper

[pablo pazos]

Hi all, I have released EHRServer v0.6 and updated the whitepaper and the 
guide, all the info is here: http://cabolabs.com/en/projects
Feedback is very welcome!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: pazospa...@hotmail.com
To: openehr-technical@lists.openehr.org; openehr-implement...@lists.openehr.org
Subject: EHRServer whitepaper
Date: Sun, 31 Jan 2016 03:35:48 -0300




Dear friends,
I'm writing a small white paper about the EHRServer, and wanted to share the 
v0.1 with you first. Please let me know what you think, and if you find any 
errors, please let me know where.

https://drive.google.com/file/d/0B27lX-sxkymfbHNhZEN5RTlvUnc/view?usp=sharing
Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   

___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: rm_type_name for the DV_DURATIONs primitive object in XML

[pablo pazos]

I think a C_DURATION can add constraints over the width of the duration 
(between two given values, below given value, above given value, i.e. an 
interval, this is really for the magnitude = duration to seconds or 
milliseconds, so it will be interval, or to the string expression 
itself with regex for example.
The problem with the regex is that should be an ISO8601_DURATION valid regex, 
but more constrained, like years between 2 given years or greater than give 
year, etc. Not sure if we need this kind of (over) engineering / complexity on 
the archetypes. I would go just with constraining the magnitude width, and let 
the more specific constraints to be implemented at the software level.
IMO, we need ISO8601_DURATION to represent the internal structure, and 
C_DURATION for data constraints, to be part of DV_DURATION constraints.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: sebastian.ga...@oceaninformatics.com
To: openehr-technical@lists.openehr.org
Subject: RE: rm_type_name for the DV_DURATIONs primitive object in XML
Date: Fri, 18 Mar 2016 08:45:19 +









Yes, that seems be another possible interpretation of the specs.
So, it could be ISO8601_DURATION with a possible C_DURATION constraint 
underneath.
Or it could be a STRING with a possible C_STRING constraint underneath.
 
Semantically, it seems to be pretty much the same (because of the invariant), 
but syntactically it matters for anybody or a tooling having to deal with this.

 
I prefer it to be the first, I think, because it is clearer, and from what I 
understand this is your and Heath’s preference of what it should(!) be as well.
But for now, looking at the specs, it clearly says String  [with an 
invariant]…so it seems that that is what it needs to be changed to?

This includes changing the C_DURATION underneath to a C_STRING as well, I would 
assume across the various tools.
 
I just wonder why it was modelled that way in the specs (was it just an 
oversight, or is there a good reason such as that Duration is not (usually) an 
inbuilt datatype)
 
Cheers
Sebastian
 
 


From: pazospa...@hotmail.com [mailto:pazospa...@hotmail.com]


Sent: Donnerstag, 17. März 2016 04:03

To: Sebastian Garde <sebastian.ga...@oceaninformatics.com>; 
openehr-technical@lists.openehr.org

Subject: Re: rm_type_name for the DV_DURATIONs primitive object in XML


 

I think the primitive is string with ISO 8601 format, so ISO8601_DURATION might 
be correct.
 
Sent from my LG Mobile


-- Original message--
From: Sebastian Garde
Date: Tue, Mar 15, 2016 09:36
To: For openEHR technical discussions;
Subject:rm_type_name for the DV_DURATIONs primitive object in XML
Dear all,
 
There are a differences in how the Template Designer and how CKM construct the 
XML for a DV_Duration:
 
Take this snippet (from 
http://openehr.org/ckm/#showArchetype_1013.1.123_XML )
 

DV_DURATION

  true
  true
  false
  false
 1
  1



  value
  
true
true
false
false
1
1
  
  
DV_DURATION

  true
  true
  false
  false
  1
  1



  PMWD
  
true
true
  

  

  
 
What is the correct rm_type_name for C_PRIMITIVE_OBJECT here (in old red above)?
 
Is it “DV_DURATION” as the Java Ref Impl uses or is it simply “DURATION” (both 
for reason I don’t really understand)
or should it maybe be “String” or “ISO8901_DURATION” as
http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042
 and/or
http://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1422968609347_115062_25681
 describe.
 
Frankly I am confused, but I hope that someone can enlighten me here?
 
Cheers
Sebastian
 
 





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Template Designer alternatives

[pablo pazos]

Hi Heath, I think this would work for my needs, will try it on the weekend and 
get back here if I find any issues.
Thanks a lot!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: openehr-technical@lists.openehr.org; openehr-implement...@lists.openehr.org
Subject: RE: Template Designer alternatives
Date: Sun, 28 Feb 2016 23:05:58 +









Hi Pablo,
Since templates are intended to assign terminology bindings for specific 
implementation, the Template Design skips the step to need
 to specify a coded text type and allows you to specify a terminology binding 
using the Value set (terminology) property as shown below.
 

 

 
The above tab uses the Ocean terminology service (DEMO), you can select 
predefined value set or select a full terminology. The Generic
 Value Set tab allows your own value set references
 

 
 
Alternatively, you can specify an inline value set using the property above as 
shown below. Select the Terminology checkbox, enter
 the code and value and finally the terminology drop down list (this needs to 
be last to get the + button to enable).
 

 
Both of these methods result in the OPT outputting a CODE_TEXT constraint.
 
Heath
 


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of pablo pazos

Sent: Sunday, 28 February 2016 5:25 PM

To: openeh technical <openehr-technical@lists.openehr.org>; openehr 
implementers <openehr-implement...@lists.openehr.org>

Subject: Template Designer alternatives


 

HI all,

 


I tried the latest release of the TD and keeps having some constraints on 
modelling, like the impossibility of specifying that a DV_TEXT will be used as 
DV_CODED_TEXT on the data type option,
 or removing (0..0) slots that will not be used on the final OPT.


 



I'm wondering if are there any template designer alternatives to create 
operational templates, that allows to set DV_TEXTs as DV_CODED_TEXT only or 
setting the 0..0 occurrence to SLOT nodes.


 


Thanks!


 



-- 

Kind regards,

Eng. Pablo Pazos Gutiérrez

http://cabolabs.com





No virus found in this message.

Checked by AVG - www.avg.com

Version: 2015.0.6189 / Virus Database: 4533/11681 - Release Date: 02/22/16




___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Composition commit and change types

[pablo pazos]

@Bert, no worries :)
@Ian, for now, I'll add a rule like this:
If committed compo is persistent  If there is no versioned_compo for the root 
archetype of the committed compo // this check is newIf change_type == 
creation // only allows to create one persistent compo, all other commits 
should be modifications  create versioned_compo with version v1  return 
200 OKElse  return 400 Bad Request  ElseIf change_type in 
[amendment, modification]  create new version in existing versioned_compo 
// this will create v2, v3, ...  return 200 OKElse // not considering 
delete for now, this do not allows to create another instace v1 for the same 
persistent compo archetype  return 400 Bad Request


For event compos, it just follows the common versioning flow, allowing to 
create any number of v1 instances with change_type creation, and version them 
using amendment or modification.
Does this makes sense? If yes, maybe this can help other implementations :)

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

> From: i...@freshehr.com
> Date: Sun, 3 Apr 2016 11:06:53 +0100
> Subject: Re: Composition commit and change types
> To: pazospa...@hotmail.com
> CC: openehr-technical@lists.openehr.org
> 
> " I would focus on intra hospital longitudinal lists since it is very
> difficult to reach agreement in the enterprise."
> 
> I agree. These decisions are partly technical but largely down to the
> level of commitment/ consensus you can get in your clinical community
> to jointly curate these lists over time. The value of longitudinal
> persistence only accrues if everyone has commitment to the on-going
> curation process and is prepared to work within a common governance
> framework, rights and responsibilities.
> 
> http://www.bcs.org/content/conWebDoc/17923
> 
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
> 
> On 3 April 2016 at 09:07, pazospa...@hotmail.com <pazospa...@hotmail.com> 
> wrote:
> > Good info and the criteria makes sense.
> >
> >
> > I would use episodic for things like hospitalization and treatments that are
> > not a knee time thing (event), maybe with help of folders. Also I would
> > focus on intra hospital longitudinal lists since it is very difficult to
> > reach agreement in the enterprise. And when that time comes, I would just
> > implement a new set of rules for the enterprise :)
> >
> >
> > Thanks!
> >
> >
> > Sent from my LG Mobile
> >
> > -- Original message--
> >
> > From: Ian McNicoll
> >
> > Date: Sat, Apr 2, 2016 15:50
> >
> > To: For openEHR technical discussions;
> >
> > Subject:Re: Composition commit and change types
> >
> > Hi Pablo,When I am advising implementers on this, I use the following
> > categories ...## Composition Commit StylesDepending on the clinical
> > requirement, 3 styles of commit strategy aresuggested.1. **’Event’**e.g
> > Nursing observations, clinical encounters, reports.Each time the composition
> > is committed, create a new instance via a POST.Generally only do a PUT if an
> > error needs to be corrected2. **’Episodic’**Create a new composition via
> > POST for each Period of Care i.e anadmission. If it needs to updated, use a
> > PUT to modify i.e Eachpatient has a single instance per Period of Care.3.
> > **’Longitudinal’**Create a new composition via POST for each patient. If it
> > needs toupdated use a PUT to modify i.e. each patient has only a
> > singleinstance over their lifetime. This will be unusual in a hospitalrecord
> > where there is generally limited ability to curate the patientrecord in this
> > way.So your persistence uses cases are either 2/3. Currently to
> > manageEpisodic persistence, you need ot set the composition category
> > toevent, as the RM currently forces a 'persistent' composition to
> > becontextless i.e. the context attribute is 0...0. This will change inan
> > upcoming RM revision.The decision about when/where to maintain
> > persistent/curated lists isone which will vary between implementations. I
> > would generally expectMedication lists, Allergies and some documents such as
> > Resuscitationpreferences to be maintained as single, persistent instances.
> > AlthoughProblems and Procedures should also probably be maintained that
> > way,there are valid situations where departmental pro

RE: Composition commit and change types

[pablo pazos]

Hi Heath,
> There are way too many use cases where our service is used and many will 
> break this scenario like merges, distributed EHRs and cross organisational 
> shared records.
It would be helpful if you share which scenarios break the rule I stated on the 
previous email to improve it.

IMHO I don't think anybody will take this little convo as a de facto standard, 
also I'm not trying to set that, never stated that. I just want to make the 
life of my users simpler by establishing an initial set of rules they can use 
until they find requirements that might need a more complex rule set, to have 
many cases that should be supported. I prefer that to start, instead of leaving 
the definition of the rules 100% to the clients of my API, considering that 
most of them won't have any experience with openEHR and how an openEHR backend 
should work. Of course this might work for my tools and my target customers, 
and I know this won't fit everybody, but this rule might help others to adapt 
it to their specific needs. And I agree if this has to be defined for an API 
behavior, the API SEC should be the place to define it.-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org
CC: openehr-technical@lists.openehr.org
Subject: Re: Composition commit and change types
Date: Sun, 3 Apr 2016 23:36:25 +









Hi Ian and Pablo,
Although I don't like commenting on how others implement their systems I would 
hate for this discussion to become the defacto standard on how the API works in 
the context of persistent compositions. 
Although I understand Ian's position on best clinical practice of a single 
medication list represented as a persistent composition in a person's EHR, 
there is nothing stated about this in the specifications. 
I would be interested in other vendors implementations in this area, but as a 
service implementation I do not like makinging these application oriented 
decisions unless they are in the specification. There are way too many use 
cases where our service is
 used and many will break this scenario like merges, distributed EHRs and cross 
organisational shared records.
I think it is the application that needs to apply these business rules.
I think this needs to be addressed by the API SEC before recommendations that 
appear normative are made on the lists.
Personally we have had big problems with persistent compositions due to lack of 
context, although we are working on fixing these, I still feel that perhaps we 
are not ready to have the category attribute constrained in the archetypes that 
we currently
 state are persistent for these same reasons. I have seen cases where there is 
a desire for different problem lists from different clinical perspectives, in 
particular a consumers view vs a GP vs a specialist.


Regards



Heath









On Sun, Apr 3, 2016 at 11:34 AM -0700, "Ian McNicoll" 
<i...@freshehr.com> wrote:






That looks correct to me :)



Ian

Dr Ian McNicoll

mobile +44 (0)775 209 7859

office +44 (0)1536 414994

skype: ianmcnicoll

email: i...@freshehr.com

twitter: @ianmcnicoll



Co-Chair, openEHR Foundation ian.mcnic...@openehr.org

Director, freshEHR Clinical Informatics Ltd.

Director, HANDIHealth CIC

Hon. Senior Research Associate, CHIME, UCL





On 3 April 2016 at 19:20, pablo pazos <pazospa...@hotmail.com> wrote:

> @Bert, no worries :)

>

> @Ian, for now, I'll add a rule like this:

>

> If committed compo is persistent

>   If there is no versioned_compo for the root archetype of the committed

> compo // this check is new

> If change_type == creation // only allows to create one persistent

> compo, all other commits should be modifications

>   create versioned_compo with version v1

>   return 200 OK

> Else

>   return 400 Bad Request

>   Else

> If change_type in [amendment, modification]

>   create new version in existing versioned_compo // this will create v2,

> v3, ...

>   return 200 OK

> Else // not considering delete for now, this do not allows to create

> another instace v1 for the same persistent compo archetype

>   return 400 Bad Request

>

>

> For event compos, it just follows the common versioning flow, allowing to

> create any number of v1 instances with change_type creation, and version

> them using amendment or modification.

>

> Does this makes sense? If yes, maybe this can help other implementations :)

>

> --

> Kind regards,

> Eng. Pablo Pazos Gutiérrez

> http://cabolabs.com

>

>> From: i...@freshehr.com

>> Date: Sun, 3 Apr 2016 11:06:53 +0100

>> Subject: Re: Composition commit and change types

>> To: pazospa...@hotmail.com

>> CC: openehr-technical@lists.openehr.org

>

>>

>>

RE: Composition commit and change types

[pablo pazos]

I thought you had more specific cases :)
Having specific lists per clinician was commented by Karsten on a previous 
message and I commented on that. I'm not sure at which extent that is a backend 
issue, an API issue or an UI issue. I would say if this is just a display 
requirement, is more UI related and we need to find ways in the backend to 
provide the data to address this requirement, independently of if we have or 
not singleton versioned_compositions per persistent compo archetype.

OT but related:
Now this got me thinking about commits. Until now, I was thinking of full 
composition commits, so if you want to add a medication to a medication list, 
you need to commit the data in the current version, plus the new entry for the 
new medication. But what about delta commits? If I didn't changed anything on 
the current medications, can't I just commit the new medication? Is this 
possible or somebody implemented something like this?
I would think of that as a commit "mode" that applies for amendment and 
modification change_type, and would allow to log individually added entries, 
and keep track of whole "singleton" persistent lists.
Does this makes any sense?
Thanks!
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org
Subject: RE: Composition commit and change types
Date: Mon, 4 Apr 2016 05:35:13 +








Hi Pablo,
I did include my scenarios re problem list at the bottom of the email. Having 
said that there had been some movement around what compositions are persistent 
due to no context issues so problem list may no longer be a persistent 
composition.
There are similar scenarios for other persistent compositions also, it all 
comes down to context of use.



As I said, I don't like advising how others implement their systems so if you 
think your users will benefit from this rule then go ahead, I was more 
concerned about Ian's response sounding definitive than your query. This has 
risen a interesting topic
 for the API SEC to address.


Regards



Heath









On Sun, Apr 3, 2016 at 10:23 PM -0700, "pablo pazos" 
<pazospa...@hotmail.com> wrote:





Hi Heath,



> There are way too many use cases where our service is used and many will 
> break this scenario like merges, distributed EHRs and cross organisational
 shared records.



It would be helpful if you share which scenarios break the rule I stated on the 
previous email to improve it.






IMHO I don't think anybody will take this little convo as a de facto standard, 
also I'm not trying to set that, never stated that. I just want to make the 
life of my users simpler by
 establishing an initial set of rules they can use until they find requirements 
that might need a more complex rule set, to have many cases that should be 
supported. I prefer that to start, instead of leaving the definition of the 
rules 100% to the clients
 of my API, considering that most of them won't have any experience with 
openEHR and how an openEHR backend should work. Of course this might work for 
my tools and my target customers, and I know this won't fit everybody, but this 
rule might help others to
 adapt it to their specific needs. And I agree if this has to be defined for an 
API behavior, the API SEC should be the place to define it.
-- 

Kind regards,

Eng. Pablo Pazos Gutiérrez

http://cabolabs.com





From: heath.fran...@oceaninformatics.com

To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org

CC: openehr-technical@lists.openehr.org

Subject: Re: Composition commit and change types

Date: Sun, 3 Apr 2016 23:36:25 +





Hi Ian and Pablo,
Although I don't like commenting on how others implement their systems I would 
hate for this discussion to become the defacto standard on how the API works in 
the context of persistent compositions. 
Although I understand Ian's position on best clinical practice of a single 
medication list represented as a persistent composition in a person's EHR, 
there is nothing stated about this in the specifications. 
I would be interested in other vendors implementations in this area, but as a 
service implementation I do not like makinging these application oriented 
decisions unless they are in the specification. There are way too many use 
cases where our service is
 used and many will break this scenario like merges, distributed EHRs and cross 
organisational shared records.
I think it is the application that needs to apply these business rules.
I think this needs to be addressed by the API SEC before recommendations that 
appear normative are made on the lists.
Personally we have had big problems with persistent compositions due to lack of 
context, although we are working on fixing these, I still feel that perhaps we 
are not ready to have the category attribute constrained in the archetypes that 
we currently
 state are persistent

RE: Composition commit and change types

[pablo pazos]

I think that can work for some implementations.
What I was thinking is not adding parts to an existing compo, but to commit a 
full COMPO, just with the changes. That means, the newObject would be a 
COMPOSITION or even a VERSION. If this is for the Problem List, to add a new 
one, the COMPO will have just one EVALUATION with the new problem. If commit 
mode is "delta", the backend will do what it needs to reflect that addition to 
the current Problem List. If the commit mode is "full", that means one problem 
was added and the rest removed.
IMO this can use the same commit(VERSION[] versions, AUDIT_DETAILS audit) 
adding a String mode param or adding another operation commit_delta(VERSION[] 
versions, AUDIT_DETAILS audit).
For my implementation all commits are for completed COMPOS, the API you 
described might allow partial updates to already committed COMPOS, and I don't 
think delta commit should imply partial updates. Delta is just to commit a 
completed COMPO but without the need of replicating all the information that 
hasn't changed. The backend can create the full compo internally, that would 
not be an issue.
Also, that is related with the initial issue: detecting individual changes to 
persistent COMPOS. Sending just the changes, allows to identify those with the 
user responsible for the changes, so it is easier to create lists of problems, 
medications, etc. per user or organization, even if internally that is stored 
in one singleton VERSIONED_COMPO. per persistent archetype. 
Consider this is only for my implementation, I'm not looking for defining this 
for the official openEHR API, but can help as input. I want to double check my 
criteria with other implementers before implementing anything :)
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: Composition commit and change types
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Mon, 4 Apr 2016 19:50:50 +0100


  

  
  




On 04/04/2016 19:14,
  pazospa...@hotmail.com wrote:



  
  
Hi Thomas,



What about
  having the 'delta' mode just at the API level? Storage might
  not store delta objects, just full objects, but the API allows
  to send only what was added, modified or deleted instead of
  the full compo?
  



then you have a transactional concept, i.e. 'add', 'remove',
'modify' etc... so for me the better way to think about it isn't in
terms of data structures but in terms of logical changes to the
existing state of some Composition. 



But the logical thing is just a function of the form



add (atPath: String; newObject: Locatable)



so then it's just a case of what level of domain semantics you want.
For example, you could have a function:



addEntryToComposition (atPath: String; newEntry: Entry)



so it's not far to get to:



addMedicationOrder (newMed: Instruction)



Now - we don't need a path, since the API knows we are dealing with
a MedicationList Composition (that should follow an archetype of
that name) and new medication orders  (Instructions) only go in a
certain place.



So you can take your pick - the great thing about APIs is you can
have as many as you like - as long as they all obey the same rules
of data structuring and validity.



If it makes sense in your environment to create an API of the
flavour of the first one above I say go for it. 



- thomas



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Composition commit and change types

[pablo pazos]

I agree with that, rephrasing, this "delta mode" would be just an API 
*feature*. Also both modes full and delta can be supported by the same API, 
with the same results when querying data back. This might not be part of a 
generic API spec, but more a concrete ITS.
I think especially for persistent compos, the delta mode is smarted than the 
full revision, and with a little thought/design, might be as safer as the full 
revision.
I'll put this idea in my icebox, since my user base is growing, in the near 
future I can send a survey to them to see if this might make their life easier. 
I won't write a line of code for this until I have a change request, and I'm 
sure this doesn't complicate other features.
Either way, it would be useful to have input from commercial implementers about 
if they support something like this, and  also about the original issue
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

> From: i...@freshehr.com
> Date: Mon, 4 Apr 2016 21:12:00 +0100
> Subject: Re: Composition commit and change types
> To: openehr-technical@lists.openehr.org
> 
> Hi Pablo,
> 
> I think there are lots of interesting approaches (though potentially
> challenging in complex environments) but I would definitely want to
> handle the question of 'diffs or not' behind the service layer. As a
> consumer I just want to be sure that the current composition
> accurately reflects changes made. Full revision is a bit dumb but it
> is safe!
> 
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
> 
> On 4 April 2016 at 20:18, pablo pazos <pazospa...@hotmail.com> wrote:
> > I think that can work for some implementations.
> >
> > What I was thinking is not adding parts to an existing compo, but to commit
> > a full COMPO, just with the changes. That means, the newObject would be a
> > COMPOSITION or even a VERSION. If this is for the Problem List, to add a new
> > one, the COMPO will have just one EVALUATION with the new problem. If commit
> > mode is "delta", the backend will do what it needs to reflect that addition
> > to the current Problem List. If the commit mode is "full", that means one
> > problem was added and the rest removed.
> >
> > IMO this can use the same commit(VERSION[] versions, AUDIT_DETAILS audit)
> > adding a String mode param or adding another operation
> > commit_delta(VERSION[] versions, AUDIT_DETAILS audit).
> >
> > For my implementation all commits are for completed COMPOS, the API you
> > described might allow partial updates to already committed COMPOS, and I
> > don't think delta commit should imply partial updates. Delta is just to
> > commit a completed COMPO but without the need of replicating all the
> > information that hasn't changed. The backend can create the full compo
> > internally, that would not be an issue.
> >
> > Also, that is related with the initial issue: detecting individual changes
> > to persistent COMPOS. Sending just the changes, allows to identify those
> > with the user responsible for the changes, so it is easier to create lists
> > of problems, medications, etc. per user or organization, even if internally
> > that is stored in one singleton VERSIONED_COMPO. per persistent archetype.
> >
> > Consider this is only for my implementation, I'm not looking for defining
> > this for the official openEHR API, but can help as input. I want to double
> > check my criteria with other implementers before implementing anything :)
> >
> > --
> > Kind regards,
> > Eng. Pablo Pazos Gutiérrez
> > http://cabolabs.com
> >
> > 
> > Subject: Re: Composition commit and change types
> > To: openehr-technical@lists.openehr.org
> > From: thomas.be...@openehr.org
> > Date: Mon, 4 Apr 2016 19:50:50 +0100
> >
> >
> >
> >
> > On 04/04/2016 19:14, pazospa...@hotmail.com wrote:
> >
> > Hi Thomas,
> >
> >
> > What about having the 'delta' mode just at the API level? Storage might not
> > store delta objects, just full objects, but the API allows to send only what
> > was added, modified or deleted instead of the full compo?
> >
> >
> > then you have a transactional concept, i.e. 'add', 'remove', 'modify' etc...
> > so for me the better way to think about it isn't in terms of data structures
> > but in terms

RE: Secure EPD

[pablo pazos]

Great info, thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

> To: openehr-technical@lists.openehr.org
> From: bert.verh...@rosa.nl
> Subject: Secure EPD
> Date: Thu, 21 Apr 2016 09:08:23 +0200
> 
> Hi,
> 
> I don't know if it is interesting for this forum, and if medical 
> information designers should be busy with this, but since, f.e. FHIR is 
> involved in incorporating technical layers, like REST and authorization 
> and authentication, in an information standard, I think there is to come 
> some connection between security and information-design.
> 
> In my idea, this is not a desirable direction, but it looks like we are 
> going that way.
> 
> "[Medical devices] are all running Windows XP or XP service pack two … 
> and probably don't have antivirus because they are critical systems."
> http://www.theregister.co.uk/2016/02/25/patient_monitors_altered_drug_dispensary_popped_in_collosal_hospital_hack/
> 
> The 71-page document is the latest, and one of the most comprehensive, 
> research efforts in the field of medical hacking, and paints a bleak 
> picture of the state of security in hospitals So, maybe it is an 
> interesting document to read. If not, just forget about it.
> 
> https://securityevaluators.com/hospitalhack/securing_hospitals.pdf
> 
> Best regards
> Bert Verhees
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Do you know of any new openEHR projects?

[pablo pazos]

Hi Thomas,

EHRGen (generator of openEHR EMRs) and EHRServer (openEHR service-oriented 
backend) are different projects, I think both should be on that page. Also I 
have many EHRServer client libs in java, js, php and .net, will polish the code 
a little and send you the info.

For the EHRServer the paragraph would be:

EHRServer is an open source, service�\oriented, openEHR clinical data 
repository. It provides a secure REST API to store and query clinical data in 
many ways, supporting standard formats like JSON and XML, that are easy to 
integrate with any front�\end application. Data queries can be created via the 
Administrative User Interface, with the powerful and easy to use EHRServer 
Query Builder. EHRServer complies with the openEHR specifications , leveraging 
the openEHR Information Model and the Dual Modeling methodology, using standard 
Archetypes and Templates.

Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: Do you know of any new openEHR projects?
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Tue, 26 Jul 2016 13:43:20 +0100


  

  
  




Pablo,

sorry for the delay, I missed seeing this post. See the page here
  - should I replace 'open EHR-gen' with 'EHRServer'? And also
  replace the google code links with the cabolabs link (which is
  certainly better in my view)? Also do you want to supply a single
  paragraph text for he 'Description' column that has a few more
  words than we currently have there?

thanks

- thomas





On 13/07/2016 02:59, pablo pazos wrote:



  
  Hi Thomas, this one is missing: the EHRServer 
http://cabolabs.com/en/projects



Is foss and Apache 2. Let me know if you need more info!



-- 

Kind regards,

Eng. Pablo Pazos Gutiérrez

http://cabolabs.com




  To: openehr-technical@lists.openehr.org;
  openehr-clini...@lists.openehr.org

  From: thomas.be...@openehr.org

  Subject: Do you know of any new openEHR projects?

  Date: Tue, 12 Jul 2016 18:51:42 +0100

  

  

  We have updated the EHR System Components page with some of
  the newer projects we know about. This page doesn't include
  the commercial products from the vendor pages (maybe it should? 
Opinions
  welcome).

  

  Do you know of other projects - open source or other? Do you
  have more details for the above page?

  

  You can provide information on the lists or by commenting on this 
issue.

  

  - thomas

  

  ___
  openEHR-technical mailing list
  openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
  
  

  
  

  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



-- 

  

  



Thomas Beale

  Management Board, Specifications Program Lead, openEHR Foundation

  Chartered IT Professional Fellow, BCS, British Computer
Society

  Health IT blog Culture blog
  

  
  


  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: initial states for instructions / when do we need actions?

[pablo pazos]

yes I will, BTW there is another conversation that is related to this and to 
improving the specs, the subject is: "ACTIVITY.description vs 
ACTION.description archetypes‏"

if anyone can take a look at it, would be helpful.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: initial states for instructions / when do we need actions?
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Thu, 14 Jul 2016 08:25:53 +0100


  

  
  




Hi Pablo

can you raise a PR for this, with some summary of the changes you
  think are needed?

thanks

- thomas





On 14/07/2016 05:16, pablo pazos wrote:



  
  Hi Heath, thanks for taking the time to answer,
this is really useful and I think your comments should be
included in the specs as examples of how the instruction/action
interaction and the effect of that interaction on the ISM should
work.



First it makes total sense for me to have INITIAL as the current
state when no ACTION was recorded for the INSTRUCTION. And it
also makes sense to include a "placeholder" ACTION (might not
have much info but the next state) for INSTRUCTIONS that need to
be on PLANNED when the INSTRUCTION is created (like the
medication case).



About 3.1 I was thinking of a case where the event of creating
the INSTRUCTION also includes the coordination/scheduling of
ACTIONs that will be performed. I think this is just another
case of my previous paragraph: we need an ACTION to change the
state to SCHEDULED.



Thanks a lot!



-- 

Kind regards,

Eng. Pablo Pazos Gutiérrez

http://cabolabs.com



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: initial states for instructions / when do we need actions?

[pablo pazos]

Hi Etienne, did you checked the ISM specs? I think the flow phases you mention 
are mappable to the current states of the ISM.

Also consider this conversation is about INSTRUCTION handling, not ACTION 
handling, ACTIONs are used to modify the state of the INSTRUCTION/ACTIVITY.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: etie...@saliez.be
To: openehr-technical@lists.openehr.org
Subject: Re: initial states for instructions / when do we need actions?
Date: Fri, 22 Jul 2016 19:35:12 +0200
CC: openehr-clini...@lists.openehr.org; s...@lists.openehr.org



 
 
Thank you very much for the schema.
 
However I believe that the handling of an Action should start earlier before 
the "INITIAL" state.
 
- "SUGGESTED"
Preliminary informal suggestion, according to some generic guidelines, 
regardless of the details of the current context of the patient
 
- "POROPSED"
It could be useful to record temporarily proposals by student, junior assistant 
or nurse, or simply when a staff member is considering some action while 
waiting on more information from the lab.
Nothing yet done, but information could be useful to be recorded temporarily as 
an element of discussion.
 
- "VALIDATED"
The decision for he action is confirmed by an authorised member of the staff.
Although not yet scheduled.
The author of an order is also responsible to specify a time range, from "very 
urgent" to "to be done within on month".
If the time would have been outdated the order should be reevaluated.
 
- etc as on the schema .
 
- "STARTED"
For example a treatment for 10 days is actually started. 
Or a bacteriology test which necessitate at least 24 hours.
 
"COMPLETED"
Completely executed.
In priciple a conclusion is expected.
 
 
Etienne Saliez
 
 
On Wednesday, 13 July 2016 00:28:54 CEST Heath Frankel wrote:
> Hi Pablo,
> Some comments below.
> 
> Heath
> 
> From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
> On Behalf Of pablo pazos Sent: Tuesday, 12 July 2016 12:29 PM
> To: openeh technical <openehr-technical@lists.openehr.org>; openehr clinical
> <openehr-clini...@lists.openehr.org>; s...@lists.openehr.org Subject: ISM:
> initial states for instructions / when do we need actions?
> 
> Hi all,
> 
> This message is related to my previous message "ACTIVITY.description vs
> ACTION.description archetypes‏" (didn't got any answers :( but this is
> focused on when we need actions to change a instruction state, and what's
> the initial state.
> 
> Considering the specs:
> http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_the_standard_in
> struction_state_machine_ism
> 
> I think when an instruction is firstly recorded, it should have a state. But
> I'm not 100% if that state should be INITIAL, or can also be PLANNED,
> SCHEDULED or ACTIVE, since at least for SCHEDULED and ACTIVE I think we
> need an ACTION to be recorded to trigger the transition, but it is not
> clear that we need that to trigger the transition "initiate (INITIAL ->
> PLANNED)".
> 
> [HKF: ] I personally consider the Initial state as your standard state
> diagram starting point rather than a usable state. The AE has allowed the
> initial state to be used, which I think is incorrect and we translate this
> to a subsequent state for real use.
> 
> 1- Is INITIAL the state associated with an instruction when no action is
> recorded?
> 
> [HKF: ] This is how I consider this. In fact I usually explain to my
> developers that an instruction is not initiated unless there is an action
> to start the instructions workflow. Without an action, it is just a
> definition of an instruction that is waiting to have its workflow started.
> 
> 2- If what it's recorded is a medication prescription, I guess the initial
> state should be PLANNED, do we need to record an action alongside with the
> instruction to make the "initiate (INITIAL -> PLANNED)" transition? OR, we
> can just set the initial state to PLANNED, even though no actions are
> recorded for the instruction/activity?
> 
> [HKF: ] As indicated, I would have an ACTION with a PLANNED state to make
> this clear. You may choose to go straight to Active.
> 
> 3- On the case of recording a treatment that should be scheduled, do we also
> need an action to trigger the "schedule (INITIAL -> SCHEDULED)" transition?
> (I guess yes if the instruction is created at one time, and the schedule
> comes later).
> 
> [HKF: ] As above.
> 
> 3.1- If yes, what happens on the case the instruction includes scheduling?
> Should we include an action to trigger the transition or can we set the
> state to SCHEDULED directly?
&g

Issues with OPT exported from the Template Designer: different attribute ordering than the openEHR XSD

[pablo pazos]

Hi,

I'm working on a small COMPOSITION generation service that will generate valid 
openEHR instances in XML, providing an OPT.

Playing around with some tests, I detected the Template Designer exports the 
attributes of the INSTRUCTION in a different order than the specified by the 
openEHR XSD. The OPT has "activities" before "protocol", and in the XSD those 
are in the inverse order.

I'm not sure if this is a bug in the TD or if we shouldn't expect the OPT to 
have the same attribute ordering as the one defined in the XSD.

If this is a bug, I will raise it in JIRA. Just wanted to confirm firm.

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Shouldn't INSTRUCTION_DETAILS.wf_details be archetypable?

[pablo pazos]

Thanks Heath, I was under the impression that this was an AE constraint.

I know the tool has it's restrictions and I would love to contribute, but I'm 
not very good with the technology stack on which the AE was created. I hope 
others can jump in and fill the blanks :)

Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: openehr-technical@lists.openehr.org; openehr-clini...@lists.openehr.org; 
s...@lists.openehr.org
Subject: RE: Shouldn't INSTRUCTION_DETAILS.wf_details be archetypable?
Date: Wed, 13 Jul 2016 00:15:09 +









Hi Pablo,
Since wf_details is ITEM_STRUCTURE, then yes it can be archetyped. Just because 
the AE doesn’t support it does not change this fact.
 As is this case in many software projects, functionality in the AE was built 
on as needed basis so I would suggest that no one has needed it to date. Since 
the AE was almost 100% contributed by Ocean Informatics, the priorities around 
“as needed” was evaluated
 by Ocean. However, the AE is open source so others can add their own 
capabilities if they desire.

 
Heath
 


From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of pablo pazos

Sent: Tuesday, 12 July 2016 2:36 PM

To: openeh technical <openehr-technical@lists.openehr.org>; openehr clinical 
<openehr-clini...@lists.openehr.org>; s...@lists.openehr.org

Subject: Shouldn't INSTRUCTION_DETAILS.wf_details be archetypable?


 

Looking at the model, INSTRUCTION_DETAILS.wf_details is an ITEM_STRUCTURE, and 
that lead me to think that should be archetypable.

 


Playing around with the archetype editor, it doesn't allow to archetype 
anything inside INSTRUCTION.instruction_details.


 


Is this a problem of the AE or that structure is not meant to be archetyped?


 


If it is not meant to be archetyped, wouldn't that be an issue for querying?


 


Thanks!



-- 

Kind regards,

Eng. Pablo Pazos Gutiérrez

http://cabolabs.com






___
openEHR-clinical mailing list
openehr-clini...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Do you know of any new openEHR projects?

[pablo pazos]

Hi Thomas, this one is missing: the EHRServer http://cabolabs.com/en/projects

Is foss and Apache 2. Let me know if you need more info!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

To: openehr-technical@lists.openehr.org; openehr-clini...@lists.openehr.org
From: thomas.be...@openehr.org
Subject: Do you know of any new openEHR projects?
Date: Tue, 12 Jul 2016 18:51:42 +0100


  


  
  


We have updated the EHR System
  Components page with some of the newer projects we know about.
This page doesn't include the commercial products from the vendor pages
(maybe it should? Opinions welcome).



Do you know of other projects - open source or other? Do you have
more details for the above page?



You can provide information on the lists or by commenting on this issue.



- thomas

  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

ISM: initial states for instructions / when do we need actions?

[pablo pazos]

Hi all,

This message is related to my previous message "ACTIVITY.description vs 
ACTION.description archetypes‏" (didn't got any answers :( but this is focused 
on when we need actions to change a instruction state, and what's the initial 
state.

Considering the 
specs:http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_the_standard_instruction_state_machine_ism

I think when an instruction is firstly recorded, it should have a state. But 
I'm not 100% if that state should be INITIAL, or can also be PLANNED, SCHEDULED 
or ACTIVE, since at least for SCHEDULED and ACTIVE I think we need an ACTION to 
be recorded to trigger the transition, but it is not clear that we need that to 
trigger the transition "initiate (INITIAL -> PLANNED)".


1- Is INITIAL the state associated with an instruction when no action is 
recorded?


2- If what it's recorded is a medication prescription, I guess the initial 
state should be PLANNED, do we need to record an action alongside with the 
instruction to make the "initiate (INITIAL -> PLANNED)" transition? OR, we can 
just set the initial state to PLANNED, even though no actions are recorded for 
the instruction/activity?

3- On the case of recording a treatment that should be scheduled, do we also 
need an action to trigger the "schedule (INITIAL -> SCHEDULED)" transition? (I 
guess yes if the instruction is created at one time, and the schedule comes 
later).
3.1- If yes, what happens on the case the instruction includes scheduling? 
Should we include an action to trigger the transition or can we set the state 
to SCHEDULED directly?

At least for me this is not 100% on the specs. If this happens to others, we 
might need to improve the specs and add more examples to make this topic clear 
for newcomers.
Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Shouldn't INSTRUCTION_DETAILS.wf_details be archetypable?

[pablo pazos]

Looking at the model, INSTRUCTION_DETAILS.wf_details is an ITEM_STRUCTURE, and 
that lead me to think that should be archetypable.
Playing around with the archetype editor, it doesn't allow to archetype 
anything inside INSTRUCTION.instruction_details.
Is this a problem of the AE or that structure is not meant to be archetyped?
If it is not meant to be archetyped, wouldn't that be an issue for querying?
Thanks!

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

ACTIVITY.description vs ACTION.description archetypes

[pablo pazos]

I'm reviewing the current version of the specs and remembered an issue we had 
in the past about this (check the bold text)

8.2.5.7. Relationship to Archetypes

Much of the semantics of particular Instructions and Actions derive 
from archetypes. Currently, archetypes are used to define two groups of 
Instruction semantics. The first is the descriptions of activities that 
are defined in Instructions (ACTIVITY.description) and executed in Actions 
(ACTION.description).
 These descriptions are always of the same form for any given 
Instruction, and it is highly desirable to have the same archetype 
component for both.  An example is where the description is of a medication, 
commonly 
consisting of a tree or list of ten or more elements describing the 
drug, its name, form, dose, route and so on. 


ref: 
http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_careflow_process_to_state_machine_mapping






1. I mentioned in other thread that current specs about INSTRUCTIONS are too 
focused on medication cases, but not on treatments, non-drug therapies, 
procedures, etc.


I would suggest to add more examples to the spec that are not related with 
medication, and ask the collaboration of the clinical colleagues on that area. 
I'm sure you can come up with very good examples we can include on the 
specifications.




2. On those non-medication related cases of INSTRUCTION/ACTIVITY and ACTION 
modelling I'm not sure if this is true "These descriptions are always of the 
same form for any given 
Instruction".


This is a very hard assessment that doesn't leave much modelling options. I as 
an informatician can come up with some examples where that is not true, and I'm 
sure clinical people can have better examples:


a. For physiotherapy: I had 10 sessions of laser treatment ordered by my 
physiatrist. This is scheduled as an administrative process. On each session, 
the physiotherapist needs to complete a form marking each ordered service as 
"done" and sign. After the last session, the order (instruction) is completed 
and that can be done automatically, because the start and end date are 
established on the schedule.



On this case, the records (ACTION) created on each session have different 
structure as the ones on the order, the only dependency from the ACTION to the 
ACTIVITY, is to the ID of the specific ACTIVITY. The ACTION's descriptions 
don't need to have the same structure as the ACTIVITY description.




b. Hemodialysis: I have worked on this area some time ago, patients are ordered 
hemodialysis as a long term treatment in some cases, or while waiting for a 
kidney transplant on other cases. The order is the treatment, 


The record of each session has a very strict protocol and every detail of it is 
recorded. That has a very specific structure that would be modelled as a whole 
COMPOSITION, but include an ACTION to represent a treatment executed for a 
medical order. I would say 99% of the documentation of the hemodialysis session 
will be on OBSERVATIONS, EVALUATIONS and ADMIN_ENTRY, and the ACTION would be 
just a log of the sessions occurrence, saving the relationship to the 
INSTRUCTION/ACTIVITY that ordered the treatment. Again I don't see that ACTION 
description to be equal in structure to the ACTIVITY description or the order 
for the treatment.


c. Surgical procedure: a traumatologist surgeon ordered an arthroscopic knee 
surgery to fix my meniscus. The INSTRUCTION included the procedure to be 
executed, and some indications for me. The procedure record was a complete 
COMPOSITION with all the details, and as in previous cases, the ACTIONs were 
related to the indication of "in progress" and later "completed" procedure.

I also don't see the structures of ACTIVITY.description and ACTION.description 
match on this case.


Sorry for the long email, but this has been a long term issue for me.

Please let me know if something of this makes sense, or not :)
If it does, I would propose to relax the specs descriptions a little and add 
non medication related examples.

Clinical modellers input would be more than welcome!


-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com   ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Creating archetypes with alternatives

[Pablo Pazos]

Hi,

I'm testing the EHRServer with alternative datatypes for the same
ELEMENT.value.

I found the only way of doing that in the Archetype Editor is by setting
the node as Any. And there is no way to further constraint the allowed
datavalues in the AE.

In the Template Designer I can further constraint that by specifying which
specific types can be used, to avoid the possibility of allowing any
datavalue to be there. The problem I found is that after setting the
allowed datavalues, I can't set constraints for them, e.g. if I specify
Coded Text, I can't set the code list.

Shouldn't the datatype constraints be set also on the AE and the
constraints per allowed datavalue allowed to be set on the AE and TD?

I've seen some ADLs/OPTs from Brazil with alternatives, and I don't know if
they are using another AE/TD or just setting the constraints by hand. For
example a problem status archetypes has this which I can't reproduce in the
Ocean's AE:

ELEMENT[at0082] occurrences matches {0..*} matches {--
Unspecified
value matches {
DV_TEXT matches {*}
DV_BOOLEAN matches {
value matches {True, False}
}
DV_COUNT matches {*}
}
}


Thanks!

-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Creating archetypes with alternatives

[Pablo Pazos]

Thanks Peter,

The Choice worked as expected in the AE, but there is an issue with the TD.

I was able to set CODED TEXT, COUNT and DATE TIME, and set constraints to
them like this:

ELEMENT[at0005] occurrences matches
{0..1} matches {-- choice
value matches {
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0006, -- 11
at0007, -- 22
at0008]-- 33
}
}
DV_COUNT matches {
magnitude matches {|0..500|}
}
DV_DATE_TIME matches {*}
}
}


The problem is when I export OPTs using that archetype, all the constraints
are gone, for example, I created a template that only allows CODED TEXT,
and the result is this (no codes in the code list of the CODE_PHRASE):


DV_CODED_TEXT

  true
  true
  false
  false
  1
  1



  defining_code
  
true
true
false
false
1
1
  
  
CODE_PHRASE

  true
  true
  false
  false
  1
  1



  openehr

433
  

  



On Wed, Feb 8, 2017 at 9:25 PM, Peter Gummer <peter.gum...@gmail.com> wrote:

> Hi Pablo,
>
> The way to produce the ADL that you’ve posted below is with a “Choice”
> element.
>
> 1. Go to the Archetype Editor’s “Definition” tab.
> 2. Click the [+] button on the left.
> 3. From the drop-down list, select “New element” and “Choice”.
> 4. Over on the right of the screen, you will see two buttons, [+] and [-].
> Click the [+] button and select “Text”.
> 5. Repeatedly click the [+] button to add all of the data types that will
> be permitted in this element.
>
> Hope that helps,
> Peter
>
>
> > On 9 Feb 2017, at 10:52, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> >
> > Hi,
> >
> > I'm testing the EHRServer with alternative datatypes for the same
> ELEMENT.value.
> >
> > I found the only way of doing that in the Archetype Editor is by setting
> the node as Any. And there is no way to further constraint the allowed
> datavalues in the AE.
> >
> > In the Template Designer I can further constraint that by specifying
> which specific types can be used, to avoid the possibility of allowing any
> datavalue to be there. The problem I found is that after setting the
> allowed datavalues, I can't set constraints for them, e.g. if I specify
> Coded Text, I can't set the code list.
> >
> > Shouldn't the datatype constraints be set also on the AE and the
> constraints per allowed datavalue allowed to be set on the AE and TD?
> >
> > I've seen some ADLs/OPTs from Brazil with alternatives, and I don't know
> if they are using another AE/TD or just setting the constraints by hand.
> For example a problem status archetypes has this which I can't reproduce in
> the Ocean's AE:
> >
> > ELEMENT[at0082] occurrences matches {0..*} matches {--
> Unspecified
> > value matches {
> > DV_TEXT matches {*}
> > DV_BOOLEAN matches {
> > value matches {True, False}
> > }
> > DV_COUNT matches {*}
> > }
> > }
> >
> >
> > Thanks!
> >
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org




-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Creating archetypes with alternatives

[Pablo Pazos]

I copied the wrong CODED TEXT from the OPT, the node that has the code list
in the ADL but doesn't in the OPT, don't include the CODE PHRASE node:

  
DV_CODED_TEXT

  true
  true
  false
  false
  1
  1


  

On Wed, Feb 8, 2017 at 11:59 PM, Pablo Pazos <pablo.pa...@cabolabs.com>
wrote:

> Thanks Peter,
>
> The Choice worked as expected in the AE, but there is an issue with the TD.
>
> I was able to set CODED TEXT, COUNT and DATE TIME, and set constraints to
> them like this:
>
> ELEMENT[at0005] occurrences matches
> {0..1} matches {-- choice
> value matches {
> DV_CODED_TEXT matches {
> defining_code matches {
> [local::
> at0006, -- 11
> at0007, -- 22
> at0008]-- 33
> }
> }
> DV_COUNT matches {
> magnitude matches
> {|0..500|}
> }
> DV_DATE_TIME matches {*}
> }
> }
>
>
> The problem is when I export OPTs using that archetype, all the
> constraints are gone, for example, I created a template that only allows
> CODED TEXT, and the result is this (no codes in the code list of the
> CODE_PHRASE):
>
> 
> DV_CODED_TEXT
> 
>   true
>   true
>   false
>   false
>   1
>   1
> 
> 
> 
>   defining_code
>   
> true
> true
> false
> false
> 1
> 1
>   
>   
> CODE_PHRASE
> 
>   true
>   true
>   false
>   false
>   1
>   1
> 
> 
> 
>   openehr
> 
> 433
>   
> 
>   
>
>
>
> On Wed, Feb 8, 2017 at 9:25 PM, Peter Gummer <peter.gum...@gmail.com>
> wrote:
>
>> Hi Pablo,
>>
>> The way to produce the ADL that you’ve posted below is with a “Choice”
>> element.
>>
>> 1. Go to the Archetype Editor’s “Definition” tab.
>> 2. Click the [+] button on the left.
>> 3. From the drop-down list, select “New element” and “Choice”.
>> 4. Over on the right of the screen, you will see two buttons, [+] and
>> [-]. Click the [+] button and select “Text”.
>> 5. Repeatedly click the [+] button to add all of the data types that will
>> be permitted in this element.
>>
>> Hope that helps,
>> Peter
>>
>>
>> > On 9 Feb 2017, at 10:52, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
>> >
>> > Hi,
>> >
>> > I'm testing the EHRServer with alternative datatypes for the same
>> ELEMENT.value.
>> >
>> > I found the only way of doing that in the Archetype Editor is by
>> setting the node as Any. And there is no way to further constraint the
>> allowed datavalues in the AE.
>> >
>> > In the Template Designer I can further constraint that by specifying
>> which specific types can be used, to avoid the possibility of allowing any
>> datavalue to be there. The problem I found is that after setting the
>> allowed datavalues, I can't set constraints for them, e.g. if I specify
>> Coded Text, I can't set the code list.
>> >
>> > Shouldn't the datatype constraints be set also on the AE and the
>> constraints per allowed datavalue allowed to be set on the AE and TD?
>> >
>> > I've seen some ADLs/OPTs from Brazil with alternatives, and I don't
>> know if they are using another AE/TD or just setting the constraints by
>> hand. For example a problem status archetypes has this which I can't
>> reproduce in the Ocean's AE:
&

Re: INFORMATION ABOUT THE SYSTEM

[Pablo Pazos]

Hi,

openEHR is a specification, not a software system.

There are many implementations. Like
https://github.com/ppazos/cabolabs-ehrserver

Regards,
Pablo.

On Tue, Feb 21, 2017 at 3:43 PM, STAMATAKI-LOUKATOU GERASIMOULA <
gstam...@uth.gr> wrote:

> Good evening,
>
> I am a postgraduate student in Bioinformatics and it may seem stupid but I
> would like to ask you a few questions about openEHR , as I was unable to
> find or understand them.
>
> What database openEHR uses and what programming language?
> Is it possible to alter the schema in order to fit to my needs?
>
> Thank you in advance,
> Mema Stamataki.
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: More generic reference model

[pablo pazos]

Hi Bert,


I was thinking about integrating SCT with path-based queries (I'm not in AQL 
yet), but maintaining the complexity of the SCT relationships and expressions 
on the terminology service (TS) side, so on queries there are just simple codes 
(specific concept ids, subsets or expressions identified just by one code). 
Then when evaluating a query, with the TS we can get all the terms and concept 
ids that match all the is_a relationships or subsets of expressions. I talked 
with several TS providers and hopefully we can build an integration next year 
to create and evaluate queries with SCT.


What I'm saying is that I prefer to delegate the complexity of SCT to the TS 
and create simpler queries in AQL or path-based queries, but your idea is 
interesting. One problem though is that query creators need to be experts in 
SCT.


What do you think?


Sent from my LG Mobile

-- Original message--

From: Bert Verhees

Date: Sat, Sep 10, 2016 13:14

To: For openEHR technical discussions;

Subject:Re: SV: More generic reference model

Hi Pablo, sorry I was bit slow with thinking through my plans. The way I see it 
now, there is no change necessary in the reference model to integrate the 
potential of SCT largely. Even you can keep on using the semantic rich entry 
types like Observation, etc.

See my post in my blog.
http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

If you, however, limit yourself to the Generic entry type, which even gives a 
better integration while keeping all OpenEhr functinality alive.

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/

I am interested in what you think about that.

Best regards
Bert Verhees

Op 10 sep. 2016 05:03 schreef "pablo pazos" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>>:

Hi all,


Regarding the genericity of the openEHR IM, from the implementation point of 
view we have at least 3 models:


+ the implementation information model

+ the persistence information model

+ and the reference / canonic information model (the openEHR IM)


Others might have more than these 3 models on their openEHR implementations.


I think some simplifications can still be done to the openEHR IM without losing 
semantics, like removing ITEM_STRUCTURE and using just CLUSTER/ELEMENT (we have 
a discussion about this on the wiki started some years ago).


IMO we should not try to make the reference model simpler just in sake of 
simplifying the implementation, since the other 2 models are for that. In my 
systems I have different implementation models that are over simplified openEHR 
IM implementations, and also very specific / optimized / generic persistence 
information models compatible with the openEHR IM. And I think the 
implementation / persistence models are the ones we can simplify and adjust to 
our needs, but not the reference model, since it's role is that: be the 
reference for all implementations.



--
Kind regards,
Eng. Pablo Pazos Guti??rrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Mikael Nyström 
<mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>>
Sent: Friday, September 9, 2016 4:15:53 AM
To: For openEHR technical discussions
Subject: SV: SV: More generic reference model

Hi,

A related activity that might be useful to know is the “RFP for LOINC - SNOMED 
CT Cooperation 
Project”.http://www.ihtsdo.org/news-articles/rfp-for-loinc--snomed-ct-cooperation-project
 .

 Regards
 Mikael

Från: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]För
 Bert Verhees
Skickat: den 9 september 2016 08:42
Till: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Ämne: Re: SV: More generic reference model

Op 9-9-2016 om 8:37 schreef Bjørn Næss:
But in addition to that we need to map terms from different other terminologies 
like SNOMED-CT, LOINC and also Disease Ontologies.

There is a mapping effort by IHTSDO en Regenstrief, they started that a few 
years ago, and it will be finished, next year, I think.

http://www.ihtsdo.org/about-ihtsdo/partnerships/loinc

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: How can I model multiple checkboxs options with terminology?

[pablo pazos]

You are right, this might be one of those cases that should be solved by 
software.


Sent from my LG Mobile

-- Original message--

From: Bert Verhees

Date: Sun, Sep 11, 2016 01:35

To: For openEHR technical discussions;

Subject:Re: How can I model multiple checkboxs options with terminology?

Hi Pablo, good solution, I think it is a better solution then mine, the only 
problem is that it allows more times the same selection, isn't it? Because you 
can let occur a DvCodedText more then once in an Element, but you cannot define 
it more then once. Maybe more elements with all one DvCodedText and with all 
have only one (but different) code to select, and have an occurrence of 
optional 0..1..

I think OpenEhr should solve this by creating a new datatype.. What do you 
think?

Op 11 sep. 2016 04:14 schreef "pablo pazos" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>>:

Use a coded text element with occurrences > 1


Sent from my LG Mobile

-- Original message--

From: Tiago Santos da Silva

Date: Sat, Sep 10, 2016 16:38

To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>;

Subject:How can I model multiple checkboxs options with terminology?

Hi,

Can anyone tell how I can model the example below?

"What parts of the body hurt? [ ] right leg [ ] left leg [ ] head [ ] right arm 
.."

I know to model a single option (radio-buttom) but I don't know to model a 
multiple options (checkbox)

The idea is that the options are of the terminology, so I can't model right in 
the archetype.

I'm using the key-path  strategy for data persistence. In the case of the 
radiobutton leaf is a DV_CODED_TEXT but I don't know when use checkbox.

Note: English is not my native language I hope it is clear the doubt.

Thank you!

--
Abs,
Tiago Santos da Silva
===
+55 21 3938-8688 /+55 21 97556-9840<tel:+55%2021%2097556-9840>
CAPGov - Centro de Apoio a Politicas de Governo
COPPE Sistemas / Universidade Federal do Rio de Janeiro

COPPE: 50 ANOS ANTECIPANDO O FUTURO

Arquiteto de Software
Doutorando em Engenharia de Sistemas e Computação (PESC/UFRJ)
Mestre em Engenharia de Sistemas e Computação (PESC/UFRJ)

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: SV: More generic reference model

[pablo pazos]

IMHO the clearness of the query should not depend on the AQL code, but the 
metadata associated with the query, like the ADL header and ontology, the AQL 
would be the "definition" of the query. To share queries between systems the 
AQL is not enough. We need a declaration of intent, purpose, use, misuse, etc 
and description of the query in natural language.


Also, to manage queries we need something like the CKM and an editor.  Good AQL 
should not rely only on clearness and readability, but on specifying exactly 
what results we need.


I think both options are valid: SCT expressions and just codes in AQL, but 
since I'm not an expert in SCT, I prefer someone else that knows SCT defines 
the expressions and relationships in the terminology server so I can create 
queries just using codes.


Sent from my LG Mobile

-- Original message--

From: Diego Boscá

Date: Sun, Sep 11, 2016 11:57

To: For openEHR technical discussions;

Subject:Re: SV: More generic reference model

I'm not a real fan of having just codes instead of expressions.. Expressions 
are far more readable and may help in the understanding of the archetype. Just 
a single code representing the subset won't be as clear.

El 11/9/2016 16:49, "pablo pazos" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>> escribió:

Hi Bert,


I was thinking about integrating SCT with path-based queries (I'm not in AQL 
yet), but maintaining the complexity of the SCT relationships and expressions 
on the terminology service (TS) side, so on queries there are just simple codes 
(specific concept ids, subsets or expressions identified just by one code). 
Then when evaluating a query, with the TS we can get all the terms and concept 
ids that match all the is_a relationships or subsets of expressions. I talked 
with several TS providers and hopefully we can build an integration next year 
to create and evaluate queries with SCT.


What I'm saying is that I prefer to delegate the complexity of SCT to the TS 
and create simpler queries in AQL or path-based queries, but your idea is 
interesting. One problem though is that query creators need to be experts in 
SCT.


What do you think?


Sent from my LG Mobile

-- Original message--

From: Bert Verhees

Date: Sat, Sep 10, 2016 13:14

To: For openEHR technical discussions;

Subject:Re: SV: More generic reference model

Hi Pablo, sorry I was bit slow with thinking through my plans. The way I see it 
now, there is no change necessary in the reference model to integrate the 
potential of SCT largely. Even you can keep on using the semantic rich entry 
types like Observation, etc.

See my post in my blog.
http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

If you, however, limit yourself to the Generic entry type, which even gives a 
better integration while keeping all OpenEhr functinality alive.

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/

I am interested in what you think about that.

Best regards
Bert Verhees

Op 10 sep. 2016 05:03 schreef "pablo pazos" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>>:

Hi all,


Regarding the genericity of the openEHR IM, from the implementation point of 
view we have at least 3 models:


+ the implementation information model

+ the persistence information model

+ and the reference / canonic information model (the openEHR IM)


Others might have more than these 3 models on their openEHR implementations.


I think some simplifications can still be done to the openEHR IM without losing 
semantics, like removing ITEM_STRUCTURE and using just CLUSTER/ELEMENT (we have 
a discussion about this on the wiki started some years ago).


IMO we should not try to make the reference model simpler just in sake of 
simplifying the implementation, since the other 2 models are for that. In my 
systems I have different implementation models that are over simplified openEHR 
IM implementations, and also very specific / optimized / generic persistence 
information models compatible with the openEHR IM. And I think the 
implementation / persistence models are the ones we can simplify and adjust to 
our needs, but not the reference model, since it's role is that: be the 
reference for all implementations.



--
Kind regards,
Eng. Pablo Pazos Guti??rrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>

From: openEHR-technical 
<openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Mikael Nyström 
<mikael.nyst...@liu.se<mailto:mikael.nyst...@liu.se>>
Sent: Friday, September 9, 2016 4:15:53 AM
To: For openEHR technical discussions
Subject: SV: SV: More generic reference model

Hi,

A related activity that might be useful to know is the “RFP for LOINC - SNOMED 
CT Cooperation 
Proje

Re: SV: More generic reference model

[pablo pazos]

I understand the point,  and it makes perfect sense talking about a general 
solution.


But it also depends on the scope. Consider a nationwide project where 
terminologies are defined and subsets / expressions can be defined in a 
controlled way. In this context my approach would not be a problem. Even   if 
local codes are defined, those can be post coordinated / harmonized, and only 
those codes can be part of queries (I can imagine such rule in a real 
situation, maybe as part of a querying guideline).


Without considering context and scope, this is a thought problem to solve in a 
general way, but with each conversation we get closer to a solution, this is a 
great exercise.


Sent from my LG Mobile

-- Original message--

From: Diego Boscá

Date: Sun, Sep 11, 2016 15:33

To: For openEHR technical discussions;

Subject:Re: SV: More generic reference model

I mean, I can see that there can be valid queries to known terminologyservices, 
I'm not against that. In practical terms however, you can'talways expect to 
have all the access that you want to a given externalservice. e.g. I was banned 
from W3C once for launching atransformation (more like 10k...) that depended on 
a online schema. Ican imagine that could even be worse for terminology 
services(downtimes and maintenance aside).That's why I said standard 
(explicit?) expression definitions shouldbe preferred when available2016-09-11 
20:21 GMT+02:00 Thomas Beale :> Not an unreasonable point 
of view, but it sort of implies that there are /> will be no well-known / 
reliable terminology value sets out there - only> specific value sets inside 
specific terminology services.>>> On 11/09/2016 19:10, Diego Boscá wrote: 
The problem I see with depending on a given terminology service is>> that the 
code you are defining may or may not be known by the>> terminology service. 
This could be ok for templates, but not for>> archetypes. In my opinion generic 
archetypes should be based on known>> syntaxes rather than in specific queries 
to terminology services>> whenever is possible>> 
___> openEHR-technical mailing 
list> 
openEHR-technical@lists.openehr.org>
 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org___openEHR-technical
 mailing 
listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: How can I model multiple checkboxs options with terminology?

[pablo pazos]

BTW, ADL allows "unique" nodes, check the ADL specs.


Sent from my LG Mobile

-- Original message--

From: pablo pazos

Date: Sun, Sep 11, 2016 11:50

To: 
bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>;openehr-technical@lists.openehr.org<mailto:;openehr-technical@lists.openehr.org>;

Subject:Re: How can I model multiple checkboxs options with terminology?

You are right, this might be one of those cases that should be solved by 
software.


Sent from my LG Mobile

-- Original message--

From: Bert Verhees

Date: Sun, Sep 11, 2016 01:35

To: For openEHR technical discussions;

Subject:Re: How can I model multiple checkboxs options with terminology?

Hi Pablo, good solution, I think it is a better solution then mine, the only 
problem is that it allows more times the same selection, isn't it? Because you 
can let occur a DvCodedText more then once in an Element, but you cannot define 
it more then once. Maybe more elements with all one DvCodedText and with all 
have only one (but different) code to select, and have an occurrence of 
optional 0..1..

I think OpenEhr should solve this by creating a new datatype.. What do you 
think?

Op 11 sep. 2016 04:14 schreef "pablo pazos" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>>:

Use a coded text element with occurrences > 1


Sent from my LG Mobile

-- Original message--

From: Tiago Santos da Silva

Date: Sat, Sep 10, 2016 16:38

To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>;

Subject:How can I model multiple checkboxs options with terminology?

Hi,

Can anyone tell how I can model the example below?

"What parts of the body hurt? [ ] right leg [ ] left leg [ ] head [ ] right arm 
.."

I know to model a single option (radio-buttom) but I don't know to model a 
multiple options (checkbox)

The idea is that the options are of the terminology, so I can't model right in 
the archetype.

I'm using the key-path  strategy for data persistence. In the case of the 
radiobutton leaf is a DV_CODED_TEXT but I don't know when use checkbox.

Note: English is not my native language I hope it is clear the doubt.

Thank you!

--
Abs,
Tiago Santos da Silva
===
+55 21 3938-8688 /+55 21 97556-9840<tel:+55%2021%2097556-9840>
CAPGov - Centro de Apoio a Politicas de Governo
COPPE Sistemas / Universidade Federal do Rio de Janeiro

COPPE: 50 ANOS ANTECIPANDO O FUTURO

Arquiteto de Software
Doutorando em Engenharia de Sistemas e Computação (PESC/UFRJ)
Mestre em Engenharia de Sistemas e Computação (PESC/UFRJ)

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: How can I model multiple checkboxs options with terminology?

[pablo pazos]

Use a coded text element with occurrences > 1


Sent from my LG Mobile

-- Original message--

From: Tiago Santos da Silva

Date: Sat, Sep 10, 2016 16:38

To: 
openehr-technical@lists.openehr.org;

Subject:How can I model multiple checkboxs options with terminology?

Hi,

Can anyone tell how I can model the example below?

"What parts of the body hurt? [ ] right leg [ ] left leg [ ] head [ ] right arm 
.."

I know to model a single option (radio-buttom) but I don't know to model a 
multiple options (checkbox)

The idea is that the options are of the terminology, so I can't model right in 
the archetype.

I'm using the key-path  strategy for data persistence. In the case of the 
radiobutton leaf is a DV_CODED_TEXT but I don't know when use checkbox.

Note: English is not my native language I hope it is clear the doubt.

Thank you!

--
Abs,
Tiago Santos da Silva
===
+55 21 3938-8688 / +55 21 97556-9840
CAPGov - Centro de Apoio a Politicas de Governo
COPPE Sistemas / Universidade Federal do Rio de Janeiro

COPPE: 50 ANOS ANTECIPANDO O FUTURO

Arquiteto de Software
Doutorando em Engenharia de Sistemas e Computação (PESC/UFRJ)
Mestre em Engenharia de Sistemas e Computação (PESC/UFRJ)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

[pablo pazos]

Hi Thomas, do you recall if we have any change request to make dvs inherit from 
locatable?

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Thomas Beale <thomas.be...@openehr.org>
Sent: Thursday, November 3, 2016 8:02:41 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives



Hi Pieter,

On 01/11/2016 10:22, Pieter Bos wrote:

I fully agree that they should be mandatory. Things like this make writing 
software based on OpenEHR more complex than it could be.

I also never understood that the DV_-types do not have an archetype node id in 
the reference model.

this is because they don't inherit from LOCATABLE, which is a modelling 
decision from a long time ago. I'm not aware that it has caused major problems 
(at least not reported ones) but I can imagine that it might seem better today 
to make DATA_VALUE inherit from LOCATABLE, or at least to have the 
archetype_node_id field in it. I'm not that clear on how much it matters in 
anyone's implementation.


This adds complexity, because the paths in an archetype do not always match the 
paths in a reference model object. Sometimes you just need paths based on an 
archetype that need to work in reference model objects. For example when 
displaying information, rendering forms, evaluating rules or score 
calculations, or rendering a UI to edit stored reference model objects. Of 
course, you can write something that converts these paths from the AOM to the 
RM, but I don't see why that should be necessary.

well the RM objects, down to the ELEMENT nodes, should have archetype paths 
that match the archetypes that create them, with the added complexity that real 
data may contain multiple instances that match a given archetype path, as 
described 
here<http://www.openehr.org/releases/BASE/latest/docs/architecture_overview/architecture_overview.html#_data_paths_and_uniqueness>.

Can you provide more detail on what 'conversion' you are referring to here?

thanks

- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Converting Archetype into Nosql Schemes

[pablo pazos]

Hi Fadoua,


I would suggest to consider generating a DB schema from the information model 
rather than generating it from the archetypes, since the schema for the IM can 
store any archetyped structure without modifying the schema, and with the 
approach you proposed, your schema will grow with each new archetype.


Also measuring performance is tricky, because performance will depend on 
specific use cases, and some schemas might be more performant for insert 
intensive usage, and others will be more performant for querying intensive 
usage. Event two different schemas on the same DB technology might have 
different benchmark/performance results on different use cases. Also 
optimizations can be done, and as more indexes are defined (more redundant 
data), performance for querying can be improved a lot, even using a relational 
database.


You might already consider this but it's worth noting: most of the current 
relational databases support XML or JSON as primitive datatypes. It might be 
interesting to test those also as an alternative of a native document database.


I've been working on this area for awhile, and a couple of years ago I designed 
the openEHR clinical database implementation course (in spanish, english 
available soon), and presented a workshop with other members of this community 
for the MEDINFO, it was the workshop with most attendees of the conference [] 
here you can find the presentation:


http://www.slideshare.net/pablitox/design-and-implementation-of-clinical-databases-using-openehr

<http://www.slideshare.net/pablitox/design-and-implementation-of-clinical-databases-using-openehr>http://www.cabolabs.com/capacitacion/medinfo2015_tutorial_bases_de_datos_cilnicas.pdf

Design and Implementation of Clinical Databases with 
openEHR<http://www.cabolabs.com/capacitacion/medinfo2015_tutorial_bases_de_datos_cilnicas.pdf>
www.cabolabs.com
Design and Implementation of Clinical Databases with openEHR Pablo Pazos 
Gutiérreza,b,c, Koray Atalagd, Luis Marco-Ruize, Erik Sundvallf,g, Sérgio 
Miranda Freireh



[http://image.slidesharecdn.com/presentation-150824223539-lva1-app6892/95/design-and-implementation-of-clinical-databases-using-openehr-1-638.jpg?cb=1440455878]<http://www.slideshare.net/pablitox/design-and-implementation-of-clinical-databases-using-openehr>

Design and implementation of Clinical Databases using 
openEHR<http://www.slideshare.net/pablitox/design-and-implementation-of-clinical-databases-using-openehr>
www.slideshare.net
Design and implementation of Clinical Databases using openEHR 1. Tutorial - 
Design and Implementation of Clinical Databases with openEHR ...



BTW, did you considered testing openEHR backends? If yes, please take a look: 
http://cabolabs.com/en/projects

Our Projects - cabolabs.com<http://cabolabs.com/en/projects>
cabolabs.com
Unique. Currently there is no other system that for openEHR clinical data 
storage, that has a secure REST API and is open source.





--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Fadoua Khennou <khennoufad...@gmail.com>
Sent: Sunday, October 16, 2016 5:51:23 PM
To: openehr-technical@lists.openehr.org
Subject: Converting Archetype into Nosql Schemes

Thanks everyone for you help i will take into consideration your notes

As for making my goal more clear for Eric, i would like to combine my Openehr 
archetypes with different nosql schemes ( document oriented, colomn oriented 
and key/value) in a sense of comparing the performence of storage and 
processing of these models with openehr standard.

because (till now  there is only the comparison of couchbase with SQL 
relational databases and no focus on specific nosql schemes)

so by then i can select the optimal solution to include as a performant model 
and do some analytics with datamining techniques and here goes the process of 
my whole phd goal.

My regards,

Fadoua khennou

--
Cordialement,

KHENNOU Fadoua
__

Phd student at USMBA-Fes, Morocco

Transmission and Processing of Information laboratory

__
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Question about paths to C_SINGLE_ATTRIBUTE alternatives

[pablo pazos]

Hi,


I was chatting with Diego, about the need of nodeIds for ELEMENT.value and I 
detected some archetypes with alternatives but no nodeIds, I guess, created 
with the Archetype Editor.


Examples from openEHR-EHR-CLUSTER.timing_daily.v0


...

ELEMENT[at0004] occurrences matches {0..*} matches {-- Specific 
time
value matches {
DV_TIME matches {*}
DV_INTERVAL matches {
upper matches {
DV_TIME matches {*}
}
lower matches {
DV_TIME matches {*}
}
}
}
}
ELEMENT[at0026] occurrences matches {0..*} matches {-- Named 
time event
value matches {
DV_TEXT matches {*}
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0031, -- immediately (stat)
at0032, -- in the morning
at0033, -- at night
at0034]-- in the morning and at night
}
}
}
}

...



How can software create paths to the specific ELEMENT.value constraint if the 
constraints don't have a nodeId?



This remembers me of an old discussion about if the nodeIds should or not be 
mandatory. Opinions?



--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

[pablo pazos]

@Thomas thanks for the pointer.

We were talking with Diego about the need of storing the nodeId in the IM for 
datatypes to allow querying over specific DV alternatives of an ELEMENT.value, 
because for path-based queries having nodeId for DV is easier to implement than 
trying to derive the DV from it's attributes in the path.

I think this goes in the lines of what Pieter commented on his email.

@All is there any change request to the IM for adding a nodeId field for 
DATAVALUE, or maybe make it extend LOCATABLE?
Is there any constraint for making DATAVALUE extend LOCATABLE?

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Pieter Bos <pieter@nedap.com>
Sent: Tuesday, November 1, 2016 7:22:48 AM
To: openeh technical; openehr clinical
Subject: Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

I fully agree that they should be mandatory. Things like this make writing 
software based on OpenEHR more complex than it could be.

I also never understood that the DV_-types do not have an archetype node id in 
the reference model. This adds complexity, because the paths in an archetype do 
not always match the paths in a reference model object. Sometimes you just need 
paths based on an archetype that need to work in reference model objects. For 
example when displaying information, rendering forms, evaluating rules or score 
calculations, or rendering a UI to edit stored reference model objects. Of 
course, you can write something that converts these paths from the AOM to the 
RM, but I don’t see why that should be necessary.

Perhaps someone can explain the reasoning behind these choices?

Regards,

Pieter Bos
Nedap Healthcare


From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of pablo pazos <pazospa...@hotmail.com>
Reply-To: openeh technical <openehr-technical@lists.openehr.org>
Date: Monday 31 October 2016 at 17:08
To: openehr clinical <openehr-clini...@lists.openehr.org>, openeh technical 
<openehr-technical@lists.openehr.org>
Subject: Question about paths to C_SINGLE_ATTRIBUTE alternatives


Hi,



I was chatting with Diego, about the need of nodeIds for ELEMENT.value and I 
detected some archetypes with alternatives but no nodeIds, I guess, created 
with the Archetype Editor.



Examples from openEHR-EHR-CLUSTER.timing_daily.v0



...
ELEMENT[at0004] occurrences matches {0..*} matches {-- Specific 
time
value matches {
DV_TIME matches {*}
DV_INTERVAL matches {
upper matches {
DV_TIME matches {*}
}
lower matches {
DV_TIME matches {*}
}
}
}
}
ELEMENT[at0026] occurrences matches {0..*} matches {-- Named 
time event
value matches {
DV_TEXT matches {*}
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0031, -- immediately (stat)
at0032, -- in the morning
at0033, -- at night
at0034]-- in the morning and at night
}
}
}
}

...





How can software create paths to the specific ELEMENT.value constraint if the 
constraints don't have a nodeId?





This remembers me of an old discussion about if the nodeIds should or not be 
mandatory. Opinions?




--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR and terminology servers

[Pablo Pazos]

Hi Daniel,

Did your team publish any articles about the demonstration? I'm interested
in the technical aspects of querying expansion of results.

Thanks!

On Fri, Dec 2, 2016 at 10:01 AM, 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 based on the SNOMED CT query
> language at the time. The demonstrator showed querying over EHR content
> including both AQL and the SNOMED CT query language. The terminology server
> per default did expansion of results of the SNOMED CT queries, i.e. it
> returned a set of SCTID:s+expression id:s. The aim of this experiment was
> to show that some very complex quality indicators could be expressed as
> queries on a structured health record.
>
> /Daniel
>
>
> On 2016-12-02 11:33, Grahame Grieve wrote:
>
> 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 PM, Daniel Karlsson <daniel.karls...@liu.se>
> wrote:
>
>> Dear All,
>>
>> while thinking about terminology server requirements for openEHR systems
>> I would like to ask all openEHR implementers about experiences of
>> different solutions. Are there any experiences of using openEHR systems
>> with e.g. the FHIR terminology services, CTS2, Ocean TQL, homebrew, etc?
>> What are the use cases when the terminology servers are used (e.g.
>> design time, data entry, querying, etc.)? What are the "terminological
>> queries" that are used/needed (e.g. subsumption testing, subset
>> membership, subset expansion, etc.)?
>>
>> Thanks,
>> Daniel
>>
>> --
>>
>> Daniel Karlsson, PhD, sr lecturer
>> Department of Biomedical Engineering/Health informatics
>> Linköping university
>> SE-58185 Linköping
>> Sweden
>> Ph. +46 708350109, Skype: imt_danka, Hangout: daniel.e.karls...@gmail.com
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> -
> http://www.healthintersections.com.au / grah...@healthintersections.com.au
> / +61 411 867 065 <+61%20411%20867%20065>
>
>
> --
> Daniel Karlsson, PhD, sr lecturer
> Department of Biomedical Engineering/Health informatics
> Linköping university
> SE-58185 Linköping
> Sweden
> Ph. +46 708350109 <+46%2070%20835%2001%2009>, Skype: imt_danka, Hangout: 
> daniel.e.karls...@gmail.com
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR and terminology servers

[Pablo Pazos]

Hi Bert,

I think the idea of the CTS2 is to define an abstraction layer over many
terminologies to have a common way to access them event if they have
different features or internal structure.

I'm sure others here will know more about it.

ref http://www.omg.org/spec/CTS2/1.2/

Cheers,
Pablo.

On Sun, Dec 4, 2016 at 5:37 AM, Bert Verhees <bert.verh...@rosa.nl> wrote:

> A Rest service for terminology needs to be defined per terminology,
> because they are all of different features.
>
> There is one good source of inspiration for a SNOMED terminology.
> https://dev-term.ihtsdotools.org/snowowl/snomed-ct/v2/
>
> I say, source of inspiration, because not everybody needs editing
> capacity, most use-cases just want to query.
> And the swagger/openapi is not optimal, there are some errors in the
> data-models on technical level, but these are very few.
>
> When you look at it, and leave out all the branch-things (which are for
> editing and versioning), then you have a decent interface for a SNOMED
> service.
> An then, it is also very obvious (afterwards) and it reflects good
> thinking in its simplicity.
>
> As you may know, there are mappings for SNOMED and LOINC, ICDxx and other
> terminologies (also local), and others, on the way, or already finished, so
> this interface can also used for these mappings which gives in this way a
> route to query other terminologies.
>
> good luck
> Bert Verhees
>
>
>
> On 04-12-16 01:53, Pablo Pazos wrote:
>
> Hi Daniel,
>
> Did your team publish any articles about the demonstration? I'm interested
> in the technical aspects of querying expansion of results.
>
> Thanks!
>
> On Fri, Dec 2, 2016 at 10:01 AM, 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 based on the SNOMED CT query
>> language at the time. The demonstrator showed querying over EHR content
>> including both AQL and the SNOMED CT query language. The terminology server
>> per default did expansion of results of the SNOMED CT queries, i.e. it
>> returned a set of SCTID:s+expression id:s. The aim of this experiment was
>> to show that some very complex quality indicators could be expressed as
>> queries on a structured health record.
>>
>> /Daniel
>>
>>
>> On 2016-12-02 11:33, Grahame Grieve wrote:
>>
>> 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 PM, Daniel Karlsson <daniel.karls...@liu.se>
>> wrote:
>>
>>> Dear All,
>>>
>>> while thinking about terminology server requirements for openEHR systems
>>> I would like to ask all openEHR implementers about experiences of
>>> different solutions. Are there any experiences of using openEHR systems
>>> with e.g. the FHIR terminology services, CTS2, Ocean TQL, homebrew, etc?
>>> What are the use cases when the terminology servers are used (e.g.
>>> design time, data entry, querying, etc.)? What are the "terminological
>>> queries" that are used/needed (e.g. subsumption testing, subset
>>> membership, subset expansion, etc.)?
>>>
>>> Thanks,
>>> Daniel
>>>
>>> --
>>>
>>> Daniel Karlsson, PhD, sr lecturer
>>> Department of Biomedical Engineering/Health informatics
>>> Linköping university
>>> SE-58185 Linköping
>>> Sweden
>>> Ph. +46 708350109 <%2B46%20708350109>, Skype: imt_danka, Hangout:
>>> daniel.e.karls...@gmail.com
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>>
>>
>>
>>
>> --
>> -----
>> http://www.healthintersections.com.au / grah...@healthintersections.co
>> m.au / +61 411 867 065 <+61%20411%20867%20065>
>>
>>
>> --
>> Daniel Karlsson, PhD, sr lecturer
>> Department of Biomedical Engineering/Health informatics
>> Linköping university
>> SE-58185 Linköping
>> Sweden
>> Ph. +46 708350109 <+46%2070%20835%2001%2009>, Skype: imt_danka, Hangout: 
>> d

Re: Cloud EHRServer is about to be launched

[Pablo Pazos]

Dear friends,

First thanks a lot for all your private emails supporting me on this new
challenge and for the people that believes that initiatives like this one
are of a great value to our community, since clinical data storage is an
open problem in the openEHR world.


Some updates!

The website is up and running: https://cloudehrserver.com/

If you detect any errors please let me know.

It has some basic information and guides. I'll be adding more guides and
tech docs soon.

In the community section you can find client libraries I created for PHP,
Javascript and Groovy. Basically are helpers and sample code to help you on
using the EHRServer REST API. If you want to create a client for another
language, please let me know!

Also there is a project called openEHR-OPT: a command line tool that allows
to 1. generate HTML GUI from an OPT, 2. generate XML instances from an OPT
(VERSION or just COMPOSITION), 3. validate XML instances using the openEHR
XSD.

All the aforementioned tools are open source, as the EHRServer itself,
designed & developed by me in the last couple of years.


For know the full documentation is the EHRServer guide that can be found
here: http://cabolabs.com/en/projects

Please let me know if you have any questions.


Happy new year for everyone!

Kind regards,
Pablo.

PS: yes, I use these lists because there is no other way to reach the
community and the announcing list is used by the openEHR Foundation Board,
not by community members. I though a lot about this, and I firmly believe
this is of value to the openEHR community as a whole and that is the most
important aspect than if I charge money to use the service. As I mentioned,
this is an open source development and the fee is to maintain
infrastructure and allow further development of the tool. Without this
support the project will just die, since it is just me designing and
developing, staying up late at night, using my weekends to work on the
project, etc. and it has been that way since 2009 when I started with my
first PoC for an openEHR backend. Please consider this and I ask for a
little understanding. Thanks.



On Mon, Dec 26, 2016 at 2:22 AM, Pablo Pazos <pablo.pa...@cabolabs.com>
wrote:

> Dear friends,
>
> I'm about to launch the Cloud EHRServer, a clinical data repository /
> health information system backend as a service. I'm very excited about
> this, since I invested a lot on the EHRServer development and now it seems
> natural to take this next step to make further development sustainable in
> time.
>
> This SaaS is based on the EHRServer, the first open source openEHR
> clinical data repository, I've been developing for the last years. The
> development and maintenance of the EHRServer will continue in parallel to
> the Cloud EHRServer.
>
> There are two big use cases for this kind of service. One is to serve as a
> backend of clinical information systems that need to access the same data
> e.g. web and mobile apps. The other use case is to centralize shared
> clinical information, generated by different systems, accessible in a
> standardized way.
>
> For the first phase of the Cloud EHRServer we will only accept sign-ups
> for the Beta Partners Program, a reduced group of people / companies that
> want to use the service, participate on its improvement, and grow with us.
>
> The cost of participation in the Beta Partners Program will be 25USD/mo
> with options for 6 or 12 months. This is be like a medium sized plan but
> without any restrictions, do you don't have to worry about quotas during
> prototyping and testing. This will help us to maintain the infrastructure
> and scale on the first year, while developing some features of the current
> roadmap to v1.0
>
> The Beta Partners will receive training, premium support, early access to
> guides and new releases of the EHRServer, access to online events, will be
> able to propose new features and vote to prioritize them, to help the
> service move towards the needs of the community.
>
> The current status of the EHRServer is that we are about to launch v0.9
> that will be production-ready, and we already have a production server in
> place with HTTPS working. The EHRServer was in the cloud for more than 12
> months on a staging server, and we have about 300 registered users, between
> testers and students of my courses (http://www.cabolabs.com/en/training).
> We will have 2 staging servers alongside the production one.
>
> Next week I will launch the official Website with more information, the
> sign-up form for the Beta Partners Program and some initial guides. On the
> first days of January the production server will be enabled for use. For
> now if you want to know more please fill the contact form:
> https://cloudehrserver.com/
>
> Feel free to contact me if you have any questions. Thanks a lot for your
&g

Cloud EHRServer is about to be launched

[Pablo Pazos]

Dear friends,

I'm about to launch the Cloud EHRServer, a clinical data repository /
health information system backend as a service. I'm very excited about
this, since I invested a lot on the EHRServer development and now it seems
natural to take this next step to make further development sustainable in
time.

This SaaS is based on the EHRServer, the first open source openEHR clinical
data repository, I've been developing for the last years. The development
and maintenance of the EHRServer will continue in parallel to the Cloud
EHRServer.

There are two big use cases for this kind of service. One is to serve as a
backend of clinical information systems that need to access the same data
e.g. web and mobile apps. The other use case is to centralize shared
clinical information, generated by different systems, accessible in a
standardized way.

For the first phase of the Cloud EHRServer we will only accept sign-ups for
the Beta Partners Program, a reduced group of people / companies that want
to use the service, participate on its improvement, and grow with us.

The cost of participation in the Beta Partners Program will be 25USD/mo
with options for 6 or 12 months. This is be like a medium sized plan but
without any restrictions, do you don't have to worry about quotas during
prototyping and testing. This will help us to maintain the infrastructure
and scale on the first year, while developing some features of the current
roadmap to v1.0

The Beta Partners will receive training, premium support, early access to
guides and new releases of the EHRServer, access to online events, will be
able to propose new features and vote to prioritize them, to help the
service move towards the needs of the community.

The current status of the EHRServer is that we are about to launch v0.9
that will be production-ready, and we already have a production server in
place with HTTPS working. The EHRServer was in the cloud for more than 12
months on a staging server, and we have about 300 registered users, between
testers and students of my courses (http://www.cabolabs.com/en/training).
We will have 2 staging servers alongside the production one.

Next week I will launch the official Website with more information, the
sign-up form for the Beta Partners Program and some initial guides. On the
first days of January the production server will be enabled for use. For
now if you want to know more please fill the contact form:
https://cloudehrserver.com/

Feel free to contact me if you have any questions. Thanks a lot for your
support!

Kind regards,
Pablo.


-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145 <099%20043%20145>
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Random / Synthetic Data Generation over Templates

[Pablo Pazos]

If course, it does several things:

- parses and loads opts in memory she does then in a cache for easy access
(I use it as jar lib in a couple of projects including the ehrserver)
- generates xml instances based on opts
- validates the instances with xsd
- generates basic html from an opt

The latest 3 are command line tools

On Apr 13, 2017 2:27 PM, "Thomas Beale" <thomas.be...@openehr.org> wrote:

> Pablo,
>
> is that a tool we can list on the openEHR tools page
> <http://www.openehr.org/downloads/modellingtools>?
>
> - thomas
>
> On 13/04/2017 10:59, Pablo Pazos wrote:
>
> Hi, I have developed a tool that does that, is the openEHR-OPT project in
> my GitHub account (ppazos).
>
> On Apr 13, 2017 12:37 PM, "Anastasiou A." <a.anastas...@swansea.ac.uk>
> wrote:
>
>> Hello everyone
>>
>>
>>
>> I remember some time ago, there was a tool that given a detailed template
>> description, it would populate it with random data taking
>> into account only knowledge about the datatype.
>>
>>
>>
>> I vaguely remember Heather Leslie mentioningit but I may be wrong.
>>
>>
>>
>> Is that functionality available from one of Ocean’s tools? (e.g. the
>> Template Designer)
>>
>>
>>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Random / Synthetic Data Generation over Templates

[Pablo Pazos]

In my case i have that in my To Do list. I want to complete the services
with an XML instance validator based on the OPT constraints, not just on
the XSD. It will take some time to have a usable release.

On Thu, Apr 13, 2017 at 5:20 PM, Ian McNicoll <i...@freshehr.com> wrote:

> Would there be any interest in making these services available if we could
> find some free uk hosting? I guess ideally we should post the template and
> get back a sample composition without any actual persistence of either.
>
>
> On Thu, 13 Apr 2017 at 18:39, Diego Boscá <yamp...@gmail.com> wrote:
>
>> Yeah, LinkEHR can do that
>>
>> Regards
>>
>> El 13/4/2017 17:37, "Anastasiou A." <a.anastas...@swansea.ac.uk>
>> escribió:
>>
>>> Hello everyone
>>>
>>>
>>>
>>> I remember some time ago, there was a tool that given a detailed
>>> template description, it would populate it with random data taking
>>> into account only knowledge about the datatype.
>>>
>>>
>>>
>>> I vaguely remember Heather Leslie mentioningit but I may be wrong.
>>>
>>>
>>>
>>> Is that functionality available from one of Ocean’s tools? (e.g. the
>>> Template Designer)
>>>
>>>
>>>
>>> Is similar functionality available through other tools? (e.g. LinkEHR,
>>> other).
>>>
>>>
>>>
>>> Looking forward to hearing from you
>>>
>>> Athanasios Anastasiou
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-
>>> technical_lists.openehr.org
>>>
>> _______
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> technical_lists.openehr.org
>
> --
> Ian McNicoll
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Random / Synthetic Data Generation over Templates

[Pablo Pazos]

Hi, I have developed a tool that does that, is the openEHR-OPT project in
my GitHub account (ppazos).

On Apr 13, 2017 12:37 PM, "Anastasiou A." 
wrote:

> Hello everyone
>
>
>
> I remember some time ago, there was a tool that given a detailed template
> description, it would populate it with random data taking
> into account only knowledge about the datatype.
>
>
>
> I vaguely remember Heather Leslie mentioningit but I may be wrong.
>
>
>
> Is that functionality available from one of Ocean’s tools? (e.g. the
> Template Designer)
>
>
>
> Is similar functionality available through other tools? (e.g. LinkEHR,
> other).
>
>
>
> Looking forward to hearing from you
>
> Athanasios Anastasiou
>
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

EHRServer v0.9 was released!

[Pablo Pazos]

Dear friends and colleagues,

I'm glad to let you know that the new version of the EHRServer is ready.
You can find the code of the release here:
https://github.com/ppazos/cabolabs-ehrserver/releases

The EHRServer is an open source, service oriented, cloud-ready, openEHR
compliant, clinical data repository. You can find more about he project,
here: http://cabolabs.com/en/projects

Next week we'll have an open demo in English (the week after I'll do one in
Spanish) where you can see it in action and ask all the question you might
have about the tool. Please check the event link and invite anyone that
might be interested. Event:
https://plus.google.com/events/coropai6fbqb47e6h6munbq9i68

This year we started a SaaS based on the EHRServer, find more info here:
https://cloudehrserver.com/ (check the learn section where you can find
useful guides).


Have a great weekend!
Pablo.

-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Clinical Knowledge Manager (CKM) - New Release with new Dashboard

[Pablo Pazos]

Awesome! I'll check it out.

On Mon, Mar 13, 2017 at 10:41 AM, Sebastian Garde <
sebastian.ga...@oceaninformatics.com> wrote:

> Dear all,
>
>
>
> We have just updated the openEHR Clinical Knowledge Manager.
>
>
>
> This CKM release adds a new Dashboard for new or not logged-in users. It
> also completely revamps the current Dashboards for logged-in users, editors
> and clinical knowledge administrators. In addition, we have finetuned many
> details around the review process, statistics, various grid tooltips, the
> UCUM unit validation and the general CKM look & feel.
>
> You can view the detailed RELEASE NOTES here:
> https://openehr.atlassian.net/wiki/display/healthmod/CKM+Release+1.7.0
>
>
>
> Very much hope that you like it, but just in case that you experience any
> problems, please first delete your browser cache.
>
> If the problem persists, contact us via CKM’s Help/Report Bug or
> Help/Suggest New Feature or directly by email to c...@oceaninformatics.com
>
>
>
> Best regards
>
> Sebastian
>
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
pablo.pa...@cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: EHRServer v0.9 was released!

[Pablo Pazos]

Hi my friend, don't worry the video will be uploaded to YouTube.

Talk to you later.

On Mar 4, 2017 2:18 PM, "Seung Jong Yu" <ggoj...@gmail.com> wrote:

Great work !

I hope many people use EHRServer a lot.

I received well your invitation at open demo next week but I may not attend
to it (AM 4:00 in Korea !)

The event will be held well !

Seung-Jong YuMD

Certified Board of Family Medicine
CEO, InfoClinic Co., Ltd. (i...@infoclinic.co​
​ , ​
http://
​www.​
infoclinic.co <http://infoclinic.co/>
​
​
)

​​
InfoClinic's FaceBook Group : https://www.facebook.com/gro
ups/1476424142610167/
STOM Browser for SNOMED CT & LOINC : http://term.infoclinic.co
STOM API List : http://api.infoclinic.co

2017-03-04 23:58 GMT+09:00 Pablo Pazos <pablo.pa...@cabolabs.com>:

> Dear friends and colleagues,
>
> I'm glad to let you know that the new version of the EHRServer is ready.
> You can find the code of the release here: https://github.com/ppazos/cabo
> labs-ehrserver/releases
>
> The EHRServer is an open source, service oriented, cloud-ready, openEHR
> compliant, clinical data repository. You can find more about he project,
> here: http://cabolabs.com/en/projects
>
> Next week we'll have an open demo in English (the week after I'll do one
> in Spanish) where you can see it in action and ask all the question you
> might have about the tool. Please check the event link and invite anyone
> that might be interested. Event: https://plus.google.com/events
> /coropai6fbqb47e6h6munbq9i68
>
> This year we started a SaaS based on the EHRServer, find more info here:
> https://cloudehrserver.com/ (check the learn section where you can find
> useful guides).
>
>
> Have a great weekend!
> Pablo.
>
> --
> Ing. Pablo Pazos Gutiérrez
> Cel:(00598) 99 043 145 <099%20043%20145>
> Skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> pablo.pa...@cabolabs.com
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>



-- 
---
Seung-Jong YuMD

Certified Board of Family Medicine
CEO, InfoClinic Co., Ltd. (i...@infoclinic.co​
​ , ​
http://infoclinic.co
​
)
Administrator, openEHR Korea (
​mas...@openehr.kr , ​
http://www.openehr.kr)

Mobile : 82-10-4752-5435
seungjong...@gmail.com
ggoj...@gmail.com ( for mailing list )

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org