Re: Ordinal values without descriptions

[pazospablo]

  

Following Thomas, I think for the missing descriptions you might need to 
put "between x and y" if x and y are available descriptions.
Sent from my LG Mobile


-- Original message--From: Thomas BealeDate: Tue, Apr 26, 2016 12:42To: 
openehr-technical@lists.openehr.org;Subject:Re: Ordinal values without 
descriptionsIf you give someone a '3' on the Apparent Sadness scale, what   
   does it mean? Apparently it's between 'Looks dispirited  but does 
brighten up without difficulty' and 'Appears sad and  unhappy most of the 
time'So now imagine that this '3' appears for me in my record - just
  that value. The scale doesn't tell you what it means. It probably  should 
have a value like 'Appears sad quite often' or similar.  Instead, I would 
see nothing at all, and maybe I would know to go  online and try to 
understand what 3 means by looking at the values  for 2 and 4. Even in a 
paper record, the problem is the same.
At a technical level, the RM will does require a DV_CODED_TEXT.  So 
one question is: considering that the set of texts for an  ordinal is 
actually a set of terms, what does the term set look  like? It must be 
value set with only 4 members instead of 7.
Personally I think that scale is not ready for use in paper or  
electronic health record...- thomas
On 26/04/2016 11:59, Bakke, Silje  Ljosland wrote:
Hi everyone, We’re 
working on anarchetype for the Montgomery-Åsberg Depression Rating 
Scale(MADRS). This scale contains several ordinal values where  
  there is no description, and some where there is no text at
all. This doesn’t work very well in archetypes, andparticularly 
when uploading to a CKM, because there’s anexpectation that every 
field should be filled in, and theCKM will replace empty fields 
with * or sometimes*([language code]). Is there any way to get 
around this? See here for what theMADRS looks like: 
http://www.psy-world.com/madrs.htm  
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Composition commit and change types

[pazospablo]

  

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


-- Original message--From: Thomas BealeDate: Mon, Apr 4, 2016 10:31To: 
openehr-technical@lists.openehr.org;Subject:Re: Composition commit and change 
types

On 04/04/2016 07:23, pablo pazos wrote:
I thought you had more specific cases :)
Having specific lists per clinician was commented by  
Karsten on a previous message and I commented on that. I'm not  sure at 
which extent that is a backend issue, an API issue or  an UI issue. I 
would say if this is just a display  requirement, is more UI related 
and we need to find ways in  the backend to provide the data to address 
this requirement,  independently of if we have or not singleton 
 versioned_compositions per persistent compo archetype.  
I think it is not just a display requirement, at least in some
countries. There are separate care plans for example in the UK forsome 
patients for relatively unrelated conditions. Whether separatemedication 
lists really exist at the clinical level is a question (abad idea for 
obvious reasons, same for allergies), but I suspect itcould exist at a 
practical level in some places, if a GP or otherMeds list is imported into 
a hospital environment that has its ownmedications list; in this case, the 
two taken together would be seenas the total logical list,  but each part 
being owned by a differentprovider. We need more concrete evidence on this, 
but I don't seeanything to prevent this sort of thing happening.

  

OT but related:
Now this got me thinking about commits. Until now, I was
  thinking of full composition commits, so if you want to add a  
medication to a medication list, you need to commit the data  in the 
current version, plus the new entry for the new  medication. But what 
about delta commits? If I didn't changed  anything on the current 
medications, can't I just commit the  new medication? Is this possible 
or somebody implemented  something like this?  
openEHR doesn't say how to store the Versions, only that the logical
view needs to be that each Version appears to have the full content.If you 
want to engineer a delta-based storage mechanism, you can,the specs don't 
prevent that. Note that implementing differentialrepresentations for object 
structures is non-trivial, but doable(AOM2 does it for example); if you are 
storing some serial format,then you can potentially use text-based diffing, 
although you haveto be careful of ordering within Hashes and Lists, which 
tends tobreak purely logical versioning e.g. on XML.

  
I would think of that as a commit "mode" that applies for   
   amendment and modification change_type, and would allow to log  
individually added entries, and keep track of whole  "singleton" 
persistent lists.
  
Well, all it really means is that a function might be added to theEHR 
API that enables you to 'add' just a medication to a medicationlist, and 
the API will actually figure out how to create the wholecomposition, do any 
diffing, and store the proper Composition withina Contribution. Personally 
I think a better way that I haveadvocated for some years is a business 
level service + API called'medication list' that provides functions like:
  getAll: List  getAllIds: List
addMedicationOrder (newMed: Instruction)  removeMedicationOrder 
(id: String)  getMedicationOrdersInState (aState: StateEnum) // e.g.
'active', etc  putAction (anAction: Action; orderId: String)  etc   
 that's just one idea of the service. Obviously it can be done  
differently. The point is that it would provide all the needed  conversions 
between a functional/transactional interface, and the  appropriate openEHR 
structures. It would do all the building of  Compositions and so on, and 
make the correct calls to the EHR  service.
I would foresee the same kind of service for:
  allergies & interactions  vaccinations  procedures list   
   care plan  patient diary  doctor's diary  etc- thomas
  

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

Re: Composition commit and change types

[pazospablo]

  

All is already versioned, my question is about how to commit compos and if 
it makes sense to have two different versioned compositions for the same 
persistent compo archetype.
Sent from my LG Mobile


-- Original message--From: Bert VerheesDate: Sat, Apr 2, 2016 15:01To: 
openehr-technical@lists.openehr.org;Subject:Re: Composition commit and change 
typesI guess you need to version it, if you  want it to be according 
the specs.
  That means, when you use it for a medication-list, you will get  many 
versions of the same compositions for a patient.
  
  But if you do not version it, that means that the concept of  
replaying the Past in case of legal investigation will not be  possible.
  
  Bert
  
  
  On 02-04-16 07:59, pazospa...@hotmail.com wrote:
  Hi  all, I'm testing some cases in the EHRServer 
and I want to  confirn some grey areas.
If  the EHR receives a commit of a persistent 
composition and the  change type is creation, should the EHR create a 
new  composition?
i.e.  I don't see an EHR having two different 
medication lists, is  that possible?
I  guess persistent compos can only be created one time 
per  archetype (one medication list, one problem list, one  
vaccination list, etc. per patient), and after the creation,  all 
commits should be modification. Does this make any sense?
If  this is OK, to avoid errors from client 
applications, I would  return an error when a creation is committed for 
a persistent  compo archetype that already has a conpo instance.
And  about the first commit. Should, lets say, the 
medication list  be created when the first medication is recorded or 
can it be  created empty? What do other implementations out there do?   
 
Thanks  a lot!

  ___openEHR-technical mailing 
listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: Composition commit and change types

[pazospablo]

I think that has more to do with the user interface than how compositions 
are committed, since I can filter meds by who prescribe them with ease.
Sent from my LG Mobile


-- Original message--From: Karsten HilbertDate: Sat, Apr 2, 2016 
04:25To: openehr-technical@lists.openehr.org;Subject:Re: Composition commit and 
change typesOn Sat, Apr 02, 2016 at 05:59:33AM +, pazospa...@hotmail.com 
wrote:> i.e. I don't see an EHR having two different medication lists, is that 
possible?Regardless of whether it makes sense conceptually, you will,at any 
rate, encounter clinicians of differing specialitiesworking against the same 
OpenEHR intance wanting to have"their own" medication list each.Whether the 
backend actually does "their own" is another matter.Karsten-- GPG key ID 
E4071346 @ eu.pool.sks-keyservers.netE167 67FD A291 2BEA 73BD  4537 78B9 A9F9 
E407 1346___openEHR-technical 
mailing 
listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: rm_type_name for the DV_DURATIONs primitive object in XML

[pazospablo]

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


-- Original message--From: Sebastian GardeDate: Tue, Mar 15, 2016 
09:36To: For openEHR technical discussions;Subject:rm_type_name for the 
DV_DURATIONs primitive object in XMLDear all, There are a differences in how 
the Template Designer and how CKM construct the XML for a DV_Duration: Take 
this snippet (from http://openehr.org/ckm/#showArchetype_1013.1.123_XML ) 
    
DV_DURATION       
   true  
true  
false  
false 1   
   1       
       
value     
 true  
  true    
false    
false    
1    1  
    
  DV_DURATION  
    true  
    true   
   false  
false  
1  1  
          
  PMWD   
       
true    
true     
       
   What is the correct rm_type_name for 
C_PRIMITIVE_OBJECT here (in old red above)? Is it “DV_DURATION” as the Java Ref 
Impl uses or is it simply “DURATION” (both for reason I don’t really 
understand)or should it maybe be “String” or “ISO8901_DURATION” 
ashttp://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264460_352968_7042
 
and/orhttp://openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1422968609347_115062_25681
 describe. Frankly I am confused, but I hope that someone can enlighten me 
here? CheersSebastian  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: PhD Thesis online: Detailed clinical models and their relation with Electronic Health Records

[pazospablo]

Felicitaciones Diego!
Sent from my LG Mobile


-- Original message--From: Diego BoscáDate: Wed, Jan 27, 2016 17:42To: 
For openEHR clinical discussions;For openEHR technical discussions;For openEHR 
implementation discussions;Subject:PhD Thesis online: Detailed clinical models 
and their relation with Electronic Health RecordsHello all,My thesis "Detailed 
clinical models and their relation with ElectronicHealth Records" is now 
available online. Until the universitypublishes it on the public repository, 
here is a link to 
it.https://www.dropbox.com/s/rqmmh9b541u7wpr/TesisDiego_v2.pdf?dl=0The slides 
are also available just in case anyone wants a quick 
summaryhttp://www.slideshare.net/yampeku/detailed-clinical-models-and-their-relation-with-electronic-health-recordsI
 also attach the abstract belowBest RegardsDiego BoscáAbstractHealthcare domain 
produces and consumes big quantities of people’shealth data. Althoughdata 
exchange is the norm rather than the exception, being able toaccess to all 
patient data isstill far from achieved. Current developments such as personal 
healthrecords will introduceeven more data and complexity to the Electronic 
Health Records (EHR).Achieving semanticinteroperability is one of the biggest 
challenges to overcome in orderto benefit from all theinformation contained in 
the distributed EHR. This requires that thesemantics of theinformation can be 
understood by all involved parties. It has beenestablished that three layersare 
needed to achieve semantic interoperability: Reference models,clinical 
models(archetypes), and clinical terminologies.As seen in the literature, 
information models (reference models andclinical models) arelacking 
methodologies and tools to improve EHR systems and to developnew systems that 
canbe semantically interoperable. The purpose of this thesis is toprovide 
methodologies andtools for advancing the use of archetypes in three different 
scenarios:- Archetype definition over specifications with no dual 
modelarchitecture nativesupport. Any EHR architecture that directly or 
indirectly has thenotion of detailedclinical models (such as HL7 CDA templates) 
can be potentially used asa referencemodel for archetype definition. This 
allows transforming single-modelarchitectures(which contain only a reference 
model) into dual-model architectures (referencemodel with archetypes). A set of 
methodologies and tools has been developed tosupport the definition of 
archetypes from multiple reference models.- Data transformation. A complete 
methodology and tools are proposedto deal with thetransformation of legacy data 
into XML documents compliant with thearchetype andthe underlying reference 
model. If the reference model is a standard then thetransformation is a 
standardization process. The methodologies andtools allow boththe 
transformation of legacy data and the transformation of databetween 
differentEHR standards.- Automatic generation of implementation guides and 
reference materials fromarchetypes. A methodology for the automatic generation 
of a set of referencematerials is provided. These materials are useful for the 
developmentand use of EHRsystems. These reference materials include data 
validators, example instances,implementation guides, human-readable formal 
rules, sample forms, mindmaps, etc.These reference materials can be combined 
and organized in differentways to adaptto different types of users (clinical or 
information technologystaff). This way, users caninclude the detailed clinical 
model in their organization workflow andcooperate in themodel definition.These 
methodologies and tools put clinical models as a key part of thesystem. The set 
of presented methodologies and tools ease theachievement of semantic 
interoperability by providing means for thesemantic description, normalization, 
and validation of existing andnew 
systems.___openEHR-implementers 
mailing 
listopenEHR-implementers@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Archetype relational mapping - a practical openEHR persistence solution

[pazospablo]

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


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

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.orgDirector, freshEHR 
Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: New EHRServer v0.5 and roadmap

[pazospablo]

  

Thanks for your comments Bert,
I still have some improvements to do to the query builder to make it simpler to 
use for clinical users that don't know openEHR.
I felt in love with Grails and Groovy a long time ago, being using them since 
2007. I can create the same functionality but with less code than plain Java, 
and produce clean code. Take a look, you wont be disapointed :)
Sent from my LG Mobile


-- Original message--From: Bert VerheesDate: Fri, Jan 15, 2016 04:56To: 
openehr-technical@lists.openehr.org;Subject:Re: New EHRServer v0.5 and roadmap  
  Very nice, Pablo, an understandable  query-builder.
  Well done. 
  
  I looked at the code, clean code, worth reading.
  
  Good thing about groovy is that it produces clean code, I should  
train myself more in it.
  ;-)
  
  I take a further look at it next week.
  
  Thanks for sharing
  Best regards
  Bert
  
  
  On 15-01-16 04:11, pablo pazos wrote:
@all the guide is ready!
http://cabolabs.com/software_resources/EHRServer_v0.5.pdf   
 
Please let me know if you find any errors or if any part
  needs clarifications, thanks!
  
  -- 
  Kind regards,
  Eng. Pablo Pazos Gutiérrez
  http://cabolabs.com
  
  From: pazospa...@hotmail.com
To: openehr-technical@lists.openehr.org
Subject: RE: New EHRServer v0.5 and roadmap
Date: Thu, 14 Jan 2016 22:56:13 -0300

Thanks Seref, this is really kind of you. I 
 agree that we need more open source implementation out  there and 
I hope my little project help others to develop  their own.
  
  -- 
  Kind regards,
  Eng. Pablo Pazos Gutiérrez
  http://cabolabs.com
  
  Date: Thu, 14 Jan 2016 20:30:10
+
Subject: Re: New EHRServer v0.5 and roadmap
From: serefari...@kurumsalteknoloji.com
To: openehr-technical@lists.openehr.org

Hi Pablo,   Just wanted to say well done. I 
have not had thechance to look at your work, mainly because 
work andstudies forced me to take a step back from open 
   source efforts, but it is great to see the
continuous progress you're making.     It is 
very important that there is an open sourceimplementation 
of openEHR out there that is activelydeveloped. Don't worry 
about the performance either.If someone wants to use it and 
they think it is notfast, they should pay you to make it 
faster.   
I hope it gets adopted and you keep working 
onit.   
All the best  Seref 
 
  
  On Thu, Jan 14, 2016 at5:42 AM, pablo 
pazos wrote:

Hi all!  
I'm very excited to share 
the good newswith all my openEHR friends here.  

We have released EHRServer 
v0.5! Thisversion 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, andbefore 
that, supporting multi-tenancy.  
I'll release user 
documentation and afull REST API documentation in 
the nextcouple 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 testthe EHRServer*, you are very welcome 
to tryit and give us some feedback to continue  
  improving the tool: 
https://cabolabs-ehrserver.rhcloud.com/ehr  

Re: New EHRServer v0.5 and roadmap

[pazospablo]

  

Thanks Thomas!
I prefer to create these videos with the latest fixes added. Also, these are 
live hangouts, so anyone can attend and ask questions if they want. I will 
publish the date for the next demo soon.
Sent from my LG Mobile


-- Original message--From: Thomas BealeDate: Thu, Jan 14, 2016 10:03To: 
openehr-technical@lists.openehr.org;Subject:Re: New EHRServer v0.5 and roadmap  
  
Hi Pablo, 

I watched the latest video, very nice. Why not consider a revoiced
version in English some time? I think it's mature enough to starttrying to 
get a wider audience.

- thomas

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

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

Re: EHRServer v0.4 released

[pazospablo]

Awesome, let me know if you need any help.
Sent from my LG Mobile


-- Original message--From: Koray AtalagDate: Mon, Nov 30, 2015 7:40 
AMTo: For openEHR technical discussions;Subject:RE: EHRServer v0.4 releasedWell 
done Pablo – a PhD student of mine and also a colleague will be playing with it 
shortly. Will definitely feed back!Keep up the great workJ Cheers, -koray From: 
openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]On Behalf 
Of pazospa...@hotmail.com
Sent: Sunday, 29 November 2015 6:36 a.m.
To: openehr-technical@lists.openehr.org; For openEHR implementation ...
Subject: EHRServer v0.4 released Dear friends, we have released the new version 
of the EHRServer https://github.com/ppazos/cabolabs-ehrserver I'll update the 
docs soon and deploy the new version on our staging server for anyone who wants 
to test it. Feedback is very welcome! Cheers,Pablo.___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

EHRServer v0.4 released

[pazospablo]

Dear friends, we have released the new version of the EHRServer 
https://github.com/ppazos/cabolabs-ehrserver
I'll update the docs soon and deploy the new version on our staging server for 
anyone who wants to test it.
Feedback is very welcome!
Cheers,Pablo.


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

Re: Party-actor-folder relationships in hierarchy

[pazospablo]

Did anyone tried the marand's online editor with the demographic model? 
Opinions?
Sent from my LG Mobile


-- Original message--From: Ian McNicollDate: Sat, Nov 28, 2015 8:44 
AMTo: For openEHR technical discussions;Subject:Re: Party-actor-folder 
relationships in hierarchyThanks Peter,

Yes. I did make a start on this a few years back but got bogged down in not  
being families with the ui aspects by which time the LinkEhr editor was 
handling Demographics archetypes nicely. 

I think this another opportunity to remind everyone that openEHR is a community 
that relies almost entirely on volunteer efforts to build and maintain the 
specs, software and clinical content models. Historically companies like Ocean 
have put a lot of effort into building tools which are open source but 
inevitably the direction and effort will mirror the requirements of their 
customers. Since the archetype editor is open source, others who see a need for 
demographics support are free to add this. I will be very happy to put my 
initial efforts up on a fork if others want to take it forward. 

I am sure we would all sign up to a future where this kind of critical tooling 
work was underpinned by solid funding by we simply do not have that luxury 
right now. 

Ian 
On Fri, 27 Nov 2015 at 21:42, Peter Gummer  
wrote:
On 27 Nov 2015, at 21:30, Bert Verhees  wrote:
>
> Anyway, the Ocean Archetype-Editor (does it support demographics now?) is not 
> the OpenEHR specification, it is just an implementation.


Hi Bert,

No, the Ocean Archetype Editor doesn’t support demographics yet. Fixes and 
improvements to the EHR support have always been higher priority in the past, 
according to the tool's users.

Ian McNicoll did make some progress on demographic support a few years ago and 
he said it was looking like it wouldn’t be too difficult, but I guess other 
priorities must have intervened.

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

Re: Party-actor-folder relationships in hierarchy

[pazospablo]

Hi Dmitry,
Consider that the folder structure is defined for each EHR, and can vary vary 
between ehrs inside the same company.I would use LINK to link the org to the 
ehr folder struct.

Sent from my LG Mobile


-- Original message--From: Dmitry BaranovDate: Thu, Nov 26, 2015 7:37 
PMTo: For openEHR technical discussions;Subject:Party-actor-folder 
relationships in hierarchyHi, I have a lot of practical questions to ask 
:)Let's imagine that I have an EHR database which is shared by several 
organizations, and each organization manages one or more EHR systems, and each 
EHR system manages it's own hierarchy of folders. Something like that:- 
Database  [C] ACME company (1.1.1.1)[S] EHR System 1 (1.1.1.1.1) - Root 
folder 1   - Folders   - Items - Root folder 2   - Folders  
 - Items[S] EHR System 2 (1.1.1.1.2) - Root folder 1   - Folders
   - Items - Root folder 2   - Folders   - Items  [C] Good Health 
Company (1.1.1.2)[S] EHR System 3 (1.1.1.2.1) - Root folder 1   - 
Folders   - Items - Root folder 2   - Folders   - Items[S] 
EHR System 4 (1.1.1.2.2) - Root folder 1   - Folders   - Items 
- Root folder 2   - Folders   - ItemsThe question is: how could I 
implement such a hierarchy using pure 1.0.1/1.0.2 classes not using custom 
object model extensions? As far as I understand, a company can be described 
either by PARTY_IDENTIFIED or ORGANIZATION (by the way, where is 
Demographic.xsd in official releases?) and identified by OID. How could I 
describe a EHR system? In which role is it (probably AGENT)? And how do I link 
a FOLDER to a PARTY/PARTY_IDENTIFIED? Thanks in advance-- Regards, 
Dmitry___openEHR-technical mailing 
listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR and IHTSDO (SNOMED CT)

[pazospablo]

Hi Mikael, there have been some approaches in the past, currently I think 
the is no formal work between openEHR and IHTSDO (we know who they are ;)
Sent from my LG Mobile


-- Original message--From: Mikael NyströmDate: Fri, Sep 25, 2015 
14:26To: For openEHR clinical discussions;For openEHR technical 
discussions;Subject:openEHR and IHTSDO (SNOMED CT)Hi,I wonder if there are any 
current collaborations or collaboration plans between openEHR Foundation and 
IHTSDO (which is the organisation that owns and maintains SNOMED CT.)  
Regards Mikael___openEHR-technical 
mailing 
listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: A question about the XML schema for version 1.4 archetypes

[pazospablo]

Hi, the uid might be assigned by the archetype editor, before uploading the 
adl into the ckm, so this can be a bug on the AE.
Sent from my LG Mobile


-- Original message--From: Barnet David (HEALTH AND SOCIAL CARE 
...Date: Thu, Sep 3, 2015 10:31To: 
openehr-technical@lists.openehr.org;Subject:A question about the XML schema for 
version 1.4 archetypesI have a question about the XML schema for archetypes 
based on ADL version 1.4 The set of schemas we are using to validate XML 
archetype exports are 1.0.1ETC.. The issue we are getting is that 
sometimes an archetype has a  tag. All those downloaded from our CKM 
(ckm.hscic.gov.uk) have this tag, but it’s not present on all archetypes from 
other CKMs (which may be why this could be a new issue). The schema is 
expecting the  tag before the  tag   
 
   

  
 However, in the XML instances, the  (if present) appears 
after the  tag  
openEHR-EHR-OBSERVATION.newborn_birth_details.v0   
   1..4   
7f716e0e-5fa8-4fec-942d-208764409b07 Further, changing the schema to 
change the expected tag order to match the XML instances shows up a further 
issue in that the format of  (according to the schema) should use a 
 tag like this  
7f716e0e-5fa8-4fec-942d-208764409b07Are we 
using an out of date set of schema? Or are these known issues? Have people 
corrected the schema for their own use (if so could I have a copy please)? Kind 
regards Dave Barnet
Interoperability LeadInteroperability SpecificationsHealth & Social Care 
Information Centre
david.bar...@hscic.gov.uk
www.hscic.gov.uk 


This message may contain confidential information. If you are not the intended 
recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take 
any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff 
in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information 
with NHSmail and GSi recipients
NHSmail provides an email address for your career in the NHS and can be 
accessed anywhere


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

Re: Advantage of ISO

[pazospablo]

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


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


On Sep 3, 2015, at 8:38 AM, pablo pazos  wrote:
I think that definition doesn't apply to a standard / spec. IMO when we talk 
about standards, we focus on the ability to use it and let others use it, and 
the constraints / freedoms in that area, not in who is the owner.

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

Re: difference and relationship between openEHR and EN13606

[pazospablo]

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


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


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

Re: Template Designer - remove slot

[pazospablo]

!--..hmmessage P{margin:0px;padding:0px}body.hmmessage{font-size: 
12pt;font-family:Calibri}--

Hi Thomas,Please let me know when I can create issues for the TD. I have 
found a couple more. Thanks!
Sent from my LG Mobile


-- Original message--From: pablo pazosDate: Sat, May 23, 2015 22:34To: 
openeh technical;Subject:RE: Template Designer - remove slotHi Thomas, trying 
to create an issue I got this error
Assignee: The default assignee does NOT have ASSIGNABLE permission OR 
Unassigned issues are turned off.

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

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

  On 04/05/2015 16:11, pablo pazos wrote:
  Awesome, I'll add this to the TD JIRA. Do anyone  
  remember where that JIRA is?

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

- thomas

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