Hi, Delaying answering to this e-mail until I contemplate some more on Roger's and Darius's comments... On 28 Apr 2012 12:01, "Darius Jazayeri" <djazayeri+...@gmail.com> wrote:
> Hi Suranga, > > Is there a particular reason you're doing this via the REST web service > module? It's not like typical REST clients will know how to receive HL7 in > any meaningful way. > > Why not just listen for queries on some other URL (i.e. not > rest/v1/patient) and return HL7 from there? > > -Darius > > On Fri, Apr 27, 2012 at 9:30 PM, Suranga Kasthurirathne < > suranga...@gmail.com> wrote: > >> >> >> Hi Dr. Burke / everyone, >> >> Sorry for the late reply, >> In that case, I had better return text/hl7. I'm using hl7 v2.5, >> so don't think I can use the hl7-v3 version. At this stage of the >> process, I'm only working on how to return Encounter/s. I must admit I had >> not given any thought on how to return a Patient before :-) >> >> >> On Fri, Apr 27, 2012 at 10:05 PM, Burke Mamlin >> <bmam...@regenstrief.org>wrote: >> >>> Suranga, >>> >>> I believe the media type in the request, specifically the media >>> specified by the Accept: header, is used to determine the format of the >>> response (JSON vs. XML vs. HL7). So, Accept: text/plain would, were it >>> supported, be asking for a plain text version of the patient, which might >>> not be useful. For lack of a standard media type for HL7, I would suggest >>> using text/hl7 or perhaps text/hl7-v3. >>> >>> BTW… HL7 v2 is a primarily an event messaging specification rather than >>> a way of describing resources. Are you looking at v3? What type of >>> document would you return if someone asked for a patient in HL7? Any >>> chance you are using Apache Camel <http://camel.apache.org/hl7.html>? >>> >>> Cheers, >>> >>> -Burke >>> >>> >>> On Fri, Apr 27, 2012 at 12:09 PM, Suranga Kasthurirathne < >>> suranga...@gmail.com> wrote: >>> >>>> >>>> Hi, >>>> >>>> Thanks Ben, >>>> @Dr. Burke, Yep, I want to use HL7 as an alternative to JSON. At this >>>> moment I have not given any thought to the media type (still working on >>>> getting the skeleton up and running). But for the initial version, I'd be >>>> quite happy with text/plain :-) >>>> >>>> Best regards, >>>> Suranga >>>> >>>> >>>> On Fri, Apr 27, 2012 at 7:28 PM, Burke Mamlin <bmam...@regenstrief.org >>>> > wrote: >>>> >>>>> Suranga, >>>>> >>>>> Do you mean HL7 as an alternative to JSON – i.e., you can request via >>>>> the header json, xml, or HL7? >>>>> >>>>> There are official media types for JSON (application/json) and XML >>>>> (text/xml); however, I don't believe there's an official media type >>>>> registered for HL7. What have you chosen? text/hl7? >>>>> >>>>> -Burke >>>>> >>>>> On Fri, Apr 27, 2012 at 4:19 AM, Suranga Kasthurirathne < >>>>> suranga...@gmail.com> wrote: >>>>> >>>>>> >>>>>> Hi Gents, >>>>>> >>>>>> A recent development from my foray into the REST web services module. >>>>>> >>>>>> I had made some improvements on top of the REST module. Specifically, >>>>>> I had modified the PatientController to return HL7 instead of JSON. >>>>>> Now, I want to develop a new module which depends on REST, and move >>>>>> my changes into that. In this case, I created the new module, and >>>>>> introduced a new Controller class which extends the PatientController. >>>>>> So of course, needless to say, I get an exception asking me to define >>>>>> a different URL (because both Controllers have the same URL) >>>>>> >>>>>> So I was wondering, can I extend a controller class (assuming that I >>>>>> introduce a new URL to the mix ? ) if I do so (since the parent and child >>>>>> have different URLs) wouldn't I have to manually call methods in the >>>>>> parent >>>>>> class from my Child class ? I dont think I have a alternative other than >>>>>> that..... >>>>>> >>>>>> -- >>>>>> Best Regards, >>>>>> >>>>>> Suranga >>>>>> >>>>>> ------------------------------ >>>>>> Click here to >>>>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>>>> OpenMRS Developers' mailing list >>>>>> >>>>> >>>>> ------------------------------ >>>>> Click here to >>>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>>> OpenMRS Developers' mailing list >>>>> >>>> >>>> >>>> >>>> -- >>>> Best Regards, >>>> >>>> Suranga >>>> >>>> ------------------------------ >>>> Click here to >>>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>>> OpenMRS Developers' mailing list >>>> >>> >>> ------------------------------ >>> Click here to >>> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >>> >> >> >> >> -- >> Best Regards, >> >> Suranga >> >> ------------------------------ >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]