Introducing Quest: FHIR Native Case Management
HL7 FHIR provides a standardized and popular way for digital health systems to represent health data and associated processes. We are excited to introduce Quest, an open source app that lets you use FHIR to define forms and capture data to take advantage of the growing Android FHIR and WHO SMART guidelines ecosystem.
Improving Automated Testing, Interoperability, and Privacy of OpenSRP
Through a committed collective of technology, research, and implementation partners, OpenSRP has matured into a fully-fledged digital health platform with multiple national deployments, high performing technology at scale, and emerging documentation around use cases for RMNCH, TB, HIV, malaria and early childhood development.
Clinical Decision Support and Measure Reporting in FHIR
Through clinical decision support (CDS) and measure reporting, FHIR gives us powerful tools to encode algorithms for healthcare workflows and define metrics that track patient care. The HL7 standards of Clinical Quality Language (CQL) and FHIRPath expressions let us express both our CDS and measures in a portable way.
Google Summer of Code 2021
Ona and Google have been collaborating to bring to life code and API-driven healthcare guidelines based on the FHIR (Fast Health Interoperability Resources) standard.
Google Summer of Code 2021: Healthcare Apps on FHIR
We are underway in the Google Summer of Code 2021, in partnership with Google to build the Android FHIR SDK powering next-generation offline-capable, mobile-first healthcare apps using Fast Healthcare Interoperability Resources (commonly referred to as FHIR and pronounced ‘Fire’).
Introducing OpenSRP FHIR Core - Why we are going all in on FHIR
When I first heard of HL7 FHIR (Fast Healthcare Interoperability Resource), I think, like most, l understood its application as a data exchange standard with promises of facilitating interoperability.
Developing Android libraries that are easy to use - Part 3: How to do it technically
This is Part 3 of the series Developing Android libraries that are easy to use. You might want to start by reading Part 1 and Part 2. With this post, I am going to get to the point and state dos and don’ts on how to actually write the source code. 1. Changes in public APIs The APIs available
Developing Android libraries that are easy to use - Part 2: Common mistakes to avoid
This is Part 2 of the series Developing Android libraries that are easy to use. You might want to start by reading Part 1. This post is basically the inverse of the previous post. Here we discuss what not to do / what to avoid. 1. Documentation location The following are the don’ts for documentation location: Don’t
Developing Android libraries that are easy to use - Part 1: Make the library conventional
We more often than not re-use code when developing software. For code to be reused when working in Java, we can package it into classes, packages, modules (read gradle-modules), or an artifact. In Java, we call these artifacts JARs while in Android they become a bit more complicated and independent to become AARs. AARs contain drawables, strings, layouts, values, assets and even the AndroidManifest.xml. However, to truly re-use the code
Setting Up a Multi-Container Development Environment with Docker
In this post we will set up a development environment for an application that will be using multiple Docker containers.