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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

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.o

RE: EHRServer is on the cloud

[pablo pazos]

Hi Jega, it is Apache 2.

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

Date: Wed, 17 Jun 2015 12:42:39 +1000
Subject: RE: EHRServer is on the cloud
From: jega.sivane...@gmail.com
To: openehr-implementers@lists.openehr.org

Hi pablo,
What license are you releasing this under?
Thanks
Jegan
On 17 Jun 2015 12:30 pm, "pablo pazos"  wrote:



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:18
To: For openEHR clinical discussions;
Subject:Re: EHRServer is on the cloud
Hi 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

RE: EHRServer is on the cloud

[pablo pazos]

Hi all!
I have deployed the v0.2 in OpenShift: 
https://cabolabs-ehrserver.rhcloud.com/ehr-0.2/
If you are interested in the improvements made, see milestone v0.2 here: 
https://github.com/ppazos/cabolabs-ehrserver/milestones
By the way, I have created a small Javascript library to pull data from the 
EHRServer using AJAX or JSONP. The idea is to use it on hybrid mobile apps or 
NodeJS apps. The project is here: 
https://github.com/ppazos/cabolabs-ehrserver-js
I will create other clients for Java, Grails and PHP inthe future. Also, I will 
create clients to push data to the server.
Thanks to everyone testing the EHRServer!

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

From: pazospa...@hotmail.com
To: openehr-implementers@lists.openehr.org
Subject: RE: EHRServer is on the cloud
Date: Wed, 17 Jun 2015 01:33:43 -0300




Hi Jega, it is Apache 2.

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

Date: Wed, 17 Jun 2015 12:42:39 +1000
Subject: RE: EHRServer is on the cloud
From: jega.sivane...@gmail.com
To: openehr-implementers@lists.openehr.org

Hi pablo,
What license are you releasing this under?
Thanks
Jegan
On 17 Jun 2015 12:30 pm, "pablo pazos"  wrote:



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:18
To: For openEHR clinical discussions;
Subject:Re: EHRServer is on the cloud
Hi 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

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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-techni...@lists.openehr.org
CC: openehr-implementers@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"  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-techni...@lists.openehr.org

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


___
openEHR-technical mailing list
openehr-techni...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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"] = 
  >
   >   ["AOD2000"] = < items = <
   ["ac0001"] =  
   >   >   >

If I use this archetype in the Template Designer and export the OPT, I get just 
one URI:

DV_CODED_TEXT
  ...
   
   
defining_code
  ...  
  
CODE_PHRASE
  ...  
   
   
terminology:SNOMED-CT?subset=motivo_de_consulta
      
  

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

RE: Development based on xml-schemas

[pablo pazos]

Hi Gabriel, the schema URI is not an URL, is the URI we use for the openEHR XML 
namespace. XSDs are on GitHub.
Also, you might need to use XML Operational Templates, not ADL archetypes 
directly.

Please let us know what's your experience with archetypes and openEHR in 
general so we can guide you better.

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

Date: Wed, 18 Nov 2015 16:37:31 -0200
Subject: Development based on xml-schemas
From: gabriel.m...@figlabs.com
To: openehr-implementers@lists.openehr.org

Hi everyone,

I'm a researcher of medical systems for ultrasound at company Figlabs in 
Brazil. I've some difficulties to implement the archetypes/templates into a 
classes (Python Language).I'm using xml and xsd files and the reference of xsd 
(http://schemas.openehr.org/v1), that shows "Not Found".

In Brazil there are standards that specify the use of XML-schemas for 
interoperable communication systems, and so we chose to use the reading of the 
archetype for xml-schemas, because of the ease of exporting data in the same 
format.

In this case, what should I do if the CKM own archetypes return the invalid XSD 
reference.

Grateful!
Gabriel MiniR & D
gabriel.mini@figlabs.comSkype: gabrielmini.figlabs
Tel.: +55 16 3315-9922 Ribeirão Preto/SP - Brazil
Website: www.figlabs.com


___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
  ___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-techni...@lists.openehr.org; openehr-implementers@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-techni...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-techni...@lists.openehr.org; openehr-implementers@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-techni...@lists.openehr.org; openehr-implementers@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-techni...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
  ___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-techni...@lists.openehr.org
CC: openehr-implementers@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"  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-techni...@lists.openehr.org

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


___
openEHR-technical mailing list
openehr-techni...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-techni...@lists.openehr.org; openehr-implementers@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-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
  ___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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-techni...@lists.openehr.org; openehr-implementers@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 
implementers 

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-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
  ___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

RE: Overview of all (defacto) standards in Health-ICT

[pablo pazos]

Thanks for sharing Bert, very interesting info! Using google translate right 
now :)

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

> To: openehr-implementers@lists.openehr.org
> From: bert.verh...@rosa.nl
> Subject: Overview of all (defacto) standards in Health-ICT
> Date: Tue, 5 Apr 2016 09:16:33 +0200
> 
> The Dutch government Health-ICT organization Nictiz, has a website with 
> 112 health related standards. It has figures of usage, classifications 
> and links, and some intelligence in selecting subsets. (in Dutch)
> 
> They did not have OpenEHR and HISA mentioned, but after me informing 
> them yesterday evening, they are going to add them. This because OpenEHR 
> is commercially implemented in the Netherlands by Code24 and some 
> others, and HISA is a CEN standard. So both are important to have on 
> that site.
> 
> I hope foreigners can understand the website too, because it is a good 
> overview, and there are lots of international keywords in the description.
> 
> Maybe if someone also misses a standard (does not need to be ISO or CEN, 
> defacto is also good), tell me (with links) and I will inform them, or 
> you can inform them yourself.
> 
> https://www.nictiz.nl/standaardisatie/overzicht-standaarden
> 
> best regards
> Bert Verhees
> 
> 
> 
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
  ___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

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 
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 f

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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: EHRServer v0.9 was released!

[Pablo Pazos]

Hi Bert,

The websites are all in English, but it defaults to Spanish if the locale
is not detected. Maybe it's because the nl locale is not supported. I'll
add a button to allow changing the language.

Thanks

On Mar 4, 2017 6:16 PM, "Bert Verhees"  wrote:

> Sorry Pablo, I am never avaible on Wednesday evening. I am really sorry
> for that.
>
> I hope there will be a way to look back at your presentation. Of course I
> can take a look at the source-code, but that is not really a quick way of
> finding out which functional and technical features your system has. I also
> found out that big parts of the website are in Spanish, which is a
> beautiful language, but I am very sorry, that my knowledge of that is
> limited to some very basic sentences.
>
> If it is good, or very promising to be good in short time, I think there
> will be a great future for it.
>
> How can we find out in an easy way about this? Imagine the questions
> Europeans could have about this product, how could they find the answers in
> an easy way?
>
> Best regards
>
> Bert Verhees
>
> Op 4-3-2017 om 15:58 schreef 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 <099%20043%20145>
> Skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> pablo.pa...@cabolabs.com
>
>
> ___
> openEHR-implementers mailing 
> listopenEHR-implementers@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_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"  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 :

> 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-techni...@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-techni...@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
technical_lists.openehr.org
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Blood pressure archetype, XML projection problem

[Pablo Pazos]

Hi Otto, C_STRING is not a data type, is a constraint over a string.

Not sure what fails in your case, what schema are you using?

On Apr 20, 2017 1:21 PM, "Otto Medin"  wrote:

> Hi all,
>
>
>
> I've just started experimenting with openEHR, and here's a newbie question
> to the list. (Please do let me know if this is not the right forum for this
> type of thing.)
>
>
>
> I auto-created classes in our platform (HealthShare), based on the RM/AM
> xsd files, then created my own 'IntervalOf' classes (as they
> weren't included), and fetched the XML projection of the blood pressure
> archetype, but this failed schema validation due to the following:
>
>
>
>   
>
> Boolean
>
> 2007
>
> false precedence_overridden>
>
> 
>
>   String
>
>   
> archetype_id/value
>
>   attribute
>
> 
>
> 
>
>   C_STRING
>
>   
>
> openEHR-EHR-CLUSTER\.
> level_of_exertion(-[a-zA-Z0-9_]+)*\.v1
>
>   
>
>   constraint
>
> 
>
>   
>
>
>
> As you can see, there are two instances of 'EXPR_LEAF', and in the first
> one, 'item' is (correctly, I think) a string, but in the second, it's a
> complex datatype, which is what fails my schema validation.
>
>
>
> Am I misunderstanding something, or is there an error in the XML
> projection?
>
>
>
> Cheers,
>
>
>
> *Otto Medin*
>
> Senior Sales Engineer – Scandinavia
>
> Mobile:  +46 705 112 117
>
> *www.intersystems.se *
>
>
>
> [image: cid:ED240A39-0B89-4E22-A855-B5D04BBD2DD0]
>
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: SNOMEDCT - correct representation

[Pablo Pazos]

Congratulations about the new adoption!

The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our
specs we are using SNOMED-CT as the name (it should be corrected to the
name preferred by the IHTSDO). On an event they explicitly asked to avoid
the SNOMED-CT with the hyphen when referencing the standard.

As for the term id, I've seen [snomed-ct::35917007 on the specs, or
SNOMED-CT on sample archetypes:
https://github.com/openEHR/specifications-ITS/search?utf8=%E2%9C%93&q=snomed&type=

Tested on the Ocean's archetype editor and they use:

constraint_bindings = <
["SNOMED-CT"] = <
items = <
["ac0001"] = 
>
>
>



On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss  wrote:

> Norway just became a SNOMED country.
>
> One simple question – what is the correct terminologyId to use for
> SNOMED-CT.
>
>
>
> Currently we use ‘SNOMEDCT’ like below. Is this correct?
>
>
>
>  
> Høyre øye
> 
>   
> SNOMEDCT
>   
>   18944008
> 
>   
>
>
>
> Vennlig hilsen
> Bjørn Næss
> Produktansvarlig
> DIPS ASA
>
> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: AQL: Expected result with repeating structures

[Pablo Pazos]

Trying to understand the problem, I modeled the database schema in my head.

origin is like a column from the container and magnitude/units are columns
for the contained node. So it is like having two tables, one for history
and one for the events with the data (might be N tables in the middle but
this is a simplification), so it is a one to many relationship, getting one
field from the *one* side and two from the *many* side. For me the result
would repeat the origin for every magnitude/units pair, and each result in
the result set will be that triplet (o, m, u), repeating the o for every
triplet, and m,n be values contained in the same
event/cluster/element/datavalue, since the parent paths until the datavalue
are the same, the only difference is the reference to the datavalue
attributes.

But that is what I think it should return, maybe the semantics are
different in AQL and the results should be the permutations of data between
siblings, but I don't see much sense on doing that. Also, something like a
group by might be needed, but instead of having that for aggregations like
in SQL, have that to group data by container.

Sorry if this doesn't make much sens, I might not understand the whole
problem :)


On Mon, Apr 24, 2017 at 7:01 PM, Bjørn Næss  wrote:

> Hi
>
> We have created a GIT repo with some issues from our experiences with AQL.
>
> The repo was created to expose one issue with repeating items. You will
> find it here – and some feedback is welcome:
>
>
>
> Folder with all files: https://github.com/bjornna/
> openehr-conformance/tree/master/aql/case1-permutations
>
>
>
> README with the problem: https://github.com/bjornna/
> openehr-conformance/blob/master/aql/case1-permutations/index.adoc
>
>
>
> The initial problem was this:
>
>
>
> One simple example may be openEHR-EHR-OBSERVATION.body_weight.v1 which
> have an optional and repeating 'any_event'. Below is a straigt forward AQL
> on this archetype. We are asking for the origin from the HISTORY attribute,
> and then for each repeating event we want the weight magnitude and unit.
>
> As you see from the AQL there is an additional WHERE clausul telling that
> we only want weight with magnitude less than 45.
>
> The question is: *What do you expect as result from this query?*
>
> select
>
> o/data[at0002]/origin/value as time,
>
> 
> o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude
> as Weight,
>
> o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/units
> as Unit
>
> from
>
> composition c
>
> contains
>
> observation o[openEHR-EHR-OBSERVATION.body_weight.v1]
>
> where
>
> 
> o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude
> < 45
>
> order by
>
> o/data[at0002]/origin/value desc
>
>
>
>
>
> Vennlig hilsen
> Bjørn Næss
> Produktansvarlig
> DIPS ASA
>
> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: AQL: Expected result with repeating structures

[Pablo Pazos]

On XML queries I would prefer to query and return a complete subdocument
starting from the history, not just individual nodes. On that scenario
querying by multiple xpath that point to individual nodes might return just
a list with those nodes without any relationship. But if those nodes
include some kind of parent instance id, from the list of results a program
might reconstruct the hierarchy. The problem I see on this is that the
database already has the hierarchy and returns a plain list and the client
needs to reconstruct, why not just return the whole hierarchy and let the
client process it?

I have more doubts than certainties. I know how I do things in the
EHRServer, but not sure how this should work in general.

1. In the EHRServer, database is relational.
2. Queries for datavalues return whole datavalues, so there is no need of
adding a projection for e.g. magnitude, units when querying a DV_QUANTITY.
3. Results can be grouped by composition, e.g. multiple instances of event
will have a leaf element in the structure, the result will put all the
ELEMENT.value for all the EVENTs of the same COMPOSITION instance together
in the result.
4. Results can be grouped by path, all the results for e.g. systolic BP
together, independently of the composition/event that contains them, but
the result is annotated with the starttime of the COMPOSITION that contains
the datavalue. And as I remember you mentioned on the latest demo of the
EHRServer something about making that more flexible, e.g. annotating the
results with the HISTORY.origin or other time in the model. I think that
will be very useful on queries like the one you mention on the first email
(and I have it on my TODO list :)

But this is not AQL (yet), is just how I designed dynamic queries that can
be clinically useful. IMO AQL is too generic and some behaviors are not
100% defined yet, but is also powerful and expressive.



On Tue, Apr 25, 2017 at 5:36 PM, Bjørn Næss  wrote:

> Thanks Pablo!
>
> I think you have understood the problem. The real problem is how to
> interpret the clinical intention of the query, and then how to apply that
> on the openEHR RM to produce the correct output.
>
>
>
> I have been thinking about adding different “implementation” of the
> problem. One “implementation” could be a ER (enitity relationship) model
> with tables and references. And then to apply this to SQL. Another
> “implementation” would be XPATH.
>
>
>
> In this problem you need to define how to repeat:
>
>
>
> . History.Origin by all child EVENTS
>
> . Observation.Protocol joined by data from events.
>
>
>
> It would be nice if you could contribute with some ER models to show how
> this would work in your model. Put another way; how would such a query look
> like and what would the output be form your system?
>
>
>
>
>
> Vennlig hilsen
> Bjørn Næss
> Produktansvarlig
> DIPS ASA
>
> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>
>
>
>
> *From:* openEHR-implementers [mailto:openehr-implementers-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* tirsdag 25. april 2017 06.54
> *To:* For openEHR implementation discussions  openehr.org>
> *Subject:* Re: AQL: Expected result with repeating structures
>
>
>
> Trying to understand the problem, I modeled the database schema in my head.
>
> origin is like a column from the container and magnitude/units are columns
> for the contained node. So it is like having two tables, one for history
> and one for the events with the data (might be N tables in the middle but
> this is a simplification), so it is a one to many relationship, getting one
> field from the *one* side and two from the *many* side. For me the result
> would repeat the origin for every magnitude/units pair, and each result in
> the result set will be that triplet (o, m, u), repeating the o for every
> triplet, and m,n be values contained in the same 
> event/cluster/element/datavalue,
> since the parent paths until the datavalue are the same, the only
> difference is the reference to the datavalue attributes.
>
> But that is what I think it should return, maybe the semantics are
> different in AQL and the results should be the permutations of data between
> siblings, but I don't see much sense on doing that. Also, something like a
> group by might be needed, but instead of having that for aggregations like
> in SQL, have that to group data by container.
>
> Sorry if this doesn't make much sens, I might not understand the whole
> problem :)
>
>
>
>
>
> On Mon, Apr 24, 2017 at 7:01 PM, Bjørn Næss  wrote:
>
> Hi
>
> We have created a GIT repo with some issues from our experiences with AQL.
>
> The repo was created to expose one issue with repeating items. You will
> find

Please help answer this question on StackOverflow

[Pablo Pazos]

http://stackoverflow.com/questions/43922257/how-to-write-a-compliance-statement-for-the-openehr-standard

-- 
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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

A little community coordination

[Pablo Pazos]

Hi all,

We were discussing on other threads about the need to improve the tools,
ref impls and frameworks we use for openEHR stuff. We are few in the
community working on those areas, and sometimes doing duplicated work and
overlapping solutions.

I believe if we know who is working on what, we can make a better use of
our collective time as a community, and reuse others work, or even help on
their projects.

Modeling tools are getting behind the specs progress, tool chain is broken
and needs manual work to get modeling done, open implementation tech stacks
are not complete, etc...

What if we can publish the areas we are working on, tools that we already
have, and try to coordinate better to fix those issues and collaborate
better as a community?


I have created a small google form to gather and share that info, it has
these questions:

1. On which areas are you / your company working on? (modeling tools, CDRs,
APIs, ...)
2. Is code open or planned to be open?
3. Current status (idea, planned, developing, developed, released, ...)
4. Main issues and challenges (for the community to help)
5. Available tools / solutions and where to find them


If you see there is another question that can add value to this, please let
me know. After this is complete, I'll share the form. When we have some
answers, I'll publish them on the wiki.

Hopefully others can this this as an opportunity to move forward on the
modeling and dev areas to increase openEHR adoption.


Kind regards,
Pablo.

-- 
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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

EHRServer v0.9.5 was released!

[Pablo Pazos]

Dear friends,

The EHRServer openEHR Clinical Data Repository, Open Source, Designed for
the Cloud v0.9.5 was released!

Release: https://github.com/ppazos/cabolabs-ehrserver/releases/tag/v0.9.5
<https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fgithub%2Ecom%2Fppazos%2Fcabolabs-ehrserver%2Freleases%2Ftag%2Fv0%2E9%2E5&urlhash=NVBW&_t=tracking_anet>

EHRServer overview: https://www.youtube.com/watch?v=ix_G6oJk_ns
<https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fwww%2Eyoutube%2Ecom%2Fwatch%3Fv%3Dix_G6oJk_ns&urlhash=39Ps&_t=tracking_anet>

EHRServer demo: https://www.youtube.com/watch?v=i9iM1xbI6SI
<https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fwww%2Eyoutube%2Ecom%2Fwatch%3Fv%3Di9iM1xbI6SI&urlhash=j13U&_t=tracking_anet>

Documentation will be updated soon here: https://cabolabs.com/en/projects

And I'm adding new guides and use cases here:
https://cloudehrserver.com/learn?lang=en

Out open test server was updated to the latest version, try it out!
https://ehrserver-cabolabs2.rhcloud.com


Questions, comments, suggestions, etc. are always welcome!

Kind regards,
Pablo.

-- 
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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: A little community coordination

[Pablo Pazos]

Hi all,

I just published the received responses. So far only four members of the
community shared they work, ideas and needs. For you:

​

Hope this can get others motivated to follow. We need to improve our
community, collaborate and be more open.

https://openehr.atlassian.net/wiki/display/dev/Development+Community+Coordination



On Mon, May 22, 2017 at 4:56 AM, Seung Jong Yu  wrote:

> Good Idea, Pablo !
>
> Even if I can not support openEHR specific terminology services, I filled
> form :)
>
> Seung-Jong YuMD
> seungjong...@gmail.com
>
> 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)
> HL7 Korea Board of Director (http://hl7korea.or.kr)
>
> Mobile : 82-10-4752-5435
> ggoj...@gmail.com ( only for mailing list )
>
> 2017-05-20 1:29 GMT+09:00 Pablo Pazos :
>
>> Hi all,
>>
>> We were discussing on other threads about the need to improve the tools,
>> ref impls and frameworks we use for openEHR stuff. We are few in the
>> community working on those areas, and sometimes doing duplicated work and
>> overlapping solutions.
>>
>> I believe if we know who is working on what, we can make a better use of
>> our collective time as a community, and reuse others work, or even help on
>> their projects.
>>
>> Modeling tools are getting behind the specs progress, tool chain is
>> broken and needs manual work to get modeling done, open implementation tech
>> stacks are not complete, etc...
>>
>> What if we can publish the areas we are working on, tools that we already
>> have, and try to coordinate better to fix those issues and collaborate
>> better as a community?
>>
>>
>> I have created a small google form to gather and share that info, it has
>> these questions:
>>
>> 1. On which areas are you / your company working on? (modeling tools,
>> CDRs, APIs, ...)
>> 2. Is code open or planned to be open?
>> 3. Current status (idea, planned, developing, developed, released, ...)
>> 4. Main issues and challenges (for the community to help)
>> 5. Available tools / solutions and where to find them
>>
>>
>> If you see there is another question that can add value to this, please
>> let me know. After this is complete, I'll share the form. When we have some
>> answers, I'll publish them on the wiki.
>>
>> Hopefully others can this this as an opportunity to move forward on the
>> modeling and dev areas to increase openEHR adoption.
>>
>>
>> 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
>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>>
>> _______
>> openEHR-technical mailing list
>> openehr-techni...@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: A little community coordination

[Pablo Pazos]

Hi all, received more answers and shared them in the openEHR wiki.

Very interesting projects there and I can see a lot of room for
collaboration!

On Sun, May 28, 2017 at 10:59 PM, Pablo Pazos 
wrote:

> Hi all,
>
> I just published the received responses. So far only four members of the
> community shared they work, ideas and needs. For you:
>
> ​
>
> Hope this can get others motivated to follow. We need to improve our
> community, collaborate and be more open.
>
> https://openehr.atlassian.net/wiki/display/dev/Development+
> Community+Coordination
>
>
>
> On Mon, May 22, 2017 at 4:56 AM, Seung Jong Yu  wrote:
>
>> Good Idea, Pablo !
>>
>> Even if I can not support openEHR specific terminology services, I filled
>> form :)
>>
>> Seung-Jong YuMD
>> seungjong...@gmail.com
>>
>> 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)
>> HL7 Korea Board of Director (http://hl7korea.or.kr)
>>
>> Mobile : 82-10-4752-5435
>> ggoj...@gmail.com ( only for mailing list )
>>
>> 2017-05-20 1:29 GMT+09:00 Pablo Pazos :
>>
>>> Hi all,
>>>
>>> We were discussing on other threads about the need to improve the tools,
>>> ref impls and frameworks we use for openEHR stuff. We are few in the
>>> community working on those areas, and sometimes doing duplicated work and
>>> overlapping solutions.
>>>
>>> I believe if we know who is working on what, we can make a better use of
>>> our collective time as a community, and reuse others work, or even help on
>>> their projects.
>>>
>>> Modeling tools are getting behind the specs progress, tool chain is
>>> broken and needs manual work to get modeling done, open implementation tech
>>> stacks are not complete, etc...
>>>
>>> What if we can publish the areas we are working on, tools that we
>>> already have, and try to coordinate better to fix those issues and
>>> collaborate better as a community?
>>>
>>>
>>> I have created a small google form to gather and share that info, it has
>>> these questions:
>>>
>>> 1. On which areas are you / your company working on? (modeling tools,
>>> CDRs, APIs, ...)
>>> 2. Is code open or planned to be open?
>>> 3. Current status (idea, planned, developing, developed, released, ...)
>>> 4. Main issues and challenges (for the community to help)
>>> 5. Available tools / solutions and where to find them
>>>
>>>
>>> If you see there is another question that can add value to this, please
>>> let me know. After this is complete, I'll share the form. When we have some
>>> answers, I'll publish them on the wiki.
>>>
>>> Hopefully others can this this as an opportunity to move forward on the
>>> modeling and dev areas to increase openEHR adoption.
>>>
>>>
>>> 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
>>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>>>
>>> _______
>>> openEHR-technical mailing list
>>> openehr-techni...@lists.openehr.org
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>>> lists.openehr.org
>>>
>>
>>
>>
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-implemente
>> rs_lists.openehr.org
>>
>
>
>
> --
> 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
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>



-- 
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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Versioning implementations

[Pablo Pazos]

Hi all,

I had this questions in mind for a long time: did someone implemented the
distributed versioning of openEHR?

The specs define a great distributed versioning mechanism but it is a
little trickier to implement. Also there is no clear who will do the work
of managing that, and how that structure will be queried. It is very
difficult to me to think of an amendment sent to an EHR and that not being
available for all the parties looking at the EHR of the patient.

In the case of the EHRServer I built, only linear versioning is possible,
there is only one latest version for each compo, and queries only get data
from latest versions.

Just wondering, what do others did for versioning and what policies do you
have if you implemented the distributed approach in terms of branching,
merging and querying.


Thanks!

-- 
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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Pablo Pazos]

Hi Bert, see below

On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees  wrote:

> Hi Pablo, I did it a few years ago, just dumped not-current versions in a
> slow XML database, because, in normal cases they are never queried, and
> when they need to be queried, there can always be found a faster solution.
>
> But of course, this was a linear version system. ExistDB supports
> distributed versioning on XML out of the box. And you can also use a
> normal, not OpenEHR, version system like Git or VCL.
>
> But when looking at how OpenEHR works, is there ever need of merging? Do
> people edit concurrently same datasets? I think they are they always
> working on new versions of datasets, there is only one exception, that is
> the persistent Composition, there could occur merging problems.
>
> The openEHR versioning mechanism is like Git. The problem I see with this
approach is that real users don't want to deal with that level of
complexity just to track changes in a distributed way. openEHR allows
branching, so if there is no merging, each user can be working on a
different branch, seeing just part of the data. Merging is complex, but
that is needed only if branching is allowed, so the problem is really
branching.

With branches, when a query is executed, it is getting data form the latest
version of the CURRENT branch, potentially missing data from other
branches. This might have patient safety issues also.

That is the main reason I ask this because it is not clear to me that a
good technical solution like distributed versioning, is the best for EHRs.
Moreover considering that most documents will have 1 or 2 versions at most
(talking about event). Of course there will be more versions for persistent
compos.

*Thinking out loud, wouldn't be interesting to have an alternative spec for
versioning where only linear versions are allowed? (IMO that would be
easier to implement even though the current spec includes that case).*


> But I think, you don't need distributed versioning to handle this, a
> locking system (like databases have) is, I think, good enough. That is how
> classic EHR builders handle concurrency.
>
> Bert
>
>
> On 21-06-17 03:04, Pablo Pazos wrote:
>
> Hi all,
>
> I had this questions in mind for a long time: did someone implemented the
> distributed versioning of openEHR?
>
> The specs define a great distributed versioning mechanism but it is a
> little trickier to implement. Also there is no clear who will do the work
> of managing that, and how that structure will be queried. It is very
> difficult to me to think of an amendment sent to an EHR and that not being
> available for all the parties looking at the EHR of the patient.
>
> In the case of the EHRServer I built, only linear versioning is possible,
> there is only one latest version for each compo, and queries only get data
> from latest versions.
>
> Just wondering, what do others did for versioning and what policies do you
> have if you implemented the distributed approach in terms of branching,
> merging and querying.
>
>
> Thanks!
>
> --
> 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
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
>
> ___
> openEHR-implementers mailing 
> listopenEHR-implementers@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
>
>
> _______
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Pablo Pazos]

Hi Bert the case you mention is not versioning control, is concurrence
control. Not sure which system will allow two users to insert invalid data
on an item when the archetype constraint says it is not valid. If that is
an implementation, I don't think it is secure in terms of concurrence.

Versioning would be when a uses commits a document that is "complete". IMO
incomplete compos should not be final versions, and if one user is working
on an incomplete version, no other user can work on that (read-write work).
If two users need to read-write incomplete compos, then 2 separate versions
are needed and there you have branches. Linear versioning would not allow
to create branches, and new versions would not be created until the user
that has the current version in read-write mode finishes and commits the
completed version. That is the only way to keep it linear, with locks.

Not sure about removing the current approach from the specs, but creating a
simpler alternative might be of use to enable more and quicker
implementations.

On Wed, Jun 21, 2017 at 5:42 AM, Bert Verhees  wrote:

> On 21-06-17 10:19, Pablo Pazos wrote:
>
> Hi Bert, see below
>
> On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees 
> wrote:
>
>> Hi Pablo, I did it a few years ago, just dumped not-current versions in a
>> slow XML database, because, in normal cases they are never queried, and
>> when they need to be queried, there can always be found a faster solution.
>>
>> But of course, this was a linear version system. ExistDB supports
>> distributed versioning on XML out of the box. And you can also use a
>> normal, not OpenEHR, version system like Git or VCL.
>>
>> But when looking at how OpenEHR works, is there ever need of merging? Do
>> people edit concurrently same datasets? I think they are they always
>> working on new versions of datasets, there is only one exception, that is
>> the persistent Composition, there could occur merging problems.
>>
>> The openEHR versioning mechanism is like Git. The problem I see with this
> approach is that real users don't want to deal with that level of
> complexity just to track changes in a distributed way. openEHR allows
> branching, so if there is no merging, each user can be working on a
> different branch, seeing just part of the data. Merging is complex, but
> that is needed only if branching is allowed, so the problem is really
> branching.
>
>
> Merging and keeping the data within the constraints of the archetypes is
> nearly impossible to do automated.
> Because, what do you do when person A adds an item to a structure and at
> the same moment person B adds an item to the same structure, but in the
> archetype is defined that in that specific structure only one item is
> allowed.
>
> There you have the problem, inconsistent data because of merging.
>
> I agree with you that distributed versioning is not feasible, even,
> sometimes, dangerous. It would be good to remove it from the specs.
>
> Bert
>
> _______
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

EHRServer v1.0 milestone reached!

[Pablo Pazos]

Hi all,

I'm glad to announce we have reached v1.0, a feature complete and
production ready version.

Mre info about the release:
https://github.com/ppazos/cabolabs-ehrserver/releases/tag/v1.0

Useful info:
+ clients and resources: https://cloudehrserver.com/community
+ documentation: https://www.cabolabs.com/en/projects
+ cloud staging server for you to test:
https://cabolabs-ehrserver.rhcloud.com/

A couple of context articles:
+
https://www.linkedin.com/pulse/cloud-ehrserver-from-proof-concept-software-service-pazos-guti%C3%A9rrez
+
https://www.linkedin.com/pulse/ehrserver-v10-milestone-release-pablo-pazos-guti%C3%A9rrez

This article might be useful:
+ https://www.ncbi.nlm.nih.gov/pubmed/26262007

There are a lot of companies adopting the server as a clinical data
repository backend, and some research projects are being published, like
this one that created the Crypt-EHRServer, an encrypted version of the
EHRServer:
http://i.cs.hku.hk/fyp/2016/fyp16007/documentation/final-report.pdf

If you are working with the EHRServer or know of people doing that, please
let me know :)


Best,
Pablo.

-- 
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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Pablo Pazos]

>From Thomas comments, it is clear that we have such last two use cases,
internal versioning and cross-system versioning / sync / consolidation.

Consider people here is talking about their own experience with the specs
under the use case they implemented. We can argue that internal versioning
is needed in 100% of the implementations while cross-system is a much less
implemented case. This doesn't mean that the current specs are not usable
and useful in abstract, but we should contextualize the discussion by use
case and by the frequency each is implemented.

 For internal versioning it is clear that distributed versioning spec
generate some friction at implementation time. IMO we need to address both
use cases trying to minimize friction for new developers. That can improve
the quality of the specs without print anything out.

Also, I would like to hear more about implementations of both use cases and
the challenges implementers had to really validate the idea of addressing
both use cases explicitly in the specs.

Cheers,
Pablo.


On Aug 18, 2017 5:39 AM, "Seref Arikan" 
wrote:

I did not realise that this discussion reached the point of suggesting that
distributed versioning is taken out from the specs. I have been designing
and implementing lots of openEHR data syncing functionality which relies on
the distributed versioning specifications. I have heaps of work pending,
which will also use that part of the specs. I can tell you that the current
specs have worked just fine for me so far and they are up to the same high
quality as the rest of the specifications, so they are absolutely usable
and useful.

The challenges of distributed versioning does not eliminate the need for
them, so I cannot agree with the suggestion to remove them.  Sure, move
them around in the specs all you want, but please keep them.

All the best
Seref


On Fri, Aug 18, 2017 at 9:15 AM, Thomas Beale 
wrote:

> Hi,
>
> distributed versioning with branching was included to allow syncing of
> data gathered about the same patient in different EHR repositories. For
> most data, syncing the repos is trivial, since it's different data.
>
> The classic cases of potential clashes is medication list, problem list,
> basic clinical demographic data, etc. If a sync was started and two
> medication lists are found that are forks of a single earlier one, a manual
> merge will be required.
>
> We are only just starting to see the implementation of systems where
> syncing may be a question, so although there may be adjustments to make to
> the branched versioning model, I would not be in favour of throwing it out
> at this point.
>
> We are however going to move it to the BASE component and make it a
> standalone model.
>
> - thomas
>
> On 21/06/2017 09:19, Pablo Pazos wrote:
>
> Hi Bert, see below
>
> On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees 
> wrote:
>
>> Hi Pablo, I did it a few years ago, just dumped not-current versions in a
>> slow XML database, because, in normal cases they are never queried, and
>> when they need to be queried, there can always be found a faster solution.
>>
>> But of course, this was a linear version system. ExistDB supports
>> distributed versioning on XML out of the box. And you can also use a
>> normal, not OpenEHR, version system like Git or VCL.
>>
>> But when looking at how OpenEHR works, is there ever need of merging? Do
>> people edit concurrently same datasets? I think they are they always
>> working on new versions of datasets, there is only one exception, that is
>> the persistent Composition, there could occur merging problems.
>>
>> The openEHR versioning mechanism is like Git. The problem I see with this
> approach is that real users don't want to deal with that level of
> complexity just to track changes in a distributed way. openEHR allows
> branching, so if there is no merging, each user can be working on a
> different branch, seeing just part of the data. Merging is complex, but
> that is needed only if branching is allowed, so the problem is really
> branching.
>
> With branches, when a query is executed, it is getting data form the
> latest version of the CURRENT branch, potentially missing data from other
> branches. This might have patient safety issues also.
>
> That is the main reason I ask this because it is not clear to me that a
> good technical solution like distributed versioning, is the best for EHRs.
> Moreover considering that most documents will have 1 or 2 versions at most
> (talking about event). Of course there will be more versions for persistent
> compos.
>
> *Thinking out loud, wouldn't be interesting to have an alternative spec
> for versioning where only linear versions are allowed? (IMO that would be
> easier

RE: Versioning implementations

[Pablo Pazos]

@Bert Persistent records are a well know pattern in ehrs and it's
usefulness should not be under question. Of course systems that focus on
primary care might not implement them. But for hospital or even regional /
national records need a wider view of the patient, persistent shows their
value.

@Bjorn, what is the relationship between a scope and OPTs/folders? The
concepts you mentioned are likely to be modeled with OPTs and folders.
It is very interesting that you didn't need branch versioning yet.

On Aug 20, 2017 6:03 PM, "Bjørn Næss"  wrote:

We are using persistent compositions a lot in our system. These are
compositions with content that lasts and might be updated several times. To
make persistent compositions usable we have introduced “scope”. Examples of
scopes is episode of care, period of care, ward stay, etc. A persistent
compositions contains information where only the latest version holds the
correct data.



So far we haven’t implemented (no need for) branching in versions. But I
know that kind of requirements will come.



I think we should keep persistent compositions (and even extend them) and
the versioning chapters in the specification. The conformance levels will
tell what kind of functions that will be needed in the different profiles.



Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010>



*From:* openEHR-implementers [mailto:openehr-implementers-
boun...@lists.openehr.org] *On Behalf Of *Bert Verhees
*Sent:* lørdag 19. august 2017 15:17
*To:* For openEHR implementation discussions 
*Subject:* Re: Versioning implementations



I agree that merging is (normally) only interesting for persistent
compositions, that are the only kind of compositions which are candidat for
simultaneously editing (branching), and then afterwards merging of the
branches is needed.

I think, getting rid of the persistent compositions would solve these
problems. I don't see objections against medication-lists in normal
compositions. Maybe the persistent composition idea was something from the
old days to have all medications handy together?

If that is so, than we can consider that this way of preordening  is not
anymore needed because modern systems can quickly find medication-entries,
and the extra advantage is that branching and merging is then also not
needed anymore.

Best regards
Bert Verhees



Op vr 18 aug. 2017 15:18 schreef Thomas Beale :



Naturally I am all for revising the specs (it's what we do ;) and throwing
out dead stuff. But one thing I have realised over the years is that many
of the scenarios (such as multi-system syncing) we thought of in the 1990s
and early 200s are only just coming onto the radar now. Progress is much
slower than many of us thought.

Consequently, some types of implementation experience gained so far -
particularly anything cross-enterprise or regional - is not going to be an
indicator to the future. Of course, some kinds of experience, say with
using the RM, or ADL 1.4, AQL etc, has been giving us all the feedback that
we needed to make the updates we are currently making to the specifications.

Probably what we should consider in this case is an update to the Change
control spec that describes a variant or guideline for using the model to
implement linear versioning, while allowing for later addition of branched
versioning when/if needed.

- thomas



On 18/08/2017 12:49, Pablo Pazos wrote:

>From Thomas comments, it is clear that we have such last two use cases,
internal versioning and cross-system versioning / sync / consolidation.



Consider people here is talking about their own experience with the specs
under the use case they implemented. We can argue that internal versioning
is needed in 100% of the implementations while cross-system is a much less
implemented case. This doesn't mean that the current specs are not usable
and useful in abstract, but we should contextualize the discussion by use
case and by the frequency each is implemented.



 For internal versioning it is clear that distributed versioning spec
generate some friction at implementation time. IMO we need to address both
use cases trying to minimize friction for new developers. That can improve
the quality of the specs without print anything out.



Also, I would like to hear more about implementations of both use cases and
the challenges implementers had to really validate the idea of addressing
both use cases explicitly in the specs.



Cheers,

Pablo.





On Aug 18, 2017 5:39 AM, "Seref Arikan" 
wrote:

I did not realise that this discussion reached the point of suggesting that
distributed versioning is taken out from the specs. I have been designing
and implementing lots of openEHR data syncing functionality which relies on
the distributed versioning specifications. I have heaps of work pending,
which will also use that part of the specs. I can tell you that the current
specs have work

Re: Versioning implementations

[Pablo Pazos]

Hi Bert, excellent questions!

On Aug 21, 2017 5:55 AM, "Thomas Beale"  wrote:


On 21/08/2017 09:09, Bert Verhees wrote:

> On 21-08-17 02:51, Pablo Pazos wrote:
>
>> @Bert Persistent records are a well know pattern in ehrs and it's
>> usefulness should not be under question. Of course systems that focus on
>> primary care might not implement them. But for hospital or even regional /
>> national records need a wider view of the patient, persistent shows their
>> value.
>>
> Hi Pablo, two questions
>
> Which problem do you solve with persistent records which cannot be solved
> in another way? Do you agree that persistent records are the only reason to
> have branching/merging necessary?
>

well they are likely to be the most common element of an EHR to which
branches and merging would be applied. However they are ubiquitous and are
also likely to be extended to things like care plans and so on. But in
principle, branch and merge could happen to anything in the record, e.g.
for reasons like adding competing translations of clinical notes etc.

- thomas





Adding to Thomas, we can view this from three points of view: technical
implementation, clinical modeling, and spec. My previous comments about
persistent records are spec related. As Thomas said, _how_ things are done
using the spec will depend on modelers, and also implementers.

>From the spec, I see persistent records as a framework to record everything
that is conceptually a Singleton (one instance across the whole patient
EHR). Then if that can or can't be modeled as an event record, is a
discussion for clinical modelers, but I think that doesn't diminish the
need of such a concept on the specs.

Versioning and branching is an ortogonal concept to event/persistent
records and can be used in any case. The _how_ versioning/branching is used
has a lot to do with implementers and that is related to my initial
question, and the hunch that maybe other devs like me found
branching/merging an friction point (related to complexity) for the most
frequent & simple implementations of openEHR, but knowing there are less
frequent implementations that make extensive use of branching and merging.

>From the current answers to this thread, I see the need of a simplified or
relaxed versioning model, that maybe is just a constraint over the current
version control, allowing only certain versioning patterns, like lineal
versioning, and some control mechanisms like versioning lock/release,
access to read-only records, etc. These are not changes to the current
spec, but additions as specs or as guidelines.

What do others think?




___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implemente
rs_lists.openehr.org
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Pablo Pazos]

I agree. The singleton is not one persistent compo, but the instance
associated with an OPT of a persistent compo. When talking about singleton
instances we should define what is considered the "class" :) My mistake.

In the case of care plans, different care plans will be defined by
different OPTs, same for medication lists if needed and modeled that way
(some systems might only need one medication list, one problem list, etc.
by EHR).

But again, these are all clinical modeling decisions. A bad model might
represent different care plans with the same OPT, and of course this breaks
the singleton concept, but we are talking about subjectiveness here, so
there are no hard rules (call it probabilistic singleton).


Best,
Pablo.


On Mon, Aug 21, 2017 at 5:40 PM, Bert Verhees  wrote:

> Pablo, one small remark, a persistent composition is not really a
> singleton. Not conceptually. A patient can have more care - plans, for
> example, at different care - institutions or multiple care - takers at a
> single institution, or have multiple medication-lists.
>
> Bert
>
> On ma 21 aug. 2017 19:24 Pablo Pazos  wrote:
>
>> Hi Bert, excellent questions!
>>
>>
>> On Aug 21, 2017 5:55 AM, "Thomas Beale"  wrote:
>>
>>
>> On 21/08/2017 09:09, Bert Verhees wrote:
>>
>>> On 21-08-17 02:51, Pablo Pazos wrote:
>>>
>>>> @Bert Persistent records are a well know pattern in ehrs and it's
>>>> usefulness should not be under question. Of course systems that focus on
>>>> primary care might not implement them. But for hospital or even regional /
>>>> national records need a wider view of the patient, persistent shows their
>>>> value.
>>>>
>>> Hi Pablo, two questions
>>>
>>> Which problem do you solve with persistent records which cannot be
>>> solved in another way? Do you agree that persistent records are the only
>>> reason to have branching/merging necessary?
>>>
>>
>> well they are likely to be the most common element of an EHR to which
>> branches and merging would be applied. However they are ubiquitous and are
>> also likely to be extended to things like care plans and so on. But in
>> principle, branch and merge could happen to anything in the record, e.g.
>> for reasons like adding competing translations of clinical notes etc.
>>
>> - thomas
>>
>>
>>
>>
>>
>> Adding to Thomas, we can view this from three points of view: technical
>> implementation, clinical modeling, and spec. My previous comments about
>> persistent records are spec related. As Thomas said, _how_ things are done
>> using the spec will depend on modelers, and also implementers.
>>
>> From the spec, I see persistent records as a framework to record
>> everything that is conceptually a Singleton (one instance across the whole
>> patient EHR). Then if that can or can't be modeled as an event record, is a
>> discussion for clinical modelers, but I think that doesn't diminish the
>> need of such a concept on the specs.
>>
>> Versioning and branching is an ortogonal concept to event/persistent
>> records and can be used in any case. The _how_ versioning/branching is used
>> has a lot to do with implementers and that is related to my initial
>> question, and the hunch that maybe other devs like me found
>> branching/merging an friction point (related to complexity) for the most
>> frequent & simple implementations of openEHR, but knowing there are less
>> frequent implementations that make extensive use of branching and merging.
>>
>> From the current answers to this thread, I see the need of a simplified
>> or relaxed versioning model, that maybe is just a constraint over the
>> current version control, allowing only certain versioning patterns, like
>> lineal versioning, and some control mechanisms like versioning
>> lock/release, access to read-only records, etc. These are not changes to
>> the current spec, but additions as specs or as guidelines.
>>
>> What do others think?
>>
>>
>>
>>
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> implementers_lists.openehr.org
>>
>>
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> implementers_lists.openehr.org
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_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-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Info request about openEHR implementations for a presentation

[Pablo Pazos]

Hi all,

I'm giving a talk about openEHR next month in Argentina and the
organization asked me to mention something about openEHR implementations
especially in Latin America. You know the typical stuff, where it was
implemented, why openEHR, for what it is used, challenges, benefits,
lessons learned, etc.

Since I don't have much info I ask for your help to gather some info. I
know Thomas, Jussara and people from Marand know more than me about openEHR
in Brazil, if you can assist me with some info would be great.

I'm not sure if there's info from other countries that would help me bring
a bigger picture. Any help would be really welcome, and I think as more
info is gathered, more interest we can get from newcomers. This event in
Argentina is very popular and there will be a lot of clinicians.

Also if you have info about implementations in other countries outside
Latin America, would be useful. All the info I have is on the openEHR
website but it doesn't have insights like challenges, benefits and lessons
learned from those implementations.


Thanks,
Pablo.

-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Info request about openEHR implementations for a presentation

[Pablo Pazos]

It's a pity we don't have much info about openEHR implementations in Latin
America :(

On Wed, Sep 27, 2017 at 11:08 PM, Pablo Pazos 
wrote:

> Hi all,
>
> I'm giving a talk about openEHR next month in Argentina and the
> organization asked me to mention something about openEHR implementations
> especially in Latin America. You know the typical stuff, where it was
> implemented, why openEHR, for what it is used, challenges, benefits,
> lessons learned, etc.
>
> Since I don't have much info I ask for your help to gather some info. I
> know Thomas, Jussara and people from Marand know more than me about openEHR
> in Brazil, if you can assist me with some info would be great.
>
> I'm not sure if there's info from other countries that would help me bring
> a bigger picture. Any help would be really welcome, and I think as more
> info is gathered, more interest we can get from newcomers. This event in
> Argentina is very popular and there will be a lot of clinicians.
>
> Also if you have info about implementations in other countries outside
> Latin America, would be useful. All the info I have is on the openEHR
> website but it doesn't have insights like challenges, benefits and lessons
> learned from those implementations.
>
>
> Thanks,
> Pablo.
>
> --
> Ing. Pablo Pazos Gutiérrez
> e: pablo.pa...@cabolabs.com
> p: +598 99 043 145 <099%20043%20145>
> skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>



-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Mandatory elements in archetypes, and user interfaces

[Pablo Pazos]

Hi, there are several cases:

1. data recorded by the software: when a data element is added to the
composition by the software, doesn't need a UI element at all

2. recording null flavour: if no data is entered on the UI field (field is
not mandatory on UI), null_flavour is recorded on the element. null_flavour
can be set by the system, or there can be a null_flavour field on the UI to
let the user specify why there is no data on the field, on this case what
can be mandatory is the data field or the null_flavour for that field.

Hope that helps.



On Fri, Nov 10, 2017 at 7:47 AM, Bakke, Silje Ljosland <
silje.ljosland.ba...@nasjonalikt.no> wrote:

> Crossposting this between the clinical and implementers lists, since it
> belongs in both:
>
>
>
> In some archetypes, one or more elements are set as mandatory (typically
> occurrences 1..1 or 1..*), because the rest of the concept makes no sense
> without this particular element recorded. Examples are Problem/diagnosis
> name in Problem/diagnosis, and Temperature in Body temperature. This is not
> intended to mean that it’s mandatory to enter data into the element in a
> UI, but that this particular element is mandatory in any persisted
> composition that uses the archetype.
>
>
>
> Recently however, we received a request to change the Head circumference
> element in the Head circumference archetype from 1..1 to 0..1 because the
> element being mandatory in the archetype automatically made the UI form
> builder mandate the entering of data into the UI field, and removing the
> archetype on the fly made more unnecessary clicks. In a fit of mental
> hiccups, I agreed with and performed this change, but have since realised
> this is wrong, because:
>
> ·   A mandatory archetype element is not the same as a mandatory UI
> field
>
> ·   A mandatory UI field is more like a field where you only allow
> persisting non *null* values, while a mandatory archetype element can be
> persisted with a * null* value without a problem.
>
>
>
> How are implementers actually handling this? Do you separate UI field
> mandation and archetype element mandation?
>
>
>
> Kind regards,
> *Silje Ljosland Bakke*
>
>
>
> Information Architect, RN
>
> Coordinator, National Editorial Board for Archetypes
> Nasjonal IKT HF, Norway
>
> Tel. +47 40203298 <+47%20402%2003%20298>
>
> Web: http://arketyper.no / Twitter: @arketyper_no
> <https://twitter.com/arketyper_no>
>
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>



-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

How do you identify OPTs in your implementation?

[Pablo Pazos]

Hi openEHR implementers!

I have a question about how do you identify operational templates in your
systems, since the Template Designer doesn't enforce any template ID
format, but we have a format defined in v1.0.2 of the specs (
http://www.openehr.org/releases/RM/Release-1.0.2/docs/support/support.html#_template_identifiers
).

In the current version of the specs, the template ID format is to be
defined.

On the other hand, in my implementation it would be useful to have the
language included in the template ID, because that helps to identify two
templates that have really the same structure but are defined for different
languages (mine is a multi-language implementation).

Would love to hear what format are you using for template IDs.

Thanks!

-- 
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com
p: +598 99 043 145
skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Announcing Archie version 0.4

[Pablo Pazos]

Thanks Pieter, I'm sure we will use it when adl 2 time arrive for us, we
are still on 1.4.

On Feb 3, 2018 9:04 AM, "Pieter Bos"  wrote:

Or a Java app with rest api and a JavaScript frontend. Let the java
application take care of parsing, validating, flattening, operational
template creation etc and send json to your front end. Archie has built-in
json serialization and deserialization support.

Pieter

Op 3 feb. 2018 om 12:05 heeft Seref Arikan mailto:serefari...@kurumsalteknoloji.com>> het
volgende geschreven:

Hi Peter,

Presumably via use of a transpiler or a bytecode to js/webassembly compiler.

On Sat, Feb 3, 2018 at 10:56 AM, Peter Gummer mailto:peter.gum...@gmail.com>> wrote:
On 1 Feb 2018, at 05:13, Thomas Beale > wrote:

... But the main interest is that we will be able to build new tools such
as a Java/JS replacement for the ADL Workbench, and of course things like a
high-quality, BMM-driven runtime archetype validating kernel for EHR
systems, workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how
Archie (written in Java, disappointingly) would enable JavaScript
implementations. JavaScript has nothing in common with Java (apart from the
name).

Peter


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

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

Is partial datetime pattern (yyyy-mm-ddTHH:??:??) equivalent to "any allowed"?

[Pablo Pazos]

Hi,

I'm digging into the specs again, and testing the modeling tools to produce
different constraints for DV_DATE_TIME.

When I analyzed the partial datetime pattern -mm-ddTHH:??:?? that
allows optional minutes and seconds, and the constraints that would
correspond to "any allowed" it seems both are the same. I'll explain.

"any allowed" for DV_DATE_TIME would be any value that actually is a
datetime. For instance "1999-01-01" is not a datetime, so "any allowed
should check for datetime that at least has hours, that is something like
"1999-01-01T16".

Having "1999-01-01" as a datetime would be a type mismatch if we are
strict. With relaxed rules we can say "1999-01-01" is equivalent to
"1999-01-01T00:00:00", but we are assuming something that might not be the
intent of the user that inputs the data. Since this is health date, I
prefer the strict approach.

But if we have the partial datetime pattern, that is validating the same,
that at least the hours are there, then minutes and seconds are optional.


   1. Invalid datetime like "546454" won't be valid on any allowed or
   partial pattern
   2. Date only like "1999-01-01" won't be valid on any allowed or partial
   pattern, since it is not a datetime, is date
   3. Date with hours, will be valid on both
   4. Date with hours and minutes, will be valid on both
   5. Date with hours, minutes and seconds will be valid on both

(on all cases timezone information can be added, if it is not present, UTC
is default)


Considering this, it seems both are equivalent. So why allow both?

IMO this generates a point where implementers can have different
interpretations and implement both constraints in a different way (any
allowed and partial pattern).


What do others think?


Thanks!

-- 
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Is partial datetime pattern (yyyy-mm-ddTHH:??:??) equivalent to "any allowed"?

[Pablo Pazos]

Hi Gerard, this is about the current specs and what is supported by
modeling tools, not about the interpretation of what a duration is. I
detected two different constraints that might be equivalent and that's not
clear on the current specs

On Mon, Mar 19, 2018, 05:14 GF  wrote:

> My ideas about this topic.
>
> Two distinct different times we need to consider:
> -Time (physical) at the system level to be used for Timestamps, including
> Time zone
> Chronos is the greek deity associated with it.
> A specific generic data type will deal with this.
> - Time as used by humans. Including Time zone but also things like week,
> autumn, midnight, and associated time relationships like before, after,
> during, overlapping, etc.
> The associated Greek deity is Chairos.
>
> The *Chronos Time* is modelled using a data type.
> The *Chairos Time* is modelled via Archetypes  using the Data Types but
> augmented with attributes taken from the proper ontologies.
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 19 Mar 2018, at 01:56, Pablo Pazos  wrote:
>
> Hi,
>
> I'm digging into the specs again, and testing the modeling tools to
> produce different constraints for DV_DATE_TIME.
>
> When I analyzed the partial datetime pattern -mm-ddTHH:??:?? that
> allows optional minutes and seconds, and the constraints that would
> correspond to "any allowed" it seems both are the same. I'll explain.
>
> "any allowed" for DV_DATE_TIME would be any value that actually is a
> datetime. For instance "1999-01-01" is not a datetime, so "any allowed
> should check for datetime that at least has hours, that is something like
> "1999-01-01T16".
>
> Having "1999-01-01" as a datetime would be a type mismatch if we are
> strict. With relaxed rules we can say "1999-01-01" is equivalent to
> "1999-01-01T00:00:00", but we are assuming something that might not be the
> intent of the user that inputs the data. Since this is health date, I
> prefer the strict approach.
>
> But if we have the partial datetime pattern, that is validating the same,
> that at least the hours are there, then minutes and seconds are optional.
>
>
>1. Invalid datetime like "546454" won't be valid on any allowed or
>partial pattern
>2. Date only like "1999-01-01" won't be valid on any allowed or
>partial pattern, since it is not a datetime, is date
>3. Date with hours, will be valid on both
>4. Date with hours and minutes, will be valid on both
>5. Date with hours, minutes and seconds will be valid on both
>
> (on all cases timezone information can be added, if it is not present, UTC
> is default)
>
>
> Considering this, it seems both are equivalent. So why allow both?
>
> IMO this generates a point where implementers can have different
> interpretations and implement both constraints in a different way (any
> allowed and partial pattern).
>
>
> What do others think?
>
>
> Thanks!
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: API's

[Pablo Pazos]

I would say the current API is a platform API, not an end-user app API. I
would expect more domain semantic richness on an end-user app API.

I think in the future we'll need both, but the end-use app API would be
more implementation dependent, but we can reach some kind of agreement to
have some basic set of common services.

On Sun, Jul 15, 2018 at 6:19 AM, Thomas Beale 
wrote:

> Bert,
>
> the addition of business-level transactional APIs, e.g for medication
> list, e-pharmacy, or other business level functions is certainly intended
> and envisaged. It's just not the first step.
>
> Such APIs would convert relatively simple transactional concepts e.g.
> get_medication_list(), suspend_medication() etc to what may be non-trivial
> information structures defined by specific archetypes, which would be
> valuable for the reasons you say. Also: they improve data interoperability
> because complex structures (say, Care Plans) are guaranteed to always be
> the correct structure due to the API, whereas manual creation might end up
> with different variations.
>
> - thomas
>
> On 15/07/2018 00:00, Bert Verhees wrote:
>
> Today I looked at the OpenEhr API:
> https://www.openehr.org/releases/ITS/latest/ehr_restapi.html#top
>
> I live sometime in the OpenEhr world, so I am not surprised that it is a
> rather low level API. In fact it is a bit hard to recognize quick what it
> is about. And it fits perfectly to the philosophy of OpenEhr. The API is
> not semantically rich. It are the archetypes which are semantically rich,
> the API IS GENERIC. So it is fine. I am not criticizing.
>
> I found another API on the Internet, in fact, I found many. They are all
> semantically rich. They all have functions like "Which medication does the
> patient take".
>
> In OpenEhr there is only a function to execute a query to find
> semantically meaningful data. The API itself offers no further clues.
>
> Again, this is not criticizing,  it fits in the philosophy of OpenEhr. It
> is impossible to write queries for the customers, because we do not know
> the archetypes they use. The customer is helpless without the expertise of
> OpenEhr specialists, of which are not many people on the world. I think,
> from marketing point of view this is hard to sell, because other vendors
> offer semantically rich API's out of the box. Only a web developer, without
> special education is then needed to write a GUI.
>
> I think it is not necessary that it is that way. The premise that we don't
> know which archetypes customers use is not always true. In fact, from many
> customers it is known that they use archetypes from CKM. So, my point:
>
> How nice would it be when CKM would publicly be extended with queries
> which fit on the archetypes, which can be used to create a semantically
> rich API.
>
> This would have to advantages.
> 1) It would be a strong marketing point. An OpenEhr customer would not
> anymore need expensive expertise to do simple things like querying which
> medication a patient uses.
> 2) It would motivate customers to use CKM archetypes (Which maybe do not
> use them now, or edit them without telling anyone, and maybe even without
> changing the identifier) because this would then have an extra advantage to
> stay closely connected to CKM.
>
> Someone having any thoughts about this?
>
> Bert
>
>
> ___
> openEHR-implementers mailing 
> listopenEHR-implementers@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Project, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/> | The Objective Stance
> <https://theobjectivestance.net/>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> implementers_lists.openehr.org
>
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: API's

[Pablo Pazos]

Hi Bert,

We don't "wait" for agreement, we "actionate" agreement as we did for the
platform API that was already released.

Any proposal should be specified for the SEC to review, agree, refine and
publish.

Not sure how this approach can take forever  if the proposal makes sense.

Best,
Pablo.

On Mon, Jul 16, 2018, 06:51 Bert Verhees  wrote:

> Heather and Pablo,
>
> First for Heather: Thanks for being open on your concerns.
> I think that the reply from Pablo is also important. He pledges (like you
> but more explitly) for common ground on API's, of course also for
> application specific API's.
>
> But that common ground needs to be defined first as a starting point.
> Inspiration could be found in the link I send as a reply to Thomas,
> yesterday.
>
> And for that common ground writing AQL would not be that hard, and it
> would be necessary.
>
> But I also tast in the reply of Pablo something like wanting to wait until
> there is an agreement. I don't think that will work. Waiting for agreements
> can take forever. It is a plan without time frame.
>
> Better is to look for agreements (agreed API) with suitable partners, and
> when they are found, some pressure will grow on the market, and that can
> make commercial motivated funders see the importance of that agreement of
> which CKM is from the OpenEhr side indispensable.
>
> There is, however, one important step. The agreement can only be platform
> independent, not only at the front side, but also on the backend side.
> Here we do it with OpenEhr, others will do it with FHIR messaging, and
> others will create layers between vendor API's and the agreed API.
>
> The profit will be in the marketpressure caused by that common API, and
> the platform-differences will be in what is outside the agreement.
>
> Bert.
>
>
> Op ma 16 jul. 2018 02:39 schreef Heather Leslie <
> heather.les...@atomicainformatics.com>:
>
>> Hi Bert,
>>
>>
>>
>> I totally agree with your view that CKM would carry AQL queries that
>> could be reviewed and potentially published in the same way that the
>> archetypes and templates are. I think it would have enormous impact on
>> healthIT and unleashing the power of openEHR and atomic data.
>>
>>
>>
>> It was a high priority in my strategic plan for CKM but I wasn’t able to
>> get inhouse resources when CKM was my responsibility.  Now it is in the
>> hands of whoever is the new product manager for CKM and the new funders of
>> Ocean to assign the resources, although judging by their previous business
>> priorities I am concerned that CKM may not be a high priority item.
>>
>>
>>
>> I’d be ecstatic to be proved wrong.
>>
>>
>>
>> Regards
>>
>>
>>
>> Heather
>>
>>
>>
>>
>>
>>
>>
>> *From:* openEHR-implementers <
>> openehr-implementers-boun...@lists.openehr.org> *On Behalf Of *Bert
>> Verhees
>> *Sent:* Sunday, 15 July 2018 9:00 AM
>> *To:* For openEHR implementation discussions <
>> openehr-implementers@lists.openehr.org>
>> *Subject:* API's
>>
>>
>>
>> Today I looked at the OpenEhr API:
>>
>> https://www.openehr.org/releases/ITS/latest/ehr_restapi.html#top
>>
>>
>>
>> I live sometime in the OpenEhr world, so I am not surprised that it is a
>> rather low level API. In fact it is a bit hard to recognize quick what it
>> is about. And it fits perfectly to the philosophy of OpenEhr. The API is
>> not semantically rich. It are the archetypes which are semantically rich,
>> the API IS GENERIC. So it is fine. I am not criticizing.
>>
>>
>>
>> I found another API on the Internet, in fact, I found many. They are all
>> semantically rich. They all have functions like "Which medication does the
>> patient take".
>>
>>
>>
>> In OpenEhr there is only a function to execute a query to find
>> semantically meaningful data. The API itself offers no further clues.
>>
>>
>>
>> Again, this is not criticizing,  it fits in the philosophy of OpenEhr. It
>> is impossible to write queries for the customers, because we do not know
>> the archetypes they use. The customer is helpless without the expertise of
>> OpenEhr specialists, of which are not many people on the world. I think,
>> from marketing point of view this is hard to sell, because other vendors
>> offer semantically rich API's out of the box. Only a web developer, without
>> special education is then needed to write a GUI.
>>
>>
>>
>> I think it is not necessary that it is that way. The premise that we
>> don't know which archetypes customers use is not always true. In fact, from
>> many customers it is known that they use archetypes from CKM. So, my point:
>>
>>
>>
>> How nice would it be when CKM would publicly be extended with queries
>> which fit on the archetypes, which can be used to create a semantically
>> rich API.
>>
>>
>>
>> This would have to advantages.
>>
>> 1) It would be a strong marketing point. An OpenEhr customer would not
>> anymore need expensive expertise to do simple things like querying which
>> medication a patient uses.
>>
>> 2) It would motivate customers to use CKM arch

Re: query writing question 2

[Pablo Pazos]

Recently we discussed other problematic cases, like having criteria over a
structured datatype like:

WHERE /data[at0001]/items[at0004]/value/magnitude >= 140 AND
/data[at0001]/items[at0004]/value/units = "mmHg"

Internally that should be interpreted as "magnitude" and "units" should be
attributes of the same DV_QUANTITY instance, but do all AQL implementations
actually do that?


But maybe that kind of query should be written as:

WHERE dv/magnitude >= 140 AND dv/units = "mmHg"

In that case, dv should be defined in the FROM, and all variables/aliases
should point to the same data instance.

On Mon, Oct 8, 2018 at 3:06 PM Georg Fette 
wrote:

> Hello,
> I have another question concerning the semantics of AQL queries:
> In the documentation there are queries of the form
> SELECT a/data[at0001]/items[at0004]/value
> FROM EHR e CONTAINS COMPOSITION a[openEHR-EHR-COMPOSITION.encounter.v1]
> WHERE b/data[at0001]/items[at0004]/value/value >= 140
> What ensures that the identified path in the SELECT section references
> the same data instances that are contrained with the same identified
> path in the WHERE section ? It could be argued that there is only one
> "data[at0001]" in "b" and only one "items[at0004]" in "a/data[at0001]"
> and so on. But is this already the full explanation for the expression
> to be unambiguous ? The aliases used in queries (e.g. "a") ensures that
> a reference to an alias definitely means the same instance. Looking at
> queries like the one above let assume that aliases are only syntactic
> sugar and are not functionally needed. Is this correct ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Pablo Pazos]

Hi Seref, see below :)

On Tue, Oct 9, 2018 at 5:19 AM Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> Hi Pablo, see inline please
>
> On Mon, Oct 8, 2018 at 8:29 PM Pablo Pazos 
> wrote:
>
>> Recently we discussed other problematic cases, like having criteria over
>> a structured datatype like:
>>
>> WHERE /data[at0001]/items[at0004]/value/magnitude >= 140 AND 
>> /data[at0001]/items[at0004]/value/units
>> = "mmHg"
>>
>> Internally that should be interpreted as "magnitude" and "units" should
>> be attributes of the same DV_QUANTITY instance, but do all AQL
>> implementations actually do that?
>>
>
> Who knows? :) the syntax is correct though, so what they do internally
> does not matter, the WHERE clause is clearly introducing two constraints on
> the same DV_QUANTITY instance.
>

That should be defined by the spec to avoid inconsistent implementations.

On the other hand, paths might not reference the same data instance,
consider multiple occurrences of the ELEMENT in
/data[at0001]/items[at0004],
the only way to be sure that references the same data instance is by doing
something like /data[at0001]/items[at0004][0]/value/... or
/data[at0001]/items[at0004][1]/value/...
without the index, paths references a list of objects.



>
>
>>
>>
>> But maybe that kind of query should be written as:
>>
>> WHERE dv/magnitude >= 140 AND dv/units = "mmHg"
>>
>> In that case, dv should be defined in the FROM, and all variables/aliases
>> should point to the same data instance.
>>
>
> this is also valid AQL but you may have two problems here:
>
> 1) AQL implementations may not support the full AQL semantics. That is,
> even though EHR e[..] CONTAINS DV_QUANTITY dv is legal AQL a particular
> back end may not support it.
>

I was thinking about EHR CONTAINS OBSERVATION CONTAINS  CONTAINS
DV_QUANTITY dv, not directly referencing a DV from the EHR, but as you
said, it is valid.

The CONTAINS also has to handle the multiple occurrences of contained items
on attributes that are collections.


> In your example snippet, the FROM statement (which we don't see) should
> have an . Now to use the dv alias as you've suggested, that FROM
> claused would have to become: /data[at0001]/items[at0004]/value as dv
> and this is the case a back end may not support, or all back ends may not
> support because a common thinking among vendors is users would select more
> meaningful/high-level nodes (mostly entries or clusters under them) and
> access data via SELECT or apply criteria in WHERE clauses using relative
> paths.
>
> 2) if you'd like to apply two criteria to , then you have to declare
>  in FROM clause and do WHERE xxx/path1/value  AND
> xxx/path2/value  So you have to define  here, if you do what
> I described above, you only have DV_QUANTITY leaf node and you cannot
> introduce constraints to other nodes relative to . So you have pros and
> cons or 'high level nodes giveth and taketh away'...
>
> Another option, which should actually be legal given the current AQL
> grammar may be to move all constraints on xxx to the immediate predicate of
>  but this should be used only when there is no ambiguity. As in:
>
> FROM . CONTAINS [data/items/value/magnitude >= 140 AND
> data/items/value/units = 'mmHg']
>

wow, that is nice :)



>
> This would neatly move the joint criteria up but I would be uncomfortable
> with this because you cannot specify archetype node ids for data[]/items[]
> anymore and this would likely trigger a cartesian explosion in result sets.
> Then you'd have Ian complaining about duplicate results ;)
>
> All the best
> Seref
>
>
>> On Mon, Oct 8, 2018 at 3:06 PM Georg Fette 
>> wrote:
>>
>>> Hello,
>>> I have another question concerning the semantics of AQL queries:
>>> In the documentation there are queries of the form
>>> SELECT a/data[at0001]/items[at0004]/value
>>> FROM EHR e CONTAINS COMPOSITION a[openEHR-EHR-COMPOSITION.encounter.v1]
>>> WHERE b/data[at0001]/items[at0004]/value/value >= 140
>>> What ensures that the identified path in the SELECT section references
>>> the same data instances that are contrained with the same identified
>>> path in the WHERE section ? It could be argued that there is only one
>>> "data[at0001]" in "b" and only one "items[at0004]" in "a/data[at0001]"
>>> and so on. But is this already the full explanation for the expression
>>> to be unambiguous ? The aliases used in querie

Re: query writing question 2

[Pablo Pazos]

I like this!

On Tue, Oct 9, 2018 at 11:22 AM Thomas Beale 
wrote:

> The correct way to do this IMO, and my earliest idea for AQL in about 2006
> was using archetype fragments, which are a kind of Frame-logic approach,
> formally. Today, people think in terms of GraphQL, but you need constraints.
>
> E.g.
>
> WHERE
> dv matches {
> magnitude matches {|>=140.0|}
>units matches {"mm[Hg]"}
> }
>
> Or, more readably:
>
> WHERE
> dv ∈ {
> magnitude ∈ {|>=140.0|}
>    units ∈ {"mm[Hg]"}
> }
>
> - thomas
>
> On 08/10/2018 16:27, Pablo Pazos wrote:
>
>
>
> But maybe that kind of query should be written as:
>
> WHERE dv/magnitude >= 140 AND dv/units = "mmHg"
>
>
>
> --
> Thomas Beale
> Principal, Ars Semantica <http://www.arssemantica.com>
> Consultant, ABD Project, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/> | The Objective Stance
> <https://theobjectivestance.net/>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Pablo Pazos]

On Wed, Oct 10, 2018, 07:10 David Moner  wrote:

>
>
> El mié., 10 oct. 2018 a las 11:52, Seref Arikan (<
> serefari...@kurumsalteknoloji.com>) escribió:
>
>>
>> Obligatory moaning for the millionth time: All of this confusion stems
>> from lack of a formal model defining AQL semantics. I used tree pattern
>> queries in my research so I can use those to explain aql, but as it stands
>> the standard we have does not have this so users will keep getting
>> confused.
>>
>>>
>>>
> This. A query language is more than just a syntax. And probably we don't
> need to invent different behaviors than technologies that already work
> (XPath/XQuery, for example)
>

That is exactly why I didn't implement AQL yet, the spec should include
syntax, behavior, semantics and result sets defined. And lots of examples
of those things combined. Because impregnada should include parser+engine
and the parser is the simple part. Until we have that all implementations
will have differences when querying the same database.


> --
> David Moner Cano
>
> Web: http://www.linkedin.com/in/davidmoner
> Twitter: @davidmoner
> Skype: davidmoner
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Pablo Pazos]

"impregnada" should be "implementations", damn phone auto correction :P

That is exactly why I didn't implement AQL yet, the spec should include
syntax, behavior, semantics and result sets defined. And lots of examples
of those things combined. Because *implementations* should include
parser+engine and the parser is the simple part. Until we have that all
implementations will have differences when querying the same database.

On Wed, Oct 10, 2018 at 4:23 PM Pablo Pazos 
wrote:

>
>
> On Wed, Oct 10, 2018, 07:10 David Moner  wrote:
>
>>
>>
>> El mié., 10 oct. 2018 a las 11:52, Seref Arikan (<
>> serefari...@kurumsalteknoloji.com>) escribió:
>>
>>>
>>> Obligatory moaning for the millionth time: All of this confusion stems
>>> from lack of a formal model defining AQL semantics. I used tree pattern
>>> queries in my research so I can use those to explain aql, but as it stands
>>> the standard we have does not have this so users will keep getting
>>> confused.
>>>
>>>>
>>>>
>> This. A query language is more than just a syntax. And probably we don't
>> need to invent different behaviors than technologies that already work
>> (XPath/XQuery, for example)
>>
>
> That is exactly why I didn't implement AQL yet, the spec should include
> syntax, behavior, semantics and result sets defined. And lots of examples
> of those things combined. Because impregnada should include parser+engine
> and the parser is the simple part. Until we have that all implementations
> will have differences when querying the same database.
>
>
>> --
>> David Moner Cano
>>
>> Web: http://www.linkedin.com/in/davidmoner
>> Twitter: @davidmoner
>> Skype: davidmoner
>> ___
>> openEHR-implementers mailing list
>> openEHR-implementers@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>>
>

-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: query writing question 2

[Pablo Pazos]

@Diego Boscá Tomás  about the technology, look at
this thing https://www.arangodb.com/

Search for AQL (funny name for a generic query language :P), but it seems
strangely nice to be use to implement an openEHR AQL backend, since it can
be used to query many backend technologies, is another abstraction layer.
I'll test this thing when I have time, would love to hear from others that
test it.

On Fri, Oct 12, 2018 at 11:22 PM Pablo Pazos 
wrote:

> "impregnada" should be "implementations", damn phone auto correction :P
>
> That is exactly why I didn't implement AQL yet, the spec should include
> syntax, behavior, semantics and result sets defined. And lots of examples
> of those things combined. Because *implementations* should include
> parser+engine and the parser is the simple part. Until we have that all
> implementations will have differences when querying the same database.
>
> On Wed, Oct 10, 2018 at 4:23 PM Pablo Pazos 
> wrote:
>
>>
>>
>> On Wed, Oct 10, 2018, 07:10 David Moner  wrote:
>>
>>>
>>>
>>> El mié., 10 oct. 2018 a las 11:52, Seref Arikan (<
>>> serefari...@kurumsalteknoloji.com>) escribió:
>>>
>>>>
>>>> Obligatory moaning for the millionth time: All of this confusion stems
>>>> from lack of a formal model defining AQL semantics. I used tree pattern
>>>> queries in my research so I can use those to explain aql, but as it stands
>>>> the standard we have does not have this so users will keep getting
>>>> confused.
>>>>
>>>>>
>>>>>
>>> This. A query language is more than just a syntax. And probably we don't
>>> need to invent different behaviors than technologies that already work
>>> (XPath/XQuery, for example)
>>>
>>
>> That is exactly why I didn't implement AQL yet, the spec should include
>> syntax, behavior, semantics and result sets defined. And lots of examples
>> of those things combined. Because impregnada should include parser+engine
>> and the parser is the simple part. Until we have that all implementations
>> will have differences when querying the same database.
>>
>>
>>> --
>>> David Moner Cano
>>>
>>> Web: http://www.linkedin.com/in/davidmoner
>>> Twitter: @davidmoner
>>> Skype: davidmoner
>>> ___
>>> openEHR-implementers mailing list
>>> openEHR-implementers@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>>>
>>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
> <https://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
>
>

-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: How to write Github commit messages to connect to openEHR Jira issues

[Pablo Pazos]

 Access denied

You do not have the correct permissions to view the page: *GitHub
Configuration*

Please request access from your Atlassian Cloud administrator.

On Thu, Apr 11, 2019 at 1:08 PM Thomas Beale 
wrote:

> We have been doing this for a few years now, but we have installed the
> new Jira connector for Github projects under openEHR. Here is a
> refresher on the instructions for writing commit messages if you are
> trying to connect to a Jira issue.
>
>
> https://openehr.atlassian.net/plugins/servlet/ac/com.github.integration.production/github-post-install-page
>
> - thomas
>
>
>
> ___
> openEHR-implementers mailing list
> openEHR-implementers@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
<https://cabolabs.com/>
http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org