New ADL 1.5 workbench beta 6 - batch serialisation, YAML, JSON, XML
The latest ADL Workbench tool (Windows build) is now online here <http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html>. The main features are a number of bug fixes and batch serialisation, so that all archetypes in a repository can be converted to one of the output forms (ADL, dADL, XML, JSON, YAML) in one go. Please note that this version requires the latest version of the knowledge2 SVN <http://www.openehr.org/svn/knowledge2/TRUNK/> repo to be updated, if you are directly using any test archetypes or RM schemas from there. I have been putting together some new test archetypes, including some new 13606 ones, also test archetypes based on InterMountain Health Clinical Element Models. I will announce these shortly when a bit more work is done. - thomas beale ** -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120329/07c87624/attachment.html>
13606 revisited - list proposal
Thomas Beale wrote: > pablo pazos wrote: >> >> Consider this ER scenario: a BP value could be recorded each 30" or so, and >> the system could be used 1. for many patients, 2. by many users, 3. on the >> same machine. > > this is most likely a 1-event-per-Observation scenario. I realise it is not > always obvious when to use which recording approach! But the other design > aspect of a COMPOSITION is that it is a 'single health system event for the > patient'. Here it sounds like 1 nursing observation every 30 mins. Therefore > we would expect 1 COMPOSITION for each one, each containing one OBSERVATION, > containing one EVENT. An important consideration here is the composer of the composition. Different nurses will be recording the readings during the course of the day (or days, or weeks ...), but each composition can have only one composer. (You could get around that by adding an updated version of the composition with each reading, so the latest version would contain all of the data, but that would be a truly baroque approach! It would make it difficult to figure out which nurse had recorded which reading.) Another consideration is that the nurse is likely to be recording other observations at the same time as the BP. It seems logical to me that all of these observations should go into the same composition, because they were all done at the same time, by the same committer, for the same subject of care. On the other hand, if the BP readings are coming from a patient monitor, say, every 30 seconds, then it would make sense to store all of these BP readings in one composition. When would you decide, okay, that's enough, let's start another composition? Maybe every hour? Each day? Or maybe at the point in time when a clinician reviews them and says, "Yep, I've reviewed those BPs, commit 'em"? Peter
openEHRArchetypes/openEHR-EHR-OBSERVATION.ecg.v1: Is ...allowed?
Well, last time I checked the serialization and the schema this was
one of the things I was not sure which was correct. I have to get some
time to modify the schema with the missing things I detected some time
ago
2012/3/29 Sebastian Garde :
> The XML generator had a comment "not sure if needed" next to the any_allowed
> related code.
> So I have removed this now.
> A corrected version is deployed to the openEHR ckm.
>
> Regards
> Sebastian
>
>
>
> On 29.03.2012 08:49, Sebastian Garde wrote:
>
> Sounds like the Java XML generator needs to be corrected to never spit this
> out then. This should be straightforward to fix.
> I wonder however if this is just in there by mistake and nobody ever cared
> before that this fairly frequent case breaks the schema or if there was some
> kind of hidden use case for this.
>
> Sebastian
>
> On 28.03.2012 19:16, Thomas Beale wrote:
>
> On 28/03/2012 16:44, Sebastian Garde wrote:
>
>
>
> On 28.03.2012 14:47, Athanasios Anastasiou wrote:
>
> Hello everyone
>
> I keep getting an error when parsing this ecg archetype (expressed as XML)
> and i was wondering if this could be because the archetype was uploaded to
> the CKM when the CKM used a different version of the published openEHR XSDs,
> if this used to be a bug of the archetype editor or if it could be something
> that i am doing wrong.
>
> No - the xml in CKM is produced on the fly from the adl, so it is always up
> to date...
> But of course not necessarily always correct: There may well a bug in the
> generation process of the Java XML generator,
> but can someone say definitely if the any_allowed tag should be in the xml
> or not, first?
> (any_allowed is an operation, not an attribute in the constraint model)
>
>
> ADL example:
>
> DV_TEXT matches {*} -- object case
>
> or
>
> value matches {*} -- attribute case
>
> In the AOM it is computed to be True if...
>
> in a C_ATTRIBUTE there are no children
> in a C_COMPLEX_OBJECT there are no children
> in a C_PRIMITIVE_OBJECT, there is no 'value', i.e. no attached C_PRIMITIVE
> (parent type of C_DATE, C_INTEGER etc etc)
>
> I would also expect it to be computed from the XML, since the XML is based
> in the AOM.
>
> - thomas
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
openEHRArchetypes/openEHR-EHR-OBSERVATION.ecg.v1: Is ...allowed?
The XML generator had a comment "not sure if needed" next to the
any_allowed related code.
So I have removed this now.
A corrected version is deployed to the openEHR ckm.
Regards
Sebastian
On 29.03.2012 08:49, Sebastian Garde wrote:
> Sounds like the Java XML generator needs to be corrected to never spit
> this out then. This should be straightforward to fix.
> I wonder however if this is just in there by mistake and nobody ever
> cared before that this fairly frequent case breaks the schema or if
> there was some kind of hidden use case for this.
>
> Sebastian
>
> On 28.03.2012 19:16, Thomas Beale wrote:
>> On 28/03/2012 16:44, Sebastian Garde wrote:
>>>
>>>
>>> On 28.03.2012 14:47, Athanasios Anastasiou wrote:
>>>> Hello everyone
>>>>
>>>> I keep getting an error when parsing this ecg archetype (expressed
>>>> as XML) and i was wondering if this could be because the archetype
>>>> was uploaded to the CKM when the CKM used a different version of
>>>> the published openEHR XSDs, if this used to be a bug of the
>>>> archetype editor or if it could be something that i am doing wrong.
>>> No - the xml in CKM is produced on the fly from the adl, so it is
>>> always up to date...
>>> But of course not necessarily always correct: There may well a bug
>>> in the generation process of the Java XML generator,
>>> but can someone say definitely if the any_allowed tag should be in
>>> the xml or not, first?
>>> (any_allowed is an operation, not an attribute in the constraint model)
>>
>> ADL example:
>>
>> DV_TEXT matches {*} -- object case
>>
>> or
>>
>> value matches {*} -- attribute case
>>
>> In the AOM it is computed to be True if...
>>
>> * in a C_ATTRIBUTE there are no children
>> * in a C_COMPLEX_OBJECT there are no children
>> * in a C_PRIMITIVE_OBJECT, there is no 'value', i.e. no attached
>> C_PRIMITIVE (parent type of C_DATE, C_INTEGER etc etc)
>>
>> I would also expect it to be computed from the XML, since the XML is
>> based in the AOM.
>>
>> - thomas
>>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120329/b32d7284/attachment.html>
openEHRArchetypes/openEHR-EHR-OBSERVATION.ecg.v1: Is ...allowed?
Sounds like the Java XML generator needs to be corrected to never spit
this out then. This should be straightforward to fix.
I wonder however if this is just in there by mistake and nobody ever
cared before that this fairly frequent case breaks the schema or if
there was some kind of hidden use case for this.
Sebastian
On 28.03.2012 19:16, Thomas Beale wrote:
> On 28/03/2012 16:44, Sebastian Garde wrote:
>>
>>
>> On 28.03.2012 14:47, Athanasios Anastasiou wrote:
>>> Hello everyone
>>>
>>> I keep getting an error when parsing this ecg archetype (expressed
>>> as XML) and i was wondering if this could be because the archetype
>>> was uploaded to the CKM when the CKM used a different version of the
>>> published openEHR XSDs, if this used to be a bug of the archetype
>>> editor or if it could be something that i am doing wrong.
>> No - the xml in CKM is produced on the fly from the adl, so it is
>> always up to date...
>> But of course not necessarily always correct: There may well a bug in
>> the generation process of the Java XML generator,
>> but can someone say definitely if the any_allowed tag should be in
>> the xml or not, first?
>> (any_allowed is an operation, not an attribute in the constraint model)
>
> ADL example:
>
> DV_TEXT matches {*} -- object case
>
> or
>
> value matches {*} -- attribute case
>
> In the AOM it is computed to be True if...
>
> * in a C_ATTRIBUTE there are no children
> * in a C_COMPLEX_OBJECT there are no children
> * in a C_PRIMITIVE_OBJECT, there is no 'value', i.e. no attached
> C_PRIMITIVE (parent type of C_DATE, C_INTEGER etc etc)
>
> I would also expect it to be computed from the XML, since the XML is
> based in the AOM.
>
> - thomas**
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120329/42b30f6c/attachment.html>
