- Data Access API - Set of APIs for performing CRUD operations on FHIR resources in the SQLite DB
- Search API - On-device fluent search API allows application to compose complex search queries to filter FHIR resources and build lists
- Smart Guidelines/ Protocols API(?) - Building blocks for deploying implementation guides (IGs) including Smart Guidelines
- Data Capture API - SDC specification implementation- The structure data capture library will render Android UI from FHIR questionnaire resources.
- Sync API - Provides sync capabilities between a FHIR server and the local DB
- CQL API - Provide support for operations and execution of CQL logic
- Utilities - Can be used to generate widget functionality for the app
- Common use case for a CHW app. Incorporates MVP elements from the SDK
- MVP server side components for reference application (Ona to own)
- specifically for rendering a FHIR Questionnaire
- currently displaying a list view with FHIR patient resources
- Patient registration
- Patient search
- Patient profile view
- Offline Sync support
- Multilingual support
- Vaccination registration
- Vaccination certificate support G6PD specific features
- Image processing engine (IPE)
- Results interpretation module (RIM)
We plan to structure FHIR resources as shown in the below diagram:
- Execute CQL logic
- Generate CarePlan
- Sync data with FHIR server
- Search
- Validate
- Interact with CarePlans and Activities
TBC
- Main unit of the business logic. Inside you will find the triggers . Give us the care plans and the resource group.
- A definition canonical reps the activity definition to recommended supplements/medication in this use case NB. Inside the Activity definition we shall define what we need to create based on the plan definition. Logic will come from the CQL which will be running additional queries.
- Inside actions , we get the triggers and conditions that reference the CQL expressions in the ANC CQL lib.
- The library filed will specify which CQl lib will be used and can reference multiple libraries
- Jurisdiction identifies where the plan is valid
- There is a goal for each plan definition and its id is unique - Goals may address the prevention of illness, cure or mitigation of a condition, prolongation of life, or mitigation of pain and discomfort.
- Create a Plan
- Has a set of Actions (Activities)
- Contains a list of sub-actions (what is to be done)
- Has a set of Actions (Activities)
- Generating actions can be implemented via
- Inline actions (No activity definition attached) or directly using Activity definitions
- Action can be implemented as a:
- Code
- Link to questionnaire
- Property to get an action
- An ApplyOperation on a plan will generate a care plan -> Set of activities on an individual
- We can have a group of resources to attach to a household
- Logic can be embedded in the plan definition
- CarePlan will be against the house (head of household) or patient (target context)
- Create a task beforehand
- Daisy-chaining - using Dynamic values - dynamic calculation of values
- Treatment - if conduction is +positive within 3 months
- Path (Status) - > Resource or task
- Expression (Active)
- Treatment - if conduction is +positive within 3 months
- Create a Plan definition
- Define a Plan selector
- Sync to phone
- Run evaluation after a questionnaire response is submitted or periodic trigger based on a schedule
Getting started with CQL
Task generation on CQF-Ruler as alternative of extending plan evaluator
- How will CQL be used to invoke these operations
- Which CQL lib, CQF ruler, in-app vs server-side?