Thomas Beale schreef:
> Bert,
>
> just look under 'test' - all kinds of archetypes like this -
> http://www.openehr.org/wsvn/knowledge/archetypes/dev/adl/test/?rev=0&sc=0
>
Thanks Thomas, very useful, saves me lots of time
Bert
> - thomas beale
>
>
Tim Cook schreef:
> On Wed, 2007-11-21 at 13:14 +0100, Bert Verhees wrote:
>
>> Is there somewhere an archetype available for testing purposes, which
>> has all/many possible item-kinds in it?
>>
>> If there is not, I shall make one, does someone want to have it?
Is there somewhere an archetype available for testing purposes, which
has all/many possible item-kinds in it?
If there is not, I shall make one, does someone want to have it?
Bert
Tim Cook schreef:
> All,
>
> I have tried (on this and other lists) to set my preferences so that I
> receive a copy of my own email. Mostly because I have no clue of what
> I sent to which mailing list I guess. :-(
>
> I NEVER seem to recieve a copy of the email I sent.
>
> Now I really thin
ed in the specs. How will that look like, from technical
view: I can imagine, this will be a service as in (http) SOA/SOAP-level
Maybe I am wrong, so please tell me were to read more about it.
regards
Bert Verhees
r idnependency
- OORDMS's are much more expensive
- they are less mature
And to map the RM-objects to a relational database it is really
suffcient to use ANSI 1992 SQL, which means that your SQL-code is not
vendor-specific.
regards
Bert Verhees
% functionally, only I have bad luck when
looking at the source (looking at those 10% not ready?)
I don't know, please explain to me how to find the reference Eiffel
implementation source as used in the ADL-workbench.
Thanks very much
kind regards
Bert Verhees
-BEGIN PGP SIGNATURE-
> Bert Verhees wrote:
>>
>> In so far, not because I like to disagree, but regrettable, many of the
>> function/method-bodies in the Eiffel-code are empty. Eiffel seems merely
>> to be/have been used as a kind of case-tool instead of really building
>> a openehr k
ehr is a great concept, and Ron's Java-kernel is a
great piece of work, the C# kernel is to, I am sure, it is build close
to the source of design.
I am building a Java-implementation too, based on Rong's kernel, he has
solved many problems and set directions, I am now using, and extending
t
Thomas Beale schreef:
> Bert Verhees wrote:
>
>> Maybe it is already being repaired, just for sure
>>
>> http://www.openehr.org/uml/release-1.0.1/Printable/Printable.html
>>
>> does not work
>>
>>
>>
> Bert, I think you have an ou
Maybe it is already being repaired, just for sure
http://www.openehr.org/uml/release-1.0.1/Printable/Printable.html
does not work
Bert
forgot to end my previous email properly, and the phrase in the end was
generated by Fortune, a small Linux-program which does that in my emails, and
I leave them sometimes, when they are funny or in another way good.
Kind regards
Bert Verhees
Op Monday 06 August 2007 22:38:20 schreef Tim Churches:
>
>
>
>
> I'm not sure whether that means it supports queries or not - I suspect not.
>
> So for an open-source implementation of openEHR, it looks like, as at
> August 2007, one has to either wait an indeterminate length of time for
> the
u bring it up. I
hope others will say something about this subject.
Thanks
Bert Verhees
Most convenient to me is to send it to the announement list, it is were it
belongs, it is easy for people to subscribe (I just did, for being sure)
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-announce
regards
Bert Verhees
> Bert Verhees wrote:
>> I don't know if it is a problem with a plugin form Firefox, never had
>> this problem before.
>>
>> But the menu-structure of the openehrwebsite on the left is not visible
>> in my Firefox.
>>
>> It does work in the Inter
the rebuild of the website, some
days ago.
I think, it must be an error in NoScript, I will report it to
Mozilla/NoScript
Thanks for your help.
regards
Bert Verhees
> With best wishes,
>
> Nathan
>
> ---
> Nathan C. Lea
> Research Fellow
> Electronic
I don't know if it is a problem with a plugin form Firefox, never had
this problem before.
But the menu-structure of the openehrwebsite on the left is not visible
in my Firefox.
It does work in the Internet Explorer.
Am I the only one experiencing this?
Thanks
Bert
life, father.' And the Dalai Lama smiled and
said, 'Well my son, life is like a beanstalk, isn't it?'
>
>
>
>
>
> On 20-mrt-2007, at 9:17, Bert Verhees wrote:
>
>> Gerard Freriks schreef:
>>
>>> Yes.
>>>
>>> I've '
Gerard Freriks schreef:
> Yes.
> I've 'translated' almost all of the terms.
> translating it is not easy.
> Several times the English term is good enough and the only reasonable one.
When are you planning to publish what you have already translated?
Is it in your plans to publish it?
Bert
Gerard Freriks schreef:
> Yes.
> I've 'translated' almost all of the terms.
> translating it is not easy.
> Several times the English term is good enough and the only reasonable one.
We use a many English words in Dutch. As long as Dutch, without
knowledge of English can understand the it (as long
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> error in the class Participation, Also the same for "Participation mode"
> (which does exist), which has no childs/members at all. I added also
> "unknown" as child. Because the class Participation is not allowed to have
> Void on function and mode.
Sam Heard schreef:
> Hi All
>
> The XML is used for the archetype editor and so has a real GUI use as
> well. This is probably not ideal in the long term so we probably need
> to separate out the GUI information from the hard openEHR terminology
> that is used for processing.
For me, the XML has
>
> Thanks for this Bert; we have raised a CR -
Thanks, Thomas, I found out, there is also a Instruction transition,
which, maybe, I think, must be "ISM Transitions"
I worked a lot last week writh this file (terminology.xml)
I also found group "Participation function" is missing, I added it mysel
7;t it be "ISM state"?
Bert
>
> Regards,
>
> Mattias
>
>
> 2007/3/16, Bert Verhees <mailto:bert.verhees at rosa.nl>>:
>
> This line is in it:
>
>
> when you go to grouper:
>
>
> and then to groupedconcept:
&g
This line is in it:
when you go to grouper:
and then to groupedconcept:
etc
which points to:
etc...
I wonder if the above (first) line should be
because this is also in the PDF-documents: terminology.pdf page 22
and in support_im.
Let me resume the discussion about this subject from last few days:
The terminology service, as defined in openehr is, as I understand, not
suitable or meant for generic codeset-interface. It is more or less
special for Openehr-terminology.
Thomas mentions, writing a terminology-service costs se
ervice
on my own, because I need it, and good or bad, but probably not in sync
with further developments on OpenEhr-specs.
But that is where we have versions for, isn't it? ;-)
I didn't know about CTS, I will look at the HL7-site to find more information
regards
Bert Verhees
__
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rahil Qamar schreef:
> Hi Bert
>
>
> Bert Verhees wrote:
>
>> It is not that problem. There is a terminology-interface, below, you
>> can do whatever you want. Webservices/databases, everything is possible.
>>
Bert Verhees schreef:
> Thank you Rahil, for replying.
>
> Rahil Qamar schreef:
>
>> Hi Bert
>>
>> I had a read through your posting. I have one query though. Which
>> terminology are you planning to use? The openEHR terminology is very
>> small and l
Thank you Rahil, for replying.
Rahil Qamar schreef:
> Hi Bert
>
> I had a read through your posting. I have one query though. Which
> terminology are you planning to use? The openEHR terminology is very
> small and limited in scope and content which makes it fine to be
> available in the curren
I found it out, partly, myself. The document
RC1.1/publishing/architecture/computable/terminology/Terminology.xsd.html
(in my local copy of the repository) was very helpful.
I, now, more or less understand the structure of classes which form the
terminology.
*Please correct me if I am wrong.*
I
Hi,
I hope this is a stupid question, and people can overload me with
information.
I am trying to build a terminology-service, but because I want to
conform as much as possible to the specs, I try to understand them.
I have a few questions:
we have the openehr-terminology, like this: (excuse
Williamtfgoossen at cs.com schreef:
> In een bericht met de datum 19-12-2006 10:52:14 West-Europa
> (standaardtijd), schrijft bert.verhees at rosa.nl:
>
>
>> You mean, for free? Paid by the resp. governments?
>>
>> That, I did not know.
>>
>> Bert
>
>
> Yes, that is what I mean, and Denmark and th
Williamtfgoossen at cs.com schreef:
> In een bericht met de datum 18-12-2006 18:00:54 West-Europa
> (standaardtijd), schrijft mattias.forss at gmail.com:
>
>
>> Maybe you're right, the definitions could be added as comments, but
>> for proprietary terminology like SNOMED CT this will mean that th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Information about the failing of a world famous 4 billion costing EHR
I found these links on a closed (payed dutch) mailing list. Maybe
someone finds this interesting.
http://histalk.blog-city.com/
http://www.ihealthbeat.org/index.cfm?action=dspItem&
Bert Verhees schreef:
> Mattias Forss schreef:
>
>> Well, I'm no expert on XSD since I never cared about learning it...
>> but if I go back to your example, why didn't you use xsi:type in some
>> places, for example:
>>
> I don't know
Mattias Forss schreef:
> Well, I'm no expert on XSD since I never cared about learning it...
> but if I go back to your example, why didn't you use xsi:type in some
> places, for example:
I don't know if you ever saw this site, I did, it was helpful
Bert
William E Hammond schreef:
> You assume the worst of me. It seems that looking at actual
> implementations of both 13606 and V3 will provide excellent experience data
> for both groups. I know V3 implementations, and did not know many 13606
> implementations, altho I do know one system that has s
ld be facilitated in an Elias and Arcos
interface, with an OpenEHR engine below.
No problem at all.
>
> My point is that you need to change to new desigs to make it work.
I agree with that.
Kind regards
Bert Verhees
-- next part --
An HTML attachment was scrubbed.
Williamtfgoossen at cs.com schreef:
> Good Point Ed,
>
> Until now the list of actual OpenEHR implementation I have actually
> seen working is 0
William,
I told before on this list, English is not even my second language, but
I do what I can to be understandable.
---
Now to your "Good Point,
, at this moment I don't have time to look at it, I am very glad
the sourcecode has been published.
This gives me that wonderful feeling of being independent ;-)
regards
Bert Verhees
> Please take your time to read the release notes before installing the program.
>
> The Archetype
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Churches schreef:
> Bert Verhees wrote:
>> I stopped this work because there is a bug in the java-kernel concerning
>> Archetype-slots, which are really necessary for this job.
> ...
>> The code I wrote is however based on
-- next part --
An embedded message was scrubbed...
From: Bert Verhees
Subject: Re: Sources of information on HL7 EHR/OpenEHR
Date: Thu, 14 Sep 2006 14:47:12 +0200
Size: 5180
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachme
>> al").
>
> well, I can't speak for "the designers" (I'm spending some time with him
> today on this subject ;-) , but archetypes and HL7 models are the
> same thing.
> I can interconvert between them. The only issues are syntactical
> differences
> in things that are allowed in each lang
>> al").
>>
>
> well, I can't speak for "the designers" (I'm spending some time with him
> today on this subject ;-), but archetypes and HL7 models are the same thing.
> I can interconvert between them. The only issues are syntactical differences
> in things that are allowed in each languag
Mattias Forss schreef:
> 2006/9/2, Bert Verhees :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Mattias Forss schreef:
>
>> > We used (and modified) parts of the code from the existing editor
>> > which was used as a facade against th
for not to enforce the OpenEHR reference model. With all
respect to the design of that model (clever people work hard on it. I
sure want to follow that in the near future), I think it can be good if
it is possible if people have good reasons to do something else with
ADL, to facilitate that.
So in
,
which causes me to search every character.
> 2006/8/28, Bert Verhees :
>>
>> > There is already a Java-based archetype editor available here:
>> >
>> > http://svn.openehr.org/knowledge/archetypes/dev/index.html
>>
>> Too bad, the sourcecode still is
Thanks Mattias for your answer. I keep it short, now, the weather has
improved, and I am on holiday ;-) and the keyboard-layout still is French,
which causes me to search every character.
> 2006/8/28, Bert Verhees :
>>
>> > There is already a Java-based archetype edi
not look at those who exists, he could get
trapped in obvious thinking.
These are only some suggestions from a rainy day in region of the South
Central France
regards
Bert Verhees
>
> Regards,
>
> Mattias Forss
>
> 2006/8/27, minreddy minreddy :
>>
>> Hello
>>
tand when you check the JUnit-tests.
I guess tomorrow you will get better answers,many readers are to a
congress in Maastricht
regaeds
Bert Verhees
>
>
> rgds
A> minreddy
>
>
>
> -
> Stay in the know. Pulse on the new Yahoo.com.
good question!!!
(though, seems an implementer-question to me)
I hope you get a good answer, interesting for me, also
regards
Bert
Rodrigo Filgueira schreef:
> Maybe I sent it to the wrong place originally.
> Any ideas?
>
> thank you
>
> ---
Hi
Does it make sense to learn previous versions of ADL for use of OpenEhr.
I ask this because ADL 1.3 is well documented, and I saw the document
updated lately (februari) and maybe it is still important?
Or maybe it is not? And is it sufficient to know about 2.0
A human, like me, only has a cer
>
> You refer to machine computer system interfaces and that these might
> be proprietary. Yes they could and will.
> But when the holy grail is about plug-and-play interoperability then
> these interfaces (archetypes) must be free to use.
Gerard, how about SNOMED-tables, they are expensive, and m
in their IDE
- Eiffel has Design By Contract build in, you can do that in other languages
to, but in Eiffel, some language features are really only there for this.
When you see the presentations on www.eiffel.com, you will see
regards
Bert Verhees
e, and I do not have much
time, regretly, so, too bad ..
Thanks
Bert
>
> On 4/26/06, Bert Verhees wrote:
> > Hi,
> >
> > I have some problems with the Eiffel-sources.
> > I made my way to understanding and even loving the Eiffel compiler, and
> > now I want t
thanks
Bert Verhees
Op maandag 24 april 2006 17:11, schreef Thomas Beale:
> Bert Verhees wrote:
> >> available in the API) requires a higher level of access than other
> >> operations, i.e. cannot just be done by any normal user - it might
> >> require a system administrator wit
where the
information is in tact. I do not understand why, because when the law in
case of art 455 says that it is not allowed (destruction means no way
back!!) to revert back, why should openehr want to revert back?
But as I said, it is not important to me, at the time it occurs I will
find my way to comply to the law.
regards
Bert Verhees
Thomas Beale schreef:
>
> Bert,
>
> I think you are making this much more complicated than it needs to be.
> There is nothing /a priori/ to stop physical deletion of _parts_ of a
> record. However in version controlled systems, something special
> behind the scenes is usually needed to effect it
fine now.
(http://oceaninformatics.biz/archetypes/)
Thanks
Bert Verhees
Op maandag 24 april 2006 01:26, schreef Thomas Beale:
> Bert Verhees wrote:
> > It is said in
> > http://www.openehr.org/getting_started/t_openehr_primer.htm that one
> > of the disadvantages of current health-care information systems is the
> > costs and difficulties t
.
Apache/2.0.50 (Fedora) Server at oceaninformatics.biz Port 80
Can someone tell me where I can find those?
Thanks in advance
Bert Verhees
-- next part --
An HTML attachment was scrubbed...
URL:
<h
plemented a
removal functionality is a very difficult issue, but it also states that
it is regarded to be necessary, and will be implemented.
I quote:
"The project has plans, however, to someday implement an *svnadmin
obliterate* command which would accomplish the task of permanently
deleting information."
It would, in my opinion be good when OpenEhr would have this goal too.
Thanks
Bert Verhees
gt; - thomas beale
>
> Bert Verhees wrote:
>> Op vrijdag 14 april 2006 14:29, schreef Bert Verhees:
>>
>>> Gerard, thanks for your explanation.
>>>
>>> I was a bit confused by the ISO18308-conformance document
>>>
>>> I understand now,
missing both legs in a GP-office in your town, then it
will be very easy to connect that record to a person, even when the
connection does not anymore exists in the database.
Concluding, there may be cases where logically deleting will not be
sufficient, so there may be cases that physically removal will be
necessary, to be compliant with the law.
Regards
Bert Verhees
Gerard Freriks schreef:
> Dear all,
>
> In the paper world, I know, it is clear.
>
> A document with legal implications can never be destroyed without any
> trace.
> A document with legal implications can be removed from a registry in
> one place and moved to a special registry, folder, cupboard,
t;
> voor info van het Juridisch lab.
>
>
>
> Gerard
>
>
>
>
>
> -- --
>
> Gerard Freriks, arts
>
> Huigsloterdijk 378
>
> 2158 LR Buitenkaag
>
> The Netherlands
>
>
>
> T: +31 252 544896
>
> M: +31 654 792800
>
>
>
First, I want to thank everyone for their contributions on this discussion, it
helped me a lot.
Now I discovered today, there is a law in the Netherlands which obliges
care-takers (GP's etc) to remove all records for patients demanding this
(within 3 months of demand, and after some years of no
Op maandag 17 april 2006 04:08, schreef Sam Heard:
> Hi everyone
>
> In fact both situations are available in openEHR. In the general case and
> without access to the repository it is only possible to create a new
> version which has no information and mark it as deleted. This is generally
> true
Let me enlighten my question
Bert Verhees schreef:
> Thanks again for the help with the authorization-question, I was lost
> in the wrong document of the specs.
> I must say, reading the specs, really is not something for a rainy
> afternoon, but it is worth it.
>
> I hav
nd it.
--
Is it possible to delete a composition in a way that is not traceable
anymore?
A short answer will do, maybe with a pointer to where to find this
information
Thanks in advance
Bert Verhees
Op vrijdag 14 april 2006 14:29, schreef Bert Verhees:
> Gerard, thanks for your explanation.
>
> I was a bit confused by the ISO18308-conformance document
>
> I understand now, that there are classes X_ACCESS_CONTROL and ACCESS_GROUP
> to handle this.
But the first is for EHR_
ts granted in
> the authorization phase.
>
> Gerard
>
> -- --
> Gerard Freriks, arts
> Huigsloterdijk 378
> 2158 LR Buitenkaag
> The Netherlands
>
> T: +31 252 544896
> M: +31 654 792800
>
> On 14-apr-2006, at 13:12, Bert Verhees wrote:
> > A GP a
would be only one extra authorization necessary,
the patient must allow the GP to use all the archetypes, he as a GP is
entitled to use.
But maybe, very well possible, I am overlooking a lot, so
Please help me thinkig about this
Thanks
Bert Verhees
the best advise?
Thanks in advance for any hint/answer
Bert Verhees
om me and other "ignorants" what this is about
(or pouint with an URL)
thanks
Bert Verhees
Because OpenEhr specs are developed with help of EiffelStudio, this
could be interesting for developers
http://www.eiffel.com/general/news/2006/2006_04_05_pr.html
http://eiffelsoftware.origo.ethz.ch/index.php/Main_Page
regards
Bert Verhees
> The paper of Scott W. Ambler is very interesting in this context
> (google for it)
http://www.ambysoft.com/essays/persistenceLayer.html
>
> Bert
>
>
>
> There are no persistence layer defined in the OpenEhr specs, Thomas
> said there will be specs for this after some time.
While reading the rest of the mails (I was a week or more behind), I see
there is a lot of work being done (I have not yet read it all).
I agree with Rong Chen that persi
>Of cause it is possible to hide everything behind a persistence layer
>_interface_ and doesn?t talk anything about what we have behind the
>interface. But the subject and quite many of the mails had talked about the
>persistence layer (and not the interface), then it is necessarily to know
>what
Rong Chen wrote:
> Bert Verhees wrote:
>
>> Dear Mikael, since I initially started the discussion, I explain what
>> my needs/opinions are.
>>
>> A good persistence-layer reflects the classes which want to be
>> persistent.
>
> Do you have any speci
Dear Mikael, since I initially started the discussion, I explain what my
needs/opinions are.
A good persistence-layer reflects the classes which want to be persistent.
The classes do not need to know what DB-vendor is involved.
There will be no db-vendor specific code in the main application, the
Kevin M. Coonan, M.D. wrote:
>Shouldn't heavy weight queries be limited to a separate OLAP platform? This
>
>
This is what I have seen at a large data-processing company where I used
to work for.
They ran separate tables, optimized for OLAP-queries (wide flat ugly
tables with lots of data-red
> We are working on two or 3 variants at the moment. The general form of
> the stored information is logically a 2-column table of:
>
>
>
> you can convert an entire object network to this form and store it
> efficiently. Because the paths are archetype-based paths, you can
> query quickly int
Are there plans to work out concepts for an persistence layer
Thanks in advance for an answer
--
regards
Bert Verhees
Thomas Beale wrote:
> Bert Verhees wrote:
>
>> I guess it is framemaker
>> Do I need these files, SVN downloaded many of them, or is the
>> information already elsewhere in other files (and up to date)?
>>
>> regards
>> Bert Verhees
>
> No, you
I guess it is framemaker
Do I need these files, SVN downloaded many of them, or is the
information already elsewhere in other files (and up to date)?
regards
Bert Verhees
an someone point me to locations on the Internet where this is discussed, or
can someone explain this for me?
I will be very thankful.
--
Kind regards
Bert Verhees
er archetype to store the "Weight".
Or am I completetely misunderstanding the issue, and is it in fact a
non-issue.
Please explain to me.
Thanks in advance
Kind regards
Bert Verhees
Karsten Hilbert wrote:
>On Fri, Jan 20, 2006 at 09:42:29AM +0100, Bert Verhees wrote:
>
>
>
>>Cache it is an expensive database-engine. But so is Oracle or SQL-server.
>>They
>>are all expensive.
>>
>>
>Well, there's always the OSS vers
hange notation, and an offer from Microsoft to buy the
company was rejected by its owner on other then financial reasons. The owner,
Terry Ragon, loves his company, and is commited to MUMPS since the very early
days in 1978.
So there are no stockholders which decide, but only he.
rega
I wonder, Ian, did you ever looked to Cache (www.intersystems.com)
It is called Post-relational, this is because it also can understand SQL.
But it is a kind of OO-database, I don't know if it has all the
OO-particularities like (multiple)inheritence, or object as field of another
object.
Anyway
resentation or persistence layer allowing
> EHR systems implemented with different GUI and persistence can interact
> with each other.
Am I wrong when I think this will be the publishing of data to be used in a
GUI, because a GUI is not only denpending on datasets, but also on
usability-guidelines?
--
regards
Bert Verhees
t an open specification and open source project.
> well, if they just want a running system, they can get one elsewhere
> faster. But if they are thinking in a 5-year time frame, waiting a bit
> might be useful. THey won't get archetypes or an open EHR data model
> and interoperable (and CEN-compliant) schemas elsewhere that I know of.
It seems Acode has done a good job already, I learned from an email
published after this in this group
>> By the way, I saw in the Eiffel Studio a menu-option: Export To XMI.
>> Could that be useful? Is it possible to do those basics things here
>
Give it a try, and send me the XMI, just for fun, but I am afraid, I did
it with a default project from eiffel, al the classes I did not ask for
are in it also.
So, maybe it is not very useful.
regards
Bert Verhees
in a special list, and all association related messages to the
main list.
It didn't work, because no-one was reading the technical list, and all
messages in the main list got the attentention, so people only
interested only in association-news had to read their mail with a finger
on the delete-button
regards
bert verhees
kernel? I wonder.
Really good news, I hope we will learn more.
In fact, that will be the whole thing, the rest is proven technology,
isn't it?
regards
bert verhees
Ian McNicoll MMS wrote:
> Hello again Rong,
>
> Glad to hear things are progressing. Do you have any thoughts about
o what you state below, this means that there is
still a long way to go for OpenEhr before it will be implementable.
Is that true? Do I understand that well?
regards
Bert Verhees
>
> I suspect there is no correct way of doing this. It will depend on
> circumstances and very rapidly ch
errible
I have never seen something like that, but I guess there must be some logic
behind it.
I guess when one is used to this kind of things, one can work with it, and be
productive, but I can imagine it scares people away.
Not really ideal for getting an open source project popular.
I will r
801 - 900 of 969 matches
Mail list logo
