Hi All,
There doesn't seem to be much momentum for finishing up the openEHR
Extract and using that as a document format to build a true SOA for
openEHR; but we need some formal framework for a document and a
transport mechanism.
I recently spoke to Sam Heard and he said that Ocean Informatics would
release the scripts that they have been using for CDA (r1 & r2). This
sounds to me to be the most reasonable solution. Select one of them
(r2?)
As far as transport goes I believe that we should use the Simple Object
Access Protocol. My primary reason for prefering SOAP over RESTful is
that SOAP is a well defined protocol whereas REST is an architecture
without a firm definition. Meaning that we would have to define the
services. It is my understanding that REST is more useful in situations
where you want to use a web services client application to perform CRUD
operations on a server whereas in our situation we will be exchanging
documents. Correct?
I know that the Ruby guys think that SOAP is ancient technology (I
prefer to think of it as mature) but see how easily Ruby can handle it:
http://rpheath.com/posts/298-consuming-soap-services-in-ruby
As far as "what" we should demo. I think Ian's email dated 12 August is
a good start. What does everyone think about developing three formal
use cases to demo?
It would be helpful if anticipated participants would list themselves on
this wiki page.
http://www.openehr.org/wiki/display/resources/Connect-a-thon
+Participants
After some discussion on the mailing list. I will attach a child page
with our use cases so we can fill them out.
Thanks in advance for your feedback.
--Tim
Hi Tim,
Thanks for the reminder about getting this going, sorry I haven't had a
chance to reply earlier.
From my experience so far I believe the EHR_EXTRACT draft is sufficient as
is and we should simply adopt it as the payload of an openEHR connectathon.
The alternative for those that want a more strongly typed payload is using
an extract of Template Data Documents although I realize this is yet to be a
published artefact.
What we are in need of is a service model, but I believe we can do this
fairly quickly based on some existing patterns such as IHE XDS
ProvideAndRegister and XDS querying but using openEHR EHR_EXTRACT payloads.
We should be able to knock this up together fairly quickly.
We could include the use of CDA R2 in the connectathon but I am reluctant to
suggest that this is the native exract for the following reasons:
1) CDA is a single document, openEHR extract allows multiple documents per
EHR and multiple EHRs (chapters) per extract.
2) the semantic and RM transformation is not for the faint hearted and
requires significant knowledge of both worlds.
3) CDA structures are not as extensible as openEHR archetypes
4) finally and most importantly, I would like to demonstrate a future world
of interoperability without the need for integration.
More later
Heath
THANK YOU!!! For making these great points.
I agree 100%
--Tim
I'd suggest starting with a SOAP solution and associated WSDL since
that will be familiar to more people.
That does not exclude the possibility for some inteRESTed people to
also agree on a preliminary RESTful extract service approach (The
semantics and syntax of appropriate URL patterns and some
documentation of expected PUT, POST & GET responses).
The core payload would be the same in both cases except that it will
be encasulated with SOAP evelope stuff in the SOAP based solutuion and
be pure openEHR extract XML in the REST case.
Best regards,
Erik Sundvall
erisu@imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579
P.s.
I wouldn't say that SOAP is ancient compared to REST. REST predates
SOAP, the web was built on REST principles from the beginning, ask the
inventors 
Hi Erik,
I would agree - why not ask which protocols each contributor would prefer. As long as at least one is prepared to support both REST and SOAP, we can still construct a set of connections.
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk
Clinical Analyst Ocean Informatics ian.mcnicoll@oceaninformatics.com
BCS Primary Health Care Specialist Group www.phcsg.org
2009/8/18 Erik Sundvall <erisu@imt.liu.se>