Stream: who-smart-guidelines
Topic: android-smart-framework
Carl Leitner (Dec 20 2021 at 13:29):
for discussion on framework/library of utilities needed to implement SMART guidelines building of Google's android SDK.
Carl Leitner (Dec 20 2021 at 13:38):
@Christopher Haskew @Jing Tang here is we can have some of the async discussion as to what should be in SDK core, what goes into a collection of libraries/common utilities from SMART Guidelines implementers , and what should be in "app-land"
Christopher Haskew (Dec 20 2021 at 13:40):
Carl Leitner said:
Christopher Haskew Jing Tang here is we can have some of the async discussion as to what should be in SDK core, what goes into a collection of libraries/common utilities from SMART Guidelines implementers , and what should be in "app-land"
perfect. thanks for setting this up Carl. including @Matt Berg @Kunjan Patel
Matt Berg (Dec 20 2021 at 13:43):
Thanks @Carl Leitner ! Look forward to moving the conversations forward
Matt Berg (Dec 21 2021 at 17:36):
For transparency and for everyone's reference here is where we are doing our app development around the FHIR SDK. We are doing under a new code base called FHIR Core. The apps we building are based on the design tenants and functionalities we developed over the past 8+ years around OpenSRP.
Matt Berg (Dec 21 2021 at 17:36):
https://github.com/openSRP/fhircore/
Kunjan Patel (Dec 22 2021 at 09:41):
Thank you for creating this stream @Carl Leitner
Matt Berg (Jan 05 2022 at 13:47):
Happy new year everyone!
Matt Berg (Jan 05 2022 at 14:24):
@Kunjan Patel I think Chris mentioned you might have some questions about FHIR Core. Please free to share and we'd be happy to discuss with you those
Matt Berg (Jan 19 2022 at 01:28):
Hi @Peter Lubell-Doughtie @Vitor Pamplona going through issues and saw this is one that's both a high priority to Ona and I think WHO. https://github.com/google/android-fhir/issues/915. Wanted to see if we need to pick up back the discussion on this
Matt Berg (Jan 19 2022 at 01:28):
@Vitor Pamplona realize you may not be on the clock to support this right now but obviously welcome your inputs!
Vitor Pamplona (Jan 19 2022 at 01:34):
It should be working. They merged it days ago
Matt Berg (Jan 19 2022 at 01:34):
Ah great thank you! I'll let @Fred Hersch know so he can update the ticekt
Matt Berg (Jan 19 2022 at 01:36):
@Christopher Haskew Is it possible to share some of the rationale for reimplementing the key cloak integration vs trying to use the HAPI key cloak integration that we had developed? It would be helpful to understand some of the thinking behind the decision. I'm sure there are probably pros and cons to both approaches and I think supporting different approaches is probably fine. I think we'll probably want to at least document some of this so new implementers coming into this can make sense of what their options are.
Matt Berg (Jan 19 2022 at 01:42):
I also think it's important we try and use this forum as a chance to ask questions (if information is needed) before implementation decisions are made. Things are moving fast and I realize a lot isn't documented out yet (Google is making great progress though on the SDK docs though!). I just don't in ability to find information to be the reason to take a certain approach. I don't think this was the case for the keycloak integration but I wanted to flag in general. The more I think we all share how we are thinking about approaching the better. I hope this forum can become that.
Fred Hersch (Jan 19 2022 at 02:08):
Thanks Vitor and Matt. Are you referring to the fix for $apply or running CQF-evaluator (CQL Engine?) on Android .. Or both?
I think there were 2 issues related to CQL:
-
Support for $apply operation - I understand this is now resolved and we are working on the API implementation within the SDK
-
General CQL Evaluation support - This is the ability to run the cqf-evaluator/engine on Android (please correct me if I have this confused).. We have been discussing how to best enable this via an API within the SDK but have not made much progress here..
Overall, great to hear that the blockers have been removed and we can start to push this forward. Really appreciate all the work you have done here with JP and Bryn
cc: @Jing Tang @Bryn Rhodes @JP @Vitor Pamplona
Vitor Pamplona (Jan 19 2022 at 02:29):
Well, I am not sure if the engine is ready for the CQF evaluator, but I was able to load that library in my Android project and run with it. But my use case is quite basic (and hard coded). I am certainly expecting things to break in more advanced workflows.
Vitor Pamplona (Jan 19 2022 at 02:30):
Nevertheless, I think @Matt Berg should not wait and try to use it. And if something becomes a problem, we can start new GitHub issues with more specific use cases.
Matt Berg (Jan 19 2022 at 13:20):
Cool I was talking about the part of the issue of precompiling CQL to ELM. Not sure if that has been addressed or is still needed. I think one of the key things we'll need to do is look at performance in general as we start to see that in apps
Matt Berg (Jan 19 2022 at 13:21):
It's not related to this issue but we're seeing performance issue with data extraction when we use structure maps. So will need to ensure we are doing it right by validating others are experiencing the same and then we can work to figure out how to better optimize performance
Vitor Pamplona (Jan 19 2022 at 13:58):
oh, yes. You will need to precompile it into a Jackson file.
Matt Berg (Jan 19 2022 at 14:02):
Coolio. Q - if we wanted to have docs for this would it go into the SDK wiki? Or is this something else? If not, we may need to think about a higher level meta docs that ties all the pieces together.
JP (Jan 19 2022 at 16:49):
There's a set of profiles defined in the CPG IG for "Executable" artifacts, which basically means including precompiling the ELM. There's work being done on the publication toolchain to make generating the correct artifacts possible in the build of an IG. You could still construct such an artifact manually, but that'll at least give you some guidance as to what it should look like. We also have a few items on the cql-translator backlog to enable compiling on the fly in Android.
https://build.fhir.org/ig/HL7/cqf-recommendations/profiles.html#artifact-profiles
JP (Jan 19 2022 at 16:55):
IOW, your documentation can currently say something along the lines of "create artifacts that follow this profile" and can soon say something like "use the publication toolchain with these options to automatically generate the artifacts with the correct profile" and eventually say "CQL will run directly just fine."
Matt Berg (Jan 19 2022 at 18:23):
Cool thanks JP that's helpful. I think we need to understand bit what this means when we're creating FHIR apps using CQL that don't have an IG which will be the case I think for people interested in adopting something like the FHIR SDK but probably need to take a bit more incremental approach
Fred Hersch (Jan 21 2022 at 07:10):
I saw this posted in another thread and thought it was interesting given our discussions around Workflow and implementing a Task like interface within the SDK - https://www.dock.health/post/everything-in-healthcare-is-a-task
Fred Hersch (Jan 21 2022 at 08:10):
(deleted)
Fred Hersch (Jan 21 2022 at 08:10):
Matt Berg said:
Cool thanks JP that's helpful. I think we need to understand bit what this means when we're creating FHIR apps using CQL that don't have an IG which will be the case I think for people interested in adopting something like the FHIR SDK but probably need to take a bit more incremental approach
@Matt Berg My sense is that publishing an ImplementationGuide is an essential part of a FHIR app to clearly define the boundaries of the use case (which Questionnaires, their ValueSets, any extensions).. it could be that we need to figure out how to simplify the process for very straight forward solutions (like data collection) .. Maybe @Jose Costa Teixeira can add thoughts here?
cc: @Carl Leitner @Bryn Rhodes @Jing Tang
Jose Costa Teixeira (Jan 21 2022 at 08:22):
I don't know if this helps, but the IG contains all the specifications, in a way that tools can use it (e.g. the valuesets can be expanded, etc)
Jose Costa Teixeira (Jan 21 2022 at 08:23):
making an IG is increasingly convenient so I think it should be part of the mandatory steps.
Fred Hersch (Jan 21 2022 at 08:23):
(deleted)
Carl Leitner (Jan 21 2022 at 13:29):
Fred Hersch said:
Matt Berg said:
Cool thanks JP that's helpful. I think we need to understand bit what this means when we're creating FHIR apps using CQL that don't have an IG which will be the case I think for people interested in adopting something like the FHIR SDK but probably need to take a bit more incremental approach
Matt Berg My sense is that publishing an ImplementationGuide is an essential part of a FHIR app to clearly define the boundaries of the use case (which Questionnaires, their ValueSets, any extensions).. it could be that we need to figure out how to simplify the process for very straight forward solutions (like data collection) .. Maybe Jose Costa Teixeira can add thoughts here?
cc: Carl Leitner Bryn Rhodes Jing Tang
agreed. even if an app developer wants to do a "light modification" to an existing SMART Guidleline/IG, that adaptation should follow the IG publishing process (and possibly use SGEX tooling) so that it is clear what the app is doing. i think we can do this in a way that is not too onerous on the dev process as we start to industrialize the Questionnaire/ValueSet creation to IG publication process. we should have some more outline of this process next week (see slide deck in the https://chat.fhir.org/#narrow/stream/310477-who-smart-guidelines/topic/community-process stream)
Christopher Haskew (Jan 25 2022 at 14:32):
Matt Berg said:
Christopher Haskew Is it possible to share some of the rationale for reimplementing the key cloak integration vs trying to use the HAPI key cloak integration that we had developed? It would be helpful to understand some of the thinking behind the decision. I'm sure there are probably pros and cons to both approaches and I think supporting different approaches is probably fine. I think we'll probably want to at least document some of this so new implementers coming into this can make sense of what their options are.
thanks Matt. tagging @Kunjan Patel to give his inputs on the keycloak questions. More broadly, yes fully agree on need to share + align on requirements/specs ahead of starting new development. We're definitely building w the wider community in mind! We'll start w the next 2 priorities that we've agreed Argusoft will lead on = IG deployment + Data sync/conflict handling.
Matt Berg (Jan 25 2022 at 16:55):
Thanks Chris and would be great to hear from Kunjan on this
Matt Berg (Jan 25 2022 at 16:55):
Can you share a bit more what you mean by IG deployment and data sync / confict
Matt Berg (Jan 25 2022 at 16:56):
right now the SDK handles data sync
Matt Berg (Jan 25 2022 at 16:56):
are we talking about the rules to define what is synced?
Matt Berg (Jan 25 2022 at 16:56):
if so i think it's really important to discuss as it's linked to a lot of different things
Matt Berg (Jan 25 2022 at 16:58):
eg what resources you want to sync in your "app" which may be defined by the IG but also want patients and their resources are synced. Which may be defined by the idea of care teams and other things. This is one of those things that defines quite a bit an implementation strategy. We don't need to agree on how to do it but obviously it would probably be a huge help if we can get some alignment on it. So it's great if argusoft wants to help put in some effort to implement it but i think a discussion really needs to be hand on the approach
Kunjan Patel (Jan 28 2022 at 10:04):
Matt Berg said:
Christopher Haskew Is it possible to share some of the rationale for reimplementing the key cloak integration vs trying to use the HAPI key cloak integration that we had developed? It would be helpful to understand some of the thinking behind the decision. I'm sure there are probably pros and cons to both approaches and I think supporting different approaches is probably fine. I think we'll probably want to at least document some of this so new implementers coming into this can make sense of what their options are.
Hi @Matt Berg In EmCare we have used the Plain Hapi Server for the persistance management of the FHIR Resources. This was done in order to satisfy some other Non Functional requirements of the system for which we needed some additional attributes for our View Models of the resources. In addition to that, we also needed additional attributes for User Management models for implementing access protocols at the Role level of the Users. Also we have used the OAuth services of KeyCloak for authorisation of the system that also takes care of the Role based authentication and authorisation. Keeping the additional requirements in mind, we made a decision to go ahead with the custom implementation of KeyCloak using the Java APIs provided by them.
I agree to your point where we should derive the Pros and Cons of the approaches we take regarding using an existing library. We can create a doc that can mention the Pros and Cons of various approaches and that shall help for future implementations.
Matt Berg (Jan 28 2022 at 14:54):
Hi @Kunjan Patel thanks for sharing this it's very helpful. When your team is ready it'll be great to be able to get a demo and see how this is implemented. I'd like to understand if there is value to potentially using this approach if we can gain better row access controls. Have you started on building a front end to manage some of the administrative functions in EmCare?
Kunjan Patel (Jan 28 2022 at 15:30):
Matt Berg said:
Hi Kunjan Patel thanks for sharing this it's very helpful. When your team is ready it'll be great to be able to get a demo and see how this is implemented. I'd like to understand if there is value to potentially using this approach if we can gain better row access controls. Have you started on building a front end to manage some of the administrative functions in EmCare?
@Matt Berg We haven't started yet on the administrative part front end UI. It is being implemented right now in the backend. We have plans to create a UI for the same. Once we implement it end to end, we can have a demo.
Matt Berg (Jan 28 2022 at 16:42):
What's your proposed stack for the front end? Node / react? Do you have a list of the admin functionalities the web interface will need to cover? It would be helpful to compare against what we have implemented so far.
Matt Berg (Jan 28 2022 at 16:43):
Bit of a different questions but do you have a plan later to support web based data entry of questionnaires and extraction?
Matt Berg (Jan 28 2022 at 16:47):
Sorry last q -related to the HAPI / auth question. Is there requirements anywhere of the different access permissions you need to implement for the web. It would be helpful to understand what these requirements look like
Matt Berg (Jan 28 2022 at 16:48):
We haven't gotten feedback from any of our clients in that level of detail so it would be helpful for better understanding the use case that are needed to be supported. @Christopher Haskew is any of that shareable?
Christopher Haskew (Jan 31 2022 at 12:19):
Matt Berg said:
What's your proposed stack for the front end? Node / react? Do you have a list of the admin functionalities the web interface will need to cover? It would be helpful to compare against what we have implemented so far.
angular framework. for the admin fucntionalities, key ones we have prioritised are: user management (including auth + permissions), location management, device management, db management, questionnaire managmeent, deployment config (including internationalisation)
Christopher Haskew (Jan 31 2022 at 12:20):
Matt Berg said:
Bit of a different questions but do you have a plan later to support web based data entry of questionnaires and extraction?
no this isnt a requirement at this time. all data entry will be supported on moblie devices using the SDC library in the SDK. if we find we need larger screen sizes, we'll use e.g. chromebooks
Christopher Haskew (Jan 31 2022 at 12:21):
Matt Berg said:
Sorry last q -related to the HAPI / auth question. Is there requirements anywhere of the different access permissions you need to implement for the web. It would be helpful to understand what these requirements look like
we are taking a flexible approach to user-role-feature associations so this can be fully customised through an admin UI based on the country needs.
Matt Berg (Jan 31 2022 at 19:59):
hi @Christopher Haskew if there are any functional requirements on EmCare on roles and permissions that are shareable it would be really helpful. For context, the apps we've built to date have had pretty simple levels of permissions especially when it comes to the web app side. It would be really helpful to understand so we can be sure to factor it into our work and make sure we're not missing something obvious.
Matt Berg (Jan 31 2022 at 20:08):
re: angular - don't want to create a debate on choice of JS framework :) Just one food for thought is most of the JS libraries we have found around FHIR are in react. The questionnaire authoring tool and questionnaire rendering tool are both in react. Just some food for thought in case you ever want to integrate with those libraries the future. There may of course be a way to do it do it via angular too. It was just one of the factors we looked at (besides our teams familiarity with react). I think IHRIS and OpenMRS are using VUE for their FHIR based front ends
Christopher Haskew (Feb 01 2022 at 14:01):
Matt Berg said:
hi Christopher Haskew if there are any functional requirements on EmCare on roles and permissions that are shareable it would be really helpful. For context, the apps we've built to date have had pretty simple levels of permissions especially when it comes to the web app side. It would be really helpful to understand so we can be sure to factor it into our work and make sure we're not missing something obvious.
Hi Matt - here's the requirements doc we are building to which includes the high level description of what we need around roles + permissions. We will only be able to test against exact use cases during pilots.
Uploading 2021-007_WHO_DHI_CHED_WS4_Final_20210316.pdf…
Christopher Haskew (Feb 01 2022 at 14:03):
Matt Berg said:
re: angular - don't want to create a debate on choice of JS framework :) Just one food for thought is most of the JS libraries we have found around FHIR are in react. The questionnaire authoring tool and questionnaire rendering tool are both in react. Just some food for thought in case you ever want to integrate with those libraries the future. There may of course be a way to do it do it via angular too. It was just one of the factors we looked at (besides our teams familiarity with react). I think IHRIS and OpenMRS are using VUE for their FHIR based front ends
copied @Kunjan Patel in case he wants to reply and add anything here on the choice of angular
Matt Berg (Feb 01 2022 at 14:10):
Chris thanks very much for sharing the doc! Kunjan doesn't need to justify the angular choice. There are pros and cons to any JS framework. I just wanted to flag that a few key things we've found in the FHIR ecosystem so far are in React that's all. I think you can potentially integrate react into angular so it may not be a big deal.
Matt Berg (Feb 01 2022 at 14:16):
@Christopher Haskew apologies I think upload may not have finished.
Christopher Haskew (Feb 01 2022 at 14:22):
Matt Berg said:
Christopher Haskew apologies I think upload may not have finished.
ah yes seems to be having trouble. ill send via email
Matt Berg (Feb 02 2022 at 14:54):
@Christopher Haskew do you mind pinging through that link when you have the chance? Thanks
Matt Berg (Feb 02 2022 at 20:19):
Here's the scoping docs shared by Chris. Please refer to p16 for the for user permissions. WS4-CHED-Appendix-1-BRD_Master_Vendors_APPROVED.pdf
Matt Berg (Feb 02 2022 at 21:01):
@Christopher Haskew thanks for sharing this. The thing that's interesting is the role of the clerk. I think in a lot of implementations they don't really differentiate on roles here between the facility health worker. The list of actions are very helpful to consider.
Fred Hersch (Feb 09 2022 at 02:11):
@Alex Goel Following up from the call yesterday, can you share more about the Knowledge Repository concept and how you are thinking about Smart Guidelines IG deployment and updates (if not as part of an Implementation Guide). I believe this is something that Kunjan and team are looking into for emCare. And we are keen to understand what the SDK needs to support. Thanks
cc: @Kunjan Patel @Christopher Haskew @Jing Tang
Alex Goel (Feb 09 2022 at 13:40):
Sure Fred! It's a term I borrowed from the CDC's MEDMORPH initiative: https://build.fhir.org/ig/HL7/fhir-medmorph/usecases.html
The idea is it's a server to store usable versions of all your FHIR knowledge artifacts (i.e. PlanDefinitions, ActivityDefinitions, ValueSets, etc.)
Pulling these down from an IG directly seems inefficient to me especially when you have a client communicating with a server. Ideally you'd have 1 central repository of guidelines which could push updates to all instances of a given client that implemented a SMART Guideline. I think it's much simpler from an implementer perspective for implementation and maintenance. Currently there's no way to easily retrieve an entire SMART Guideline except by following the references in the FHIR resources. For example if you got 1 PlanDefinition for ANC and wanted to get the related ValueSets, you'd have to walk the links from the PlanDefinition to the Library, read the CQL, then to the ValueSet. If you did that for every PlanDefinition you'd be making over 200 GET requests. Having a repository with a central location to distribute the guidelines and a FHIR operation to make a single GET of all the artifacts needed to run a CPG is much easier
Carl Leitner (Feb 09 2022 at 14:21):
@Fred Hersch @Alex Goel some of the knowledge repo is incorporated here already (see slides 9 and 11 in particular)
https://docs.google.com/presentation/d/1tklkYEJAeSqvpOx8txEgEmeWRbiBm5QaQYh_qMtE7tQ/edit#slide=id.g10f5ad47de9_2_0
The MedMorph bit is US Realm, if I recall correctly, and @Bryn Rhodes and I discussed have a universal/global realm version for WHO.
Agree with Alex that we should take advantage of the server infrastructure. In particular I am worried about IG package size for minor updates on low bandwidth connections (do you want to download the whole IG just to add two concepts to a value set). Walking the dependency tree of resources is, I think, handled already by the IG Update process we would just want to ask for the updated resource against a given timestamp rather than a snapshot of all the resources (which is my understanding of the current IG Update)
Matt Berg (Feb 09 2022 at 14:25):
@Carl Leitner good point how big are IGS? Not sure if it's possible but longer term it would be sweet if we could sync diffs in resources only.
Matt Berg (Feb 09 2022 at 14:26):
At the same time I think App updates are generally a bit less common and you can usually coordinate these in the field. In many cases you have to update the whole app. So the IG may be a lot smaller then that.
Alex Goel (Feb 09 2022 at 16:39):
I think another thing that we've found is it's just inconvenient to send CPGs from a server to client right now without an operation to get it all in one go. ANC IG is about 246mb: https://build.fhir.org/ig/WorldHealthOrganization/smart-anc/downloads.html
Downloading just the artifact definitions is 10.2mb, but you don't even need all the artifact definitions every time. For server --> client I'd argue you just know the Knowledge Artifact definitions, not every profile in the IG
Carl Leitner (Feb 10 2022 at 01:58):
where is the 246m coming from?
Carl Leitner (Feb 10 2022 at 01:59):
(i guess i can look myself... just being lazy in case you knew offhand)
Bryn Rhodes (Feb 10 2022 at 15:05):
246MB is the entire IG website with all the pages, images, artifacts, test cases, everything. The artifact bundles are pretty big too, but the $package operation we're working on will be able to target executable-only, which will decrease the size of the artifact resources.
Carl Leitner (Feb 10 2022 at 15:14):
@Bryn Rhodes any chance to build deltas from previous builds for incremental updates?
Bryn Rhodes (Feb 10 2022 at 15:51):
That's not in the proposed package operation now, but could be added, like an incrementalFromVersion parameter.
Kunjan Patel (Feb 10 2022 at 19:08):
Carl Leitner said:
Fred Hersch Alex Goel some of the knowledge repo is incorporated here already (see slides 9 and 11 in particular)
https://docs.google.com/presentation/d/1tklkYEJAeSqvpOx8txEgEmeWRbiBm5QaQYh_qMtE7tQ/edit#slide=id.g10f5ad47de9_2_0
The MedMorph bit is US Realm, if I recall correctly, and Bryn Rhodes and I discussed have a universal/global realm version for WHO.Agree with Alex that we should take advantage of the server infrastructure. In particular I am worried about IG package size for minor updates on low bandwidth connections (do you want to download the whole IG just to add two concepts to a value set). Walking the dependency tree of resources is, I think, handled already by the IG Update process we would just want to ask for the updated resource against a given timestamp rather than a snapshot of all the resources (which is my understanding of the current IG Update)
Extending to what @Carl Leitner mentioned about the example of syncing just the value sets, we are also looking at provisioning the L4 implementers a feature to be able to do minor changes to the Questionnaires of the IG. This is to be done for adding country specific flavours/context where some questions or data points being collected might not be relevent. In case we go ahead with it, there can be one more versioning of the IG at the L4 level as well. I am not sure if its the correct way of doing it. Or rather the L4 app should ever have a feature to tweak with the imported IG. Would like to know views of the community over this.
@Fred Hersch @Carl Leitner @Matt Berg @Alex Goel @Bryn Rhodes
Alex Goel (Feb 10 2022 at 19:40):
I think the solution is to have each individual resource hosted by a repository and then minor updates can be pushed just to those select resources, like in the Questionnaire example Kunjan brings up. For example if ANC updated 1 questionnaire it doesn't make sense to pull the full IG. Having all the knowledge artifacts and profiles available in a server using a FHIR API makes a lot of sense, and then having a package operation to get all the knowledge artifacts when necessary would solve the packaging problem
Alex Goel (Feb 10 2022 at 19:41):
We could create a separate "CPG Update" operation that checked which Knowledge artifacts had been changed and then update only those. @Bryn Rhodes would that work?
Bryn Rhodes (Feb 10 2022 at 21:57):
We could automate updating the uncustomized artifacts, but we could only provide some information about customized artifacts that needed to be updated based on changes upstream (and then only if the customized artifacts were careful to declare what they were customizations of).
Kashyap Jois (Mar 02 2022 at 12:13):
@Matt Berg Hi, we have just started working on implementing the WHO smart guidelines. We are going with a docker approach and I would like to use the keycloak integration that you guys have done with openSRP. I see that It has 3 java files, one to disable the default security adapter, one to define the keycloak adapter and im not sure what the third one does.
We are currently using https://github.com/hapifhir/hapi-fhir-jpaserver-starter docker image and
https://github.com/Alvearie/keycloak-extensions-for-fhir . So Im guessing I need to copy these three files into the source code of the hapi-fhir-jpaserver-starter and rebuild the docker image? Also are you using the keycloak extensions? Looks like it allows defining scopes based on resource types. Thanks!
cc: @Akhil Kumar @Nitin Sabale @Deepak Anjana
Matt Berg (Mar 02 2022 at 12:28):
Hi @Kashyap Jois thanks for reaching out. Copying in @Benjamin Mwalimu and @Francis Otieno and our side to help with this.
Matt Berg (Mar 02 2022 at 12:30):
Also - let us know if you want to jump on a call to better understand what you want to do and see if we can potentially collaborate on a broader level.
Kashyap Jois (Mar 02 2022 at 12:41):
Thanks for the quick reply! I can probably clear this out in our android dev call tomorrow if we have time.
Benjamin Mwalimu (Mar 02 2022 at 13:05):
@Kashyap Jois We fork the https://github.com/opensrp/hapi-fhir-jpaserver-starter project then added the keycloak extension as a dependency.
<dependency>
<groupId>org.smartregister</groupId>
<artifactId>hapi-fhir-keycloak</artifactId>
<version>0.0.7-SNAPSHOT</version>
</dependency>
You then need to add the following values to the application.yaml file
keycloak:
auth-server-url: <server-base-url>
realm: <keycloak-realm-name>
resource: <client-name>
credentials:
secret: <client-secret>
ssl-required: external
You will then need to rebuild the docker image and re-deploy your instance
Kashyap Jois (Mar 02 2022 at 13:22):
Thanks Benjamin! Thats super helpful. We will try it out and let you know If it works.
Cc: @Sarvesh Makthal @Madhav Shanbhag
Matt Berg (Mar 02 2022 at 13:24):
Jois - if we could connect a bit more at the strategic level too it would be great. It would be helpful to understand your broader goals and we can share what we're doing to. There might be some broader things that we are working on that may be helpful and vice-versa. Let me know if you have a bit of time where we can jump on a call. Thanks!
Kashyap Jois (Mar 03 2022 at 06:58):
Matt Berg said:
Jois - if we could connect a bit more at the strategic level too it would be great. It would be helpful to understand your broader goals and we can share what we're doing to. There might be some broader things that we are working on that may be helpful and vice-versa. Let me know if you have a bit of time where we can jump on a call. Thanks!
Sure Matt, I will bring this up with the rest of the team and get back to you.
Matt Berg (Mar 06 2022 at 19:18):
Sounds great thanks @Kashyap Jois
Matt Berg (Apr 11 2022 at 16:36):
hi @Kashyap Jois your team demoed a great feature on reviewing questionnaire summaries. Is that part of the SDK or is that in your app code? If so, is that something you can share?
Matt Berg (Apr 11 2022 at 16:36):
And if in the SDK is that part of SDC? can you point us toward it? Thanks!
Kashyap Jois (Apr 11 2022 at 16:47):
Hi @Matt Berg , yes its part of the SDK. There is a partial working version . We have to still incorporate the feedback given by @Jing Tang . Apologies that it has taken so much time to conclude. We will be working on it soon. Here is the link to the PR https://github.com/google/android-fhir/pull/1094
Benjamin Mwalimu (Apr 12 2022 at 13:28):
@Kashyap Jois Are you open to collaborating on this feature so that we maybe merge it faster?
Kashyap Jois (Apr 12 2022 at 13:33):
Sure @Benjamin Mwalimu We are open to collaborating on this feature! we can get on a call to discuss this if needed.
Benjamin Mwalimu (Apr 12 2022 at 13:38):
@Kashyap Jois Let me set up a call for this. How is 13th 1:30PM GMT for 30mins?
Kashyap Jois (Apr 12 2022 at 13:44):
Ill just PM you so we can setup a time
Last updated: Apr 12 2022 at 19:14 UTC
