In the next year 2010, Medinfo 2010 will be held in Captown, South
Africa.(http://medinfo2010.org/)
I would like to have a workshop in the openEHR implementation in Eiffel,
Java, Python and Ruby to examine the universality and availability of
openEHR specification. It is interesting that each implementation has
its own feature in contrast.
Fortunately our Ruby implementation is progressing step by step, some
demo will be shown in the session.
I would like to hear comments by other language leaders. Is'nt this a
good idea?
I would suggest that we show interoperability in action. Lets send a couple
of extracts between a few different systems such as those by Tim Cook, Bert
Verhes, Rong Chen, Shinji KOBAYASHI, Opereffa, OceanEHR....
Yes, it would be a great impact to show such 'archetype connectathon'
amongs diferent systems.
Otherwise, all the people shown bellow will not be able to join the
Medinfo2010 because of their schedules.
Please reply this mailing list or direct to me, if you will join the
Medinfo2010.
Moreover, please help me to organise this workshop, Sam. It is no doubt
that you are one of the most suitable people for this session.
I agree that we should begin developing a plan for this. I will likely
NOT be at Medinfo but as long as we have internet connectivity that
should not be a problem.
At first thought; though I haven't looked at the artifacts in detail:
1) We should probably use the SOAP note approach that Operffera has
started with.
2) We should define 3-5 patients (maybe Ocean can contribute here).
3) Possibly have one source point to create documents and then pass them
around making minor additions/changes and recording screen shots from
each application.
4) The documents end up back at the source point to validate all
original data plus changes.
I hope that as we push for a focus on SOAP & Summary clinical material
to get the archetypes/templates right, that would form the basis of a
simple yet effective requirement for that Medinfo interoperability demo.
A variety of SOAP notes could be generated per patient..
A Summary view of each patient should pick up the relevant material from
those SOAP notes to populate the summary.
Users should perhaps be able to see the patient summary from any system,
perhaps just the SOAP notes within the originating system?
As Tony Shannon pointed out, SOAP note has much diversity. We needs to
implement the versioning system and how to serialize the versions.
Although the versioning system of the openEHR specification seems to be
perfect for such distributed versioning condition, the common
information system specification has not determined the
serialization(http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf
, p44)
I think the referral letter amongs organisation is preffer because it
needs less strict versioning.
I agree that we should begin developing a plan for this. I will likely
NOT be at Medinfo but as long as we have internet connectivity that
should not be a problem.
Medinfo2010 is 13 months away. Seems like a long time in some respects
but if we are going to really put on a "road show" of interoperability
then we really need to start developing a solid action plan.
KOBAYASHI, Shinji made a good point about referral letters simplicity.
But... my belief is that *THIS* is the opportunity for openEHR
implementations to come out of the closet and make the splash that
commercial and open source systems of different sizes can shared
information without loss of semantic interoperability; using significant
and meaningful information.
I think that Tony's ideas below are something that we should work
towards detailing out for a true demonstration "with meaning".
But, we must begin to get organized.
Who's in and commited?
Should we scheduled quarterly conference (Skype) calls? Say beginning
in September?
I do not believe that we must be in attendance at MedInfo. In fact it
may be a much better demo if at least some of the sites are remote.
I'll volunteer to begin organizing this project unless someone else
prefers to do it.
In the next year 2010, Medinfo 2010 will be held in Captown, South
Africa.(http://medinfo2010.org/)
I would like to have a workshop in the openEHR implementation in Eiffel,
Java, Python and Ruby to examine the universality and availability of
openEHR specification. It is interesting that each implementation has
its own feature in contrast.
Hi Shinji, it is a good idea, to show what several people/companies have
achieved. It can really draw new attention.
This will be beneficial to us all.
I don't think of traveling to SA myself. To be honest, it is rather
expensive to travel from the Netherlands, hotel expenses, etc. As being
an independent developer no-one is paying my expenses. There is no
direct return on investment expected if I would pay it myself, because I
am targeting to the Dutch market to sell my work.
But generally spoken, it is a good idea to show the strength of Openehr,
not only in idea, but also in follow up on the market.
As Sam suggested, there may be a way for people not going to SA, to
contribute, in some way.
It is some time until September 2010, but when time comes, if some one
has ideas how I can contribute, just ask. I will be glad to participate.
But generally spoken, it is a good idea to show the strength of Openehr,
not only in idea, but also in follow up on the market.
As Sam suggested, there may be a way for people not going to SA, to
contribute, in some way.
It is some time until September 2010, but when time comes, if some one
has ideas how I can contribute, just ask. I will be glad to participate.
Bert,
I am also an independent developer (not certain if I am going or not yet) but anyway this is why I
followed up on the earlier recommendation for the CONNECT-A-THON.
I'm quite certain that we could get Internet access there and we could demonstrate actually
transfering documents (Tony suggested a SOAP note) between sites making modifications along the way.
This will certainly require some logistical planning that is why I suggest we start soon.
Please note that section 1.2 contains this as well as several other
related documents in order to attain full understanding.
It would be a lot easier to do data exchange if someone define a WSDL
and used the archetype identifiers inside an structured XML document.
If you would like to be that someone to define an XML schema that meets
all of the version control, audit trail response, security, etc.
requirements of openEHR queries I am sure the community would be
grateful.
"Keep everything as simple as possible; but no simpler."
-- Albert Einstein
If you'll notice; the extract document is a 2 year old draft that is
heavily dependent upon the settling out of the query language. It has
many places where there are questions to be answered. It also probably
needs heavy review in order to bring it up to date with the latest RM
release. This is an open source project so maybe it is time that some
of us step up and take care of this issue instead of just complaining
about it being incomplete?
Please note that section 1.2 contains this as well as several other
related documents in order to attain full understanding.
It would be a lot easier to do data exchange if someone define a WSDL
and used the archetype identifiers inside an structured XML document.
If you would like to be that someone to define an XML schema that meets
all of the version control, audit trail response, security, etc.
requirements of openEHR queries I am sure the community would be
grateful.
We do plan to expose data exchange via web services out the box and that would include Archetyped data as well as other sources so that is certainly on the cards.
For the version control, audit trail, security defined as part of the OpenEHR I think the barrier to entry is too high and we would stick with our own internal system for managing audits and security and provide information more in line with HL7 CDA , CCR requirements.
“Keep everything as simple as possible; but no simpler.”
– Albert Einstein
If you’ll notice; the extract document is a 2 year old draft that is
heavily dependent upon the settling out of the query language. It has
many places where there are questions to be answered. It also probably
needs heavy review in order to bring it up to date with the latest RM
release. This is an open source project so maybe it is time that some
of us step up and take care of this issue instead of just complaining
about it being incomplete?
Better to receive some feedback than have it ignored.
I suspect that the extract is too complex to gain traction and something simpler is required. I would propose starting by defining some simple REST interfaces or XML over HTTP to allow the community to query our implementations and at least get started.
If everyone disagrees and prefer to work the extract then I will put this on the back burner..
