openEHR / FHIR data types cross analysis
Thanks Tom for this useful work. A couple of thoughts: 1) It might be worth explaining the need for DV_BOOLEAN - and not just use Boolean 2) The separation of date and time is not usual in computing languages at the moment and I would guess is a consideration - we certainly do not model these separately but as a constraint 3) The ability to have codes as units in quantity is an interesting approach which has been around for a while in HL7 v2 where you are not limited to SI units/UCUM but can have TAB for tablets etc. You state: The FHIR choice to represent units as a code or a string seems unnecessarily complicated. A UCUM units string should be adequate. There is an example with unit=mcg/L and code=ug. What can this mean? Nota sure how we could have a code for a unit that is UCUM/SI - this does not make sense really - but having the ability to put in quantities that are not SI Units does have some merit. Pulse is a good example - it is really a frequency x/min but people often say bpm or beats per minute. The amount of tobacco people use can be in cigarettes per day or oz/week or gm/day. At the moment we have to divide these into different parts of the archetype. That is not to say that it is right to put the counted thing as a unit and not keep it in the leaf node name but TAB/CAP/Puff/Drop etc are common for medication and do cause some difficulty. Cheers, Sam From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Monday, 30 January 2012 4:27 AM To: Openehr-Technical Subject: openEHR / FHIR data types cross analysis I have started a gap analysis of the openEHR and FHIR data types http://www.openehr.org/wiki/display/stds/FHIR+-+openEHR+Data+Types+cross-an alysis , created by Grahame Grieve as part of the HL7 'fresh look' activity. ANyone is welcome to add to the tables on this page - I am just slowly working on it in the background. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/8bab1f24/attachment.html
DV_DURATION as ranges
Hi Tom and Diego,
The reference workbench only has an interval constraint on duration as it is
the logical constraint. If this is a point duration then it still expresses
a range. Not sure if this has changed over time.
Cheers, Sam
-Original Message-
From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Tuesday, 31 January 2012 2:51 AM
To: openehr-technical at openehr.org
Subject: Re: DV_DURATION as ranges
I thought I had replied to this, but must not have. Anyway, I don't
understand why single point values are not used either, rather than
point ranges (which seem somewhat pointless ;-)
- thomas
On 25/01/2012 22:56, Diego Bosc? wrote:
No comments about this one?
2012/1/13 Diego Bosc?yampeku at gmail.com:
As Ian suggested I copy this issue from CKM to the technical list.
I have seen that in some archetypes (e.g. Apgar or BloodPressure)
that use DV_Duration restrictions (such as the width of the interval
event in the blood pressure archetype or the famous offset in the
apgar
archetype) define them like this:
offset existence matches {1..1} matches {
DV_DURATION[at0040] occurrences matches
{0..1} matches { --
value existence matches {1..1}
matches {|PT10M|}
}
}
As you can see, even if it is a single default value (10 minutes),
they are defined as ranges. As durations allow the definition of
default values (and they parse correctly) I think they should be
changed to this:
offset existence matches {1..1} matches {
DV_DURATION[at0040] occurrences matches
{0..1} matches { --
value existence matches {1..1}
matches {PT10M}
}
}
As checking a concrete value is always easier than a range I would
suggest to change them to that.
___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
pass_through and implementation directives in general
data dictionary] = NDD ref for intolerance [/data[at0001]/items[at0002]] = items = [design note] = this is a SPECIALISED design note on Statement [NEW TAG] = this is a SPECIALISED design note on Statement So let's imagine that a new section could be of a similar structure. The first thing to note is that it is path-based. Is this sufficient? For now, I will assume it is. Secondly, do we need multiple languages? I would assume not, since we are now talking about computable strings rather than human-consumable strings. The tags will obviously be different. Here is a possible example. *implementation_directives* items = [*/data[at0001]/items[at0.8]*] = items = [*presentation*] = *pass_through* [*querying*] = *something_else* [*/data[at0001]/items[at0.10]*] = items = [*presentation*] = *widget_type*=*smart_text_coded_selector (args...)* The blue tags would have to be controlled somehow by agreement, and would define the possible 'implementation directives' that could be stated. The green values, or 'flags' could potentially also be controlled. The red part in the last one illustrates an example whereby the value is a piece of syntax (it could be a function call, or something like a Javascript expression). If the value space for a given 'flag' is controlled (e.g. 'widget_type' always = some javascript expression) then we have enabled some formal computing elements to be used, as are likely to be required for implementation. It seems clear to me at least that there would not be many of these implementation directives on international archetypes, but national and local archetypes, and particular templates would potentially have many. We would need to establish basic rules like: - tag names come from a) a central controlled vocabulary and additionally b) local values being allowed - this could be done by registering the vocabularies at different jurisdictional levels. Initially, I think we could just work off a central wiki page, with perhaps a few key tags defined in the AOM spec itself (if we can figure them out in time) - values could also potentially be defined in this controlled vocabulary, i.e. in the form - tag1 = value1 | value2 | value3 etc - or in other ways, e.g. tag1 = string; javascript syntax - specialised archetypes and templates could override the value of an existing tag with another legal value for that tag - but we probably need to allow locally defined values as well for tags with a fixed value set - specialised archetypes and templates can add directives containing new (locally-defined) tags and values - there may need to be a way to 'remove' a tag setting from an archetype This is obviously pretty 'soft' computing, and therefore open to some dangers, but if we manage it as a community in a sensible way, it could bring a lot of value. The use of specialisation to add new directives I think is the key to making it work properly with respect to localisation. thoughts? - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/66eb5d9c/attachment.html
pass_through and implementation directives in general
do it * we could make it so that applying more local directives was done by defining correct inheritance rules for the implementation-directives section - i.e. use inheritance As I think about this, I am starting to be persuaded that continuing to use inheritance to achieve local additions and overrides is a good thing - it works for the rest of the archetype. If we commit to this path, the remaining question is: is the current annotations section structure sophisticated enough to contain implementation directives? An example of the annotations section from a current test archetype is as follows: annotations items = [en] = items = [/data[at0001]/items[at0.8]] = items = [design note] = this is a design note on allergic reaction [requirements note] = this is a requirements note on allergic reaction [medline ref] = this is a medline ref on allergic reaction [/data[at0001]/items[at0.10]] = items = [design note] = this is a design note on intelerance [requirements note] = this is a requirements note on intolerance [national data dictionary] = NDD ref for intolerance [/data[at0001]/items[at0002]] = items = [design note] = this is a SPECIALISED design note on Statement [NEW TAG] = this is a SPECIALISED design note on Statement So let's imagine that a new section could be of a similar structure. The first thing to note is that it is path-based. Is this sufficient? For now, I will assume it is. Secondly, do we need multiple languages? I would assume not, since we are now talking about computable strings rather than human-consumable strings. The tags will obviously be different. Here is a possible example. implementation_directives items = [/data[at0001]/items[at0.8]] = items = [presentation] = pass_through [querying] = something_else [/data[at0001]/items[at0.10]] = items = [presentation] = widget_type=smart_text_coded_selector (args...) The blue tags would have to be controlled somehow by agreement, and would define the possible 'implementation directives' that could be stated. The green values, or 'flags' could potentially also be controlled. The red part in the last one illustrates an example whereby the value is a piece of syntax (it could be a function call, or something like a Javascript expression). If the value space for a given 'flag' is controlled (e.g. 'widget_type' always = some javascript expression) then we have enabled some formal computing elements to be used, as are likely to be required for implementation. It seems clear to me at least that there would not be many of these implementation directives on international archetypes, but national and local archetypes, and particular templates would potentially have many. We would need to establish basic rules like: * tag names come from a) a central controlled vocabulary and additionally b) local values being allowed * this could be done by registering the vocabularies at different jurisdictional levels. Initially, I think we could just work off a central wiki page, with perhaps a few key tags defined in the AOM spec itself (if we can figure them out in time) * values could also potentially be defined in this controlled vocabulary, i.e. in the form * tag1 = value1 | value2 | value3 etc * or in other ways, e.g. tag1 = string; javascript syntax * specialised archetypes and templates could override the value of an existing tag with another legal value for that tag * but we probably need to allow locally defined values as well for tags with a fixed value set * specialised archetypes and templates can add directives containing new (locally-defined) tags and values * there may need to be a way to 'remove' a tag setting from an archetype This is obviously pretty 'soft' computing, and therefore open to some dangers, but if we manage it as a community in a sensible way, it could bring a lot of value. The use of specialisation to add new directives I think is the key to making it work properly with respect to localisation. thoughts? - thomas beale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/0ee26490/attachment.html
pass_through and implementation directives in general
to be a way to 'remove' a tag setting from an archetype This is obviously pretty 'soft' computing, and therefore open to some dangers, but if we manage it as a community in a sensible way, it could bring a lot of value. The use of specialisation to add new directives I think is the key to making it work properly with respect to localisation. thoughts? - thomas beale ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/859cea49/attachment.html
pass_through and implementation directives in general
On 31/01/2012 11:15, Erik Sundvall wrote: Hi! Ok, if implementation experience says it is better to have separate sections for human readable annotations and machine-targeted program directives then I guess that is a good approach. Are there any tools that support this now? well not today, but if we decide to specify this concept, I can implement it with examples in the reference ADL compiler very quickly. The code for more dADL sections is easy. Others are working in getting the Java parser up to ADL 1.5. Changes like this don't make that much difference because they are just straight dADL = objects transforms. If we specifiy and implement the outer structure I proposed, but don't say anything about the tag or values, we can accommodate the RDF approach just as easily as anything else. If going for an RDF-like URI based approach for program directives or implementation_directives then those serialization formats that aim for human readability (e.g. ADL and YAML) may want to use some kind of URI-prefixing-mechanism to make the directives shorter and more readable. (Similar approaches are used in XML (namespaces) and many RDF serialization formats.) I would opt for implementation_directives, less ambiguous. I assume program directives will include both pass_through and more purely GUI-oriented directives. Will they contain everything annotation/directive-like that is intended to be machine processable and human language independent? Is that a correct and shared view of the purpose? that's my understanding. I don't think anyone has any more than an ad hoc knowledge so far of what these things are likely to be, much less a structured theory about what /should/ be included. Are both annotations and program directives supposed to be attributes of the class AUTHORED_RESOURCE? I don't find them in the current http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdf but I guess that might be a matter of time constraints - or are they going to be only a part of AOM/ADL itself? I just want to check what the future thoughts are. you can see annotations in section 7.1 of that doc. 'implementation_directives' I think should go on the ARCHETYPE class for now. Is program directives the best name? Annotations is very a very generic and useful name, but that word is already taken for the human readable stuff. Could anything from the following list inspire somebody with a more native feel for English to come up with alternate name suggestions? well I think 'implementation_directives' says what we mean here, but it is annoyingly long, that's for sure. I am fine with 'directives', as long as we define what this means in the documentation and everyone understands its scope. 'processing_directives' or 'processing_instructions' seem like reasonable synonyms, but are also annoyingly long. Does 'processing' on its own make sense? - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/3482363a/attachment.html
pass_through and implementation directives in general
On 31/01/2012 00:16, Heath Frankel wrote: Hi Thomas, I think you're going too far with this controlled key and syntax approach. The important thing at this point is we get a structure that we can start using to get more experience with. Although my proposal was a simple property value bag, I think your idea of a triplet is good, but we should do this using attributes rather than syntax. So a directive type, an name/ID and value attributes seems like a pretty powerful structure, its similar the Claim class in an Identity Model for authorisation (claim type, right, resource). I think the majority of view directive use will be in templates at the local level, but certainly some directives are likely at the jurisdictional level (e.g. pass_through). For this reason, I think that we should not restrict the values to only controlled values, controlled values are only necessary for shared use and it is these that certainly need to have a registry. agree - that's what I was trying to say in fact. Erik's RDF suggestion seems like a reasonable approach to doing this rather than openEHR inventing a new scheme. We need to support innovation in this area and hence allow local groups to use local directive type/identifiers/values at will and when they have something to bring back to the community somewhere to register and align their local directives with shared directives. A consumer should only need to process the directives it is interested in, unless we provide something like a must-understand attribute. With regard to inheritance of directives, I think this needs to be based on the directive type. In some cases we will want an override, in others we would want addition or constraint. Not sure yet whether this needs to be specified in the directive or not so that the compile can generate the appropriate result or always have the complete set and leave the responsibility to the consumer to interpret the set. I don't think we need to make this too complicated at first, the main thing is to get the containment structure right, we can always add attributes such as must_understand and override mode to the directive class later. Regards yep. See my last post. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/bc563d4d/attachment.html
pass_through and implementation directives in general
On 31/01/2012 13:12, Erik Sundvall wrote: Hi! On Tue, Jan 31, 2012 at 13:44, Thomas Beale thomas.beale at oceaninformatics.com mailto:thomas.beale at oceaninformatics.com wrote: If going for an RDF-like URI based approach for program directives or implementation_directives then those serialization formats that aim for human readability (e.g. ADL and YAML) may want to use some kind of URI-prefixing-mechanism to make the directives shorter and more readable. (Similar approaches are used in XML (namespaces) and many RDF serialization formats.) I would opt for implementation_directives, less ambiguous. In that part of the mail I was thinking of shortening serialisations of things like... [http://schema.openehr.org/GUI-v0_1#view;] = http://schema.openehr.org/GUI-v0_1#pass_through; ...to something like... [gui:view http://schema.openehr.org/GUI-v0_1#view] = gui:pass_through http://schema.openehr.org/GUI-v0_1#pass_through ...by somewhere in the file defining gui: ...to mean... http://schema.openehr.org/GUI-v0_1# http://schema.openehr.org/GUI-v0_1#pass_through // Erik Erik, which file do you mean here? Where is this alias? - thomas ** -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/e84efa8c/attachment.html
Python / Django experience??
Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that: a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Wed, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/e4138f6c/attachment.html
Python / Django experience??
Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that:?a very lightly-governed archetype?collaboration, simple review and discussion space to enable early?communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain:?http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Wed, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been good enough to offer further support and guidance. 3. At some point some sort of integration with CKM would be interesting. I will be taking an interest in the developments but have very limited Python skills. Anyone interested? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Python / Django experience??
This will be part of our tool chain:?http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png Hi Pablo, there's a minor typo in your otherwise great diagram: decision in stead of decition. Cheers, Roger
Python / Django experience??
://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/a048220c/attachment.html
Python / Django experience??
Thanks a lot Roger, it has been corrected, now the working link is: http://4.bp.blogspot.com/-9_P5lrqSaH4/TygHTXUDOnI/E_c/ebyHliBiuaA/s1600/openEHR+Toolchain+ppazos+sm.png The diagram is part of this entry on the outcomes of our first openEHR course in spanish: http://informatica-medica.blogspot.com/2012/01/conclusiones-del-curso-de-openehr-en.html -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 31 Jan 2012 16:05:39 +0100 Subject: Re: Python / Django experience?? From: roger.erens at e-s-c.biz To: openehr-technical at openehr.org This will be part of our tool chain: http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png Hi Pablo, there's a minor typo in your otherwise great diagram: decision in stead of decition. Cheers, Roger ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/53f657e8/attachment.html
Python / Django experience??
Hi Pablo, Your initial ideas on a possible service layer would be very interesting. I think we are starting to see a need to support cross repository service layer but possibly split between formally governed assets and those that are in early or experimental stages of development (as we envisage with CKI). The requirements for governed cross-repository assets will be rather more demanding. Have you seen this HL7/OMG proposal? http://hssp-rlus-normative.wikispaces.com/home Might be a useful start point. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 15:27, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, it would be nice to share a common API or service layer that both groups can rely on, so we can make our tools compatible in some way. I have an informal list of requirements that this tool should support, maybe we can start sharing our requirements and see if we can agree on a common interface (API/services). -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Tue, 31 Jan 2012 14:57:20 + Subject: Re: Python / Django experience?? To: openehr-technical at openehr.org Thanks Pablo, I will be interested to see how your app develops. We have a few Python volunteers so hope to have something visibly quite soon. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation ?www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care ?www.phcsg.org On 31 January 2012 14:45, pablo pazos pazospablo at hotmail.com wrote: Hi Ian, we are planning to work in this area but not with those technologies, I think it will be PHP or Java/Groovy. What we want is just that:?a very lightly-governed archetype?collaboration, simple review and discussion space to enable early?communication between possible archetype developers. Firstly for the openEHR-ES community, to engage doctors and nurses in archetype development, and later to show how to use that knowledge in an EHR tool like EHRGen (http://code.google.com/p/open-ehr-gen-framework/). Later it could be a general use tool. This will be part of our tool chain:?http://1.bp.blogspot.com/-Yd3JhnuVjgk/TwMepovkBeI/E-4/7UCf-ry2JqY/s1600/openEHR+Toolchain+ppazos+sm.png And it'll serve as a continuation for the students of our openEHR course, to embrace and don't lose the momentum after the course. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos From: Ian.McNicoll at oceaninformatics.com Date: Wed, 11 Jan 2012 11:10:57 + Subject: Python / Django experience?? To: openehr-technical at openehr.org Hi all, Would any of you with Python / Django experience be interested in helping with a small open-source project to establish a 'Clinical Knowledge Incubator' website under the auspices of the Foundation? The intention is to establish a very lightly-governed archetype collaboration, simple review and discussion space to enable early communication between possible archetype developers. This is not intended to compete with a more formally-governed repository such as CKM but to allow archetypes, requirements and specification documents to be shared and discussed prior to more formal governance and development processes kicking in. The site will be based on the open source Snowcloud Clinical Templates framework see clinicaltemplates.org. The work needing done to adapt this for openEHR is broadly .. 1. Add some sort of persistence/ repository back-end for archetypes and associated documentation e.g Github and/ or Dropbox. There is a very nice Python API for the latter which I got working. This does not need to be be particularly complex. Github would probably be a better solution but the limited versioning afforded by Dropbox is probably sufficient. 2. Add the ability to import from openEHR ADL/XML and .opt XML ) into the native XML format. Derek Hoy, the Snowcloud developer, has already partially implemented this but it does need further work. Derek has been
13606 revisited - list proposal
Hi Thomas, I've added a proposal to the page on the wiki http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model I'm also thinking about the ENTRY model, to lift up the data/description attributes from all entry subclasses to the ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all subentries could define the data as ITEM_STRUCTURE or as a HISTORY. Maybe to have the flexibility to define ACTIONS and other entries to have a data attribute of class ITEM_STRUCTURE or HISTORY to track time of events instead of inventing DV_DATE/DV_DATETIME ELEMENTs on ACTION/EVALUATION/INSTRUCTION archetypes is a good idea. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Thu, 15 Dec 2011 15:48:07 + From: thomas.be...@oceaninformatics.com To: openehr-technical at openehr.org Subject: Re: 13606 revisited - list proposal I have started a wiki page for this 'lower RM' simplification. The top contains the existing models, feel free to add to the 'problem' list (why are we simplifying?). If you have a candidate solution to offer, please put it under a new heading - you will see a 'Candidate B' ready to be used by someone. If we proceed in that fashion, I think we can keep the proposals clear. NOTE: I have only half done my proposal, Candidate A, so don't bother looking at it yet. - thomas On 15/12/2011 14:54, pablo pazos wrote: Hi Erik, I want to implement some simplifications of the item_structure in the EHRGen ( http://code.google.com/p/open-ehr-gen-framework/ ) we talked about this: http://www.openehr.org/mailarchives/openehr-clinical/msg02231.html My focus is on the persistence layer, because we persist data using an ORM (object-relational mapping) component, and the complexity of the relational schema is proportional to the complexity of the object model. BTW, the EHRGen has the complete cicle of information implemented: automatic gui generation (based on archetypes and our gui templates), data validation against archetype constraints, data binding (creation of RM structures from user data input and archetypes), persistence of those structures, and getting data to show on a GUI. Now I'm experimenting with semantic queries (common SQL but based on arcehtype ids and paths). Regards, Pablo. Regarding the RM I know Tom is experimenting with simplified ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other RM-redesign experiments going on anywhere? What is happening in the 13606-world regarding thoughts about practical datatypes? What about (optional) reusable ENTRY subtypes in the 13606 world? (see http://www.openehr.org/mailarchives/openehr-technical/msg05285.html under the heading 2. OBSERVATION et. al. (ISO 13606 CR)) ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120131/d3898636/attachment.html
