[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Health-dev] [task #13118] FHIR integration

From: Chris Zimmerman
Subject: [Health-dev] [task #13118] FHIR integration
Date: Wed, 11 May 2016 20:41:41 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0

Update of task #13118 (project health):

   Should be Finished on: Sun 04 Jan 2015 12:00:00 AM GMT => Sun 04 Dec 2016
12:00:00 AM GMT
                 Release:                   2.7.0 => 3.1.0                  


Follow-up Comment #5:

An update on the FHIR work.

There are two issues that I'm trying to address:

1) A better interface for the tryton data models. Since there seems
considerable interest in data from multiple sources -- devices, telemed, etc.
-- we need a better common interface for the tryton data models.

2) Deprecating our fhir library(s). We don't have the resources (or desire) to
maintain libraries against evolving standards. Furthermore, there are,
finally, good 3rd-party libraries for fhir - seems an easy choice to me.

The fhir server, currently, is mostly proof-of-concept code, rather than
actually well designed. I probably should have spent some more designing,
rather than jumping into the fhir standards, etc. Easy to see in hindsight, I
suppose. Anyways, here are the goals:

- Write adapter classes for the data models.
    - This should be a general interface to the models using fhir-like
    - I'm mostly separating code out from other classes, and updating it for
the new standard.
        e.g., fhir-like data <---> ADAPTER <---> gnuhealth.patient

- Move as much code to the 3rd party fhir library.
    - Mostly this means removing a lot of code, and writing glue code.
        e.g., 3rd party fhir library <---> GLUE CODE <---> fhir-like data
<---> adapter

The adapter classes are there as a general interface, not only for the fhir
server. For example, handling device input to update a patient's current
weight. However, currently, they don't work well separated from the fhir
server, so I need to separate out the relevant code. The glue code will be
tedious but hopefully I can adapt previous code.

Since I don't want to pollute the main repo, I'm using a github repo (for
now): Once I get reasonable stability and
function, I'll merge the new code back into the main repo, host it separately,



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]