CODEWITHSUNDEEP
androidhl7hapi
Ankit
Ankit

Reputation: 256

HL7 database setup and android client to store patient info in hl7 format

I am very new to clinical system development. We are having one android application which store some patient information locally. Now we want to store this info to HL7 system. Here what I want to know at first level:-

1) I know some what about HAPI which provide api to generate HL7 messages, is it correct? Like can we use it with android or is there any other java library?

2) We want to setup HL7 data base and service at our end on which my android app can store data remotely. So for this as per my basic search I found openEMR , mirth.. so can any one please give more info for this kind of setup. And suggest proper way to do it.

Thank you in advance. :)

Regards, Ankit

Upvotes: 2

Views: 1461

Answers (1)

Shamil
Shamil

Reputation: 940

I would post this as a comment rather than the answer, but it seems I don’t have such capability (no “add comment” button). My comment would be that you need to refine your question a bit since there are no such things as HL7 systems and HL7 database. The HL7 standard is a vehicle to communicate medical data, it does not govern (and it should not) how systems handle and store these data. Similarly as POP3/SMTP protocols do not govern how to build an email client and store emails. Furthermore, it is not feasible to use the HL7 RIM as a database structure pattern, you will end up de-normalizing it a lot (Abdul-Malik Shakir did a presentation about it).

What it means is that you are free to use any database and DB structure for your application; same is true for the remote system. This may answer your second question.

Next thing to do is to find out what exact messages you need to support in order to exchange medical data. It might happen that all you need to do is to request/update patient demographics. Or request and present a CDA report. In such case you may build your own custom library and support only a small subset of segments (for HL7v2) or messages (for v3). The trade off of such solution is that it is not easily scalable.

Ps. If possible, move this to comments.

Upvotes: 1

Related Questions