Stream: OpenHIE
Topic: client-registry
Carl Leitner (Feb 12 2021 at 12:47):
for discussions around OpenCR and SanteMPI...
Carl Leitner (Feb 12 2021 at 12:48):
hey @Joseph Dal Molin and @Ryan Crichton
Carl Leitner (Feb 12 2021 at 14:53):
adding in @Luke Duncan and @Ally Shaban as well.
Matthew Dickie (Feb 18 2021 at 07:48):
Hi all, Jembi Matt here.
I have a Sub-topic question on OpenCR as part of the Instant OpenHIE Client package.
Does OpenCR require its own independent instance of HAPI-FHIR with Instant OpenHIE or could it be configured to use the HAPI-FHIR instance created by the Core package? (i.e. Do we need the FHIR server duplication?)
Currently, the two HAPI-FHIR instances conflict if you try to start up the Core and Client packages at the same time.
Client HAPI-FHIR instance: https://github.com/openhie/instant/blob/master/client/docker/docker-compose.yml#L20-L24
Core HAPI-FHIR instance: https://github.com/openhie/instant/blob/master/core/docker/docker-compose.yml#L26-L36
Side note: Jembi is currently updating the Core package Instant HAPI-FHIR instance to 5.2.0
Ryan Crichton (Feb 18 2021 at 08:58):
@Richard Stanley maybe you could help us understand this?
Richard Stanley (Feb 18 2021 at 09:01):
Great question. It can use the HAPI in the core package.
Matthew Dickie (Feb 18 2021 at 09:21):
Richard Stanley said:
Great question. It can use the HAPI in the core package.
Hi @Richard Stanley - I'm trying to test this now and there's an issue with the OpenCR Docker image having a hard-coded reference to a specific HAPI-FHIR URL - https://github.com/intrahealth/client-registry/blob/master/docker/opencr/Dockerfile#L24
I'll try to make this url configurable and open a PR if it works :grinning:
Richard Stanley (Feb 18 2021 at 14:10):
Indeed. Yeah, OpenCR doesn't like if HAPI isn't ready and usually the HAPI container takes a couple of minutes to be ready. So, I used Dockerize to ensure the service is available. This isn't really needed in K8s because of init containers. I'll have a look at it today.
Richard Stanley (Feb 18 2021 at 23:36):
@Matthew Dickie So, OpenCR requires a hard-coded config file. This is also true for decision rules for matching. So, the Docker quick start doesn't use the Dockerized OpenCR (https://intrahealth.github.io/client-registry/admin/docker/), it asks the user to run OpenCR (not HAPI or ES) straight from the command line because they'll need to customize it in any case to match anything. What I was thinking when I wrote the Dockerization was that it's really for demos or CI/CD pipelines. I'm waiting for the devs to tell me me if there are env vars to do it but I don't think there are for now.
Richard Stanley (Feb 18 2021 at 23:37):
I can commit a config file just for K8s/Instant that would fulfill whatever is needed in the meantime and publish an image. Just please give me an idea of what is needed. Right now the K8s service is named fhir and the service name and ports can be remapped to whatever OpenHIM requires.
Carl Leitner (Feb 19 2021 at 12:51):
I imagine that for some deployments it would be useful to have two instances of a fhir server/HAPI. How comparison is it to have fhir-cr as the named K8s service that OpenCR references and then allow for a configuration option that allows fhir-cr to point/route to the core fhir K8s service. In other words have open CR know nothing about fhir and only references fhir-cr internally and then let the user decide if fhir-cr and fhir are one and the same. This could be useful for data segmentation and/or performance optimization reasons.
Matthew Dickie (Feb 25 2021 at 13:14):
Richard Stanley said:
I can commit a config file just for K8s/Instant that would fulfill whatever is needed in the meantime and publish an image. Just please give me an idea of what is needed. Right now the K8s service is named
fhirand the service name and ports can be remapped to whatever OpenHIM requires.
Hi Richard, I submitted a PR with a small change to the Dockerfile - it just adds an Env Var for the HAPI-FHIR heartbeat check. But I kept the previous value as a default to make it backward compatible.
https://github.com/intrahealth/client-registry/pull/43
I also added some documentation to that Docker section you mentioned. I added an example of voluming in a new configuration file to replace the default image config on startup. Using the docker volume caters for the config needs so far :grinning_face_with_smiling_eyes:
I'll add you as the reviewer for my Instant changes.
Matthew Dickie (Feb 25 2021 at 13:29):
@Carl Leitner - our concern about running two separate HAPI-FHIR servers is that these are quite resource-intense services. Since we're already upgrading to v5.2.x we plan to use HAPI's Resource Partitioning feature.
We think this may be a more efficient way of fulfilling any data segmentation needs - though perhaps our tune will change when we've actually implemented the partitioning.
On performance optimization, I'm not sure - perhaps having one better spec'd HAPI-FHIR instance will perform better in the long run compared to two HAPI-FHIR instances sharing those resources? Thoughts @Ryan Crichton
With regards to OpenCR not knowing about FHIR, I'm quite sure what you mean? But in the PR I mentioned earlier that should make the OpenCR very agnostic about the HAPI-FHIR instance. The user will now have full config control there.
Carl Leitner (Feb 25 2021 at 14:04):
OK, partitioning looks promising. Do you know if these partitions are strict (e.g. a resource can only exist in one partition) or does it allow overlaps?
Carl Leitner (Feb 25 2021 at 14:07):
performance optimization consideration was thinking that would want to be able to support multiple scaling options in a cost efficient manner. for example, through more compute resources on an instance of HAPI that is making use of the CQL engine or being hit hard for search queries.. that said I haven't really though through this or looked at the threading capabilities with HAPI+CQL.
Richard Stanley (Feb 25 2021 at 14:46):
Most resources can be partitioned. However, code systems, questionnaires, and similar are actually shared. But, most can be partitioned.
Richard Stanley (Feb 25 2021 at 15:11):
See Non-Partitionable in: https://hapifhir.io/hapi-fhir/docs/server_jpa_partitioning/partitioning.html
Carl Leitner (Feb 25 2021 at 15:33):
As I RTFM, I see "In a partitioned repository, it is important to understand that only a single pool of resource IDs exists. In other words, only one resource with the ID Patient/1 can exist across all partitions, and it must be in a single partition." which means that there is no overlap.
Matthew Dickie (Mar 03 2021 at 11:58):
@Richard Stanley I've opened another small PR to OpenCR.
It would be useful in Instant OpenHIE to use environment variables to make small config changes to OpenCR - instead of voluming in entire files.
OpenCR already accepts some environment variables but the colon syntax for accessing the nested config fields (like the OpenHIM API details) does not play well with Docker.
Since OpenCR uses nconf already, the change was very minor . nconf allows defining a new separator for accessing nested config. The suggested separator is __ according to the documentation and examples.
I also added some documentation along with the change :grinning:
Richard Stanley (Mar 03 2021 at 18:01):
@Matthew Dickie Looks great, let me review with the devs
Richard Stanley (Mar 04 2021 at 15:58):
Reviewed and merged. Thanks again.
Last updated: Apr 12 2022 at 19:14 UTC
