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]

Reply via email to