We had to wrestle with data transformation in our early days, which made us
learn things in the hard way :)
As you said ADL2 addresses most of these issues so I think it is definitely
the way to go.
2018-07-13 13:37 GMT+02:00 Thomas Beale :
>
>
> On 13/07/2018 12:13, Diego Boscá wrote:
>
>>
On 13/07/2018 12:13, Diego Boscá wrote:
Technically in ADL1.4 it is completely legal that alternatives have
their own node codes. Other thing is that OPT or current software
supports it
it is legal, but not always implemented. Your group (UPV) did the right
thing with LinkEHR early on, and
Technically in ADL1.4 it is completely legal that alternatives have their
own node codes. Other thing is that OPT or current software supports it
2018-07-13 13:05 GMT+02:00 Thomas Beale :
>
>
> On 06/07/2018 18:03, Pablo Pazos wrote:
>
>> Hi Dileep,
>>
>> In the EHRServer we use the template
On 06/07/2018 18:03, Pablo Pazos wrote:
Hi Dileep,
In the EHRServer we use the template path as an absolute path for each
node in the template, that allows to identify each node in the OPT
even if different nodes hang from the same archetype root (have the
same archetype path). This
Hi Dileep,
In the EHRServer we use the template path as an absolute path for each node
in the template, that allows to identify each node in the OPT even if
different nodes hang from the same archetype root (have the same archetype
path). This allows querying for the right node.
Also there is
Thanks Ian,
I will also test with Ethercis and update
regards
Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in e: dil...@healthelife.in
On Fri, Jul 6, 2018 at 8:12 PM, Ian McNicoll wrote:
>
Hi Dileep,
I'll check the AQL against Ethercis ASAP - Chrisitian has done a lot
of work in this area recently.
The issue of how best to distinguish different nodes on the same path is an
old and long conversation. There are quite a few different requirements/
use-cases.
What I suggested is
Thanks Ian/Silje,
I will take a look at what Ian has suggested. But if Ethercis dos not
support it, I will be back to square one. In that case would specializing
the person_name and organisation archetypes for requester and receiver make
sense?
On further thought, I feel that what Ian has
As a side note, the “Service request” archetype has just (yesterday, in fact)
been published as INSTRUCTION.service_request.v1.
Regards,
Silje
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On
Behalf Of Ian McNicoll
Sent: Friday, July 06, 2018 11:16 AM
To: For
Hi Dileep,
The usual approach I take here is to rename the clustered archetype to
reflect local use, which works out as
[openEHR-EHR-COMPOSITION.request.v1]
[openEHR-EHR-INSTRUCTION.request.v0]
[openEHR-EHR-CLUSTER.organisation.v0, 'Requesting organisation']
Hi,
We are trying to create a service request template using the following
structure
[openEHR-EHR-COMPOSITION.request.v1]
[openEHR-EHR-INSTRUCTION.request.v0]
[openEHR-EHR-CLUSTER.organisation.v0]
[openEHR-EHR-CLUSTER.person_name.v1]
[openEHR-EHR-CLUSTER.organisation.v0]
11 matches
Mail list logo
