|Subject:||Re: [Health] Thalamus|
|Date:||Tue, 28 May 2019 14:29:18 -0400|
|User-agent:||Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0|
Dear Dr. Luis,
Thanks for the reply. more below
On 5/25/19 9:57 AM, Luis Falcon wrote:
I have installed the plugin into the native gnu health client per the instructions however I do not see how it works or if it has made any changes to the people model or pages of life. Can you explain how the plugin to be used from the client interface?Dear Bahaa On Fri, 24 May 2019 23:10:25 -0400 Bahaa Alamood <address@hidden> wrote:Dear Dr. Luis, Thank you and I will update next week when the new release is out. I have since set up a second node so I can see how data is synced or propagated between the two nodes, but no syncing happened. Here is what I tried to do: 1. I setup the first node and I have added a medical professional then I sent it to Thalamus and from querying the database I can see it is stored there and things are good.Great2. I created a second node and added an institution just like I did in the first node and I created a health professional there with the same name as the first one and I linked the 2 federation Ids together as it created a new one in the second node. 3. on the second node I created 2 new patients and I added a book of life page to one of them, and sent the changes to Thalamus and again it stored them in the DB. 4. I went back to the first node and tried to see if I can pull the patients info I stored in the second node, but nothing happened even though I gave the same federation ID. I looked in the logs, but nothing was logged too. My question is what is the correct workflow to make the data sync between the tow nodes when needed. I realize that the sync is asynchronous and it happens only when needed?The idea on GH Federation is not to replicate the information across the nodes, but to share it, making accessible when needed. That way we maintain the operational / transactional environment separated from the analytical and reporting environment. As you know now, the GNU Health Federation consists of three main components 1) Nodes : GH HMIS, future mobile app, GH portal ... 2) Message server : Thalamus 3) Health Information System : DB The GH HMIS nodes can send the information to the Federation using the health_federation package. GH HMIS node <--> Thalamus <--> GH HIS We can have different tools to import selected models. Let's take the case of demographic information that I want to import / update on my node from the HIS. The workflow would be: * New patient comes * The Federation ID is scanned. The system verifies if the person exists in the local node. * If it does not exist, you can query the GH HIS, retrieve and import the demographic information locally. * If it exists you may also want to query the HIS and retrieve the most updated demographic information of the person. To do this task, you can use the FRL (Federation Resource Locator) plugin (latest dev version http://hg.savannah.gnu.org/hgweb/health/file/tip/plugins/frl ). The FRL has two main fields, the resource (currently "people") and the ID. For more information about GH plugins please visit https://en.wikibooks.org/w/index.php?title=GNU_Health/Plugins Once you have the person registered in your local node, you can create the related patient and add the pages of life for the specific context.
another question how to change the role of the party from end_user to health_professional or root? can this be done from the Tryton client?No. The GH Federation Portal (vuejs web application) will be responsible for this. It has three main areas: * Resource management (fed accounts, roles , DUs, PoLs,...) * Person portal * Analytics / Reporting The GH Portal is being developed now, and the initial release should be by Q4 of this year, but you can see it evolving on the mercurial development branch and on its related task (https://savannah.gnu.org/task/?15244). The account management will be next in implementation. The GH Portal will complement or replace many activities done currently at the HMIS nodes. For instance, most of the demographic and epidemiology reporting will be done from the Portal. If you need to check the comprehensive / latest medical history of a person, you can login in directly to the GH Portal and get it from there.is there any way that the data (send from the federation queue) be set in such a way that is sent automatically without having to manually send them from the queue?Yes. For the GH HMIS nodes I see two ways: a) A periodic job from Tryton that activates the "Send" action of all the queued items. b) A cron job from the operating system, using Proteus. I like this one more because it gives full flexibility and ways to concatenate events, send alerts and link it to the logger facility at OS level.
Can you share an example of the cron job (what to execute and params)?
Can the data update from thalamus be a function of the server
and not the client? this will speed up the process and speed up
the deployment on the client side in addition of one chose to use
the web interface they would have access to this function as well.
Interactively, you can of course send all the queued job at once periodically from the client, by selecting them (CTRL+A) and clicking "Send". But I agree that the best is to have some sort of automation. Thanks again for the feedback, and hope this summary helps to have a better idea of the components and their roles. I think that the current GH Federation model balances scalability and flexibility on the HIS with integrity needed on each of the participating nodes. Any feedback / suggestions is most welcome ! Bests,
-- Bahaaldin Al-amood Managing Director IQ Tel: +964 (0) 780 926 2103 US tel: 540 632 1388 email: address@hidden Skype ID: bahaa.alamood Arc Digital Solutions and Consultancy www.arcdsc.com This message contains information that may be confidential and privileged to Arc digital Solutions and Consultancy, its partners, or customers. Unauthorized use is strictly prohibited. Unless you are the addressee (or authorized to receive mail for the addressee), you should not use, copy or disclose to anyone this message or any information contained in this message. If you have received this message in error, please so advise the sender by reply e-mail and delete this message. Thank you for your cooperation.
|[Prev in Thread]||Current Thread||[Next in Thread]|