diff --git a/adaptors/asana.md b/adaptors/asana.md new file mode 100644 index 00000000000..85700e49464 --- /dev/null +++ b/adaptors/asana.md @@ -0,0 +1,44 @@ +--- +title: Asana Adaptor +--- + +## About Asana + +[Asana](https://app.asana.com/) is a web-based project management tool that helps teams organize, plan, collaborate, and execute tasks. + +## Integration Options + +Asana supports 2 primary integration options: + +1. Rest API: Asana has an available REST API that enable external services like OpenFn to pull data from CommCare, or push data from external apps to CommCare. This option is suited for scheduled, bulk syncs or workflows that must update data in CommCare with external information. See [functions](/adaptors/packages/asana-docs) for more on how to use this adaptor to work with the API. + +2. Webhook: Asana also has a [Webhook or Data Forwarding](https://developers.asana.com/docs/webhooks-guide) to push data from Asana to external systems. This option is suited for real-time, event-based data integration. Check out the Asana [devloper documentation](/adaptors/packages/asana-docs) to learn how to set up a webhook to push data to OpenFn. + +## Authentication + +See [Asana docs](https://developers.asana.com/docs/authentication) for the latest on supported authentication methods. + +When integrating with Asana via OpenFn, there is one primary authentication method supported: **Personal Access Token (PAT)**. You can generate a personal access token from the Asana [developer console](https://developers.asana.com/docs/personal-access-token). + +See this adaptor's [Configuration docs](/adaptors/packages/asana-configuration-schema) for more on required authentication parameters. + +See platform docs on [managing credentials](/documentation/manage-projects/manage-credentials) for how to configure a credential in OpenFn. If working locally or if using a Raw JSON credential type, then your configuration will look something like this: + +``` +{ + "apiVersion": "1.0", + "token": "sample-tokenyWSJdXBACMLLWMNGgADFA" +} +``` + +### Helpful Links + +1. [API documentation](https://developers.asana.com/docs/overview) + +### Implementation Examples + +1. The Wildlife Conservation Society (WCS) - KoboToolBox -> GoogleSheets -> Asana sync: https://openfn.github.io/ConSoSci/asana/ + + + + diff --git a/adaptors/fhir-fr.md b/adaptors/fhir-fr.md new file mode 100644 index 00000000000..38ac51106d2 --- /dev/null +++ b/adaptors/fhir-fr.md @@ -0,0 +1,15 @@ +--- +title: FHIR-FR IG Adaptor +--- + +## Custom FHIR Adaptor: fhir-fr +Note❗: This is a custom adaptor generated from this France FHIR Implementation Guide: https://hl7.fr/ig/fhir/core/2.0.0/index.html + +Custom FHIR adaptors generate a suite of helper functions specific to their source Implementation Guides. + +See the generic [fhir adaptor](/adaptors/fhir) and our [docs on standards](/documentation/get-started/standards) for more general guidance on OpenFn + FHIR. + +## Build your own FHIR Adaptor +See the [Adaptors Wiki](https://github.com/OpenFn/adaptors/wiki/Generating-Fhir-Adaptors) to build your own adaptor for _your_ implementation guide by trying out our fhir-adaptor-generator (which is a new tool still in testing). + +Please share any questions or feedback on [community.openfn.org](https://community.openfn.org). \ No newline at end of file diff --git a/adaptors/fhir-ndr-et.md b/adaptors/fhir-ndr-et.md new file mode 100644 index 00000000000..2a42c6a3ab2 --- /dev/null +++ b/adaptors/fhir-ndr-et.md @@ -0,0 +1,15 @@ +--- +title: FHIR-NDR-ET IG Adaptor +--- + +## Custom FHIR Adaptor: fhir-ndr-et +Note❗: This is a custom adaptor generated from this Implementation Guide `Ethiopia FHIR Implementation Guide - HIV Treatment & Care Services` authored by Jembi Health Systems: https://build.fhir.org/ig/jembi/ethiopia-hiv/branches/master/index.html + +Custom FHIR adaptors generate a suite of helper functions specific to their source Implementation Guides. + +See the generic [fhir adaptor](/adaptors/fhir) and our [docs on standards](/documentation/get-started/standards) for more general guidance on OpenFn + FHIR. + +## Build your own FHIR Adaptor +See the [Adaptors Wiki](https://github.com/OpenFn/adaptors/wiki/Generating-Fhir-Adaptors) to build your own adaptor for _your_ implementation guide by trying out our fhir-adaptor-generator (which is a new tool still in testing). + +Please share any questions or feedback on [community.openfn.org](https://community.openfn.org). \ No newline at end of file diff --git a/adaptors/fhir.md b/adaptors/fhir.md new file mode 100644 index 00000000000..91d22834dcb --- /dev/null +++ b/adaptors/fhir.md @@ -0,0 +1,48 @@ +--- +title: FHIR Adaptor +--- + +## About FHIR + +[FHIR](https://www.hl7.org/fhir/overview.html) stands for Fast Healthcare Interoperability Resources. It is a standard for representing and exchanging healthcare data electronically. + + +:::tip About this adaptor and features coming soon! + +This adaptor is very basic and generic, used mostly to integrate demo FHIR servers. It's a work-in-progress, so share questions and feedback on [community.openfn.org](https://community.openfn.org). + +**FHIR version-specific adaptors (e.g., `fhir-r4`) with enhanced functionality are coming soon** to fast-track integration setup with more helper functions, templates, and docs than this simple adaptor. See the [Adaptors Wiki](https://github.com/OpenFn/adaptors/wiki/Generating-Fhir-Adaptors) for how to build an adaptor specific to your FHIR Implementation Guide. + +::: + +## Integration Options + +**1. Rest API:** The FHIR specification includes a REST API that enables external services like OpenFn to pull data from the FHIR server, or push data from external apps to FHIR servers. This option is suited for scheduled, bulk syncs or workflows that must update data with external information. See [functions](/adaptors/packages/fhir-docs) for more on how to use this adaptor to work with the API. + +**2. Webhook:** The FHIR specification does not inherently define a webhook or data-forwarding mechanism. However, many FHIR implementations and platforms offer extensions or configurations that support similar functionality. This option is suited for real-time, event-based data integration. Check out the FHIR `Subscription` resource [documentation](https://build.fhir.org/subscription-definitions.html) to learn more about one way this might be implemented. + +## Authentication + +The FHIR standard does not directly prescribe authentication and authorization methods. Instead, it provides security guidelines and leaves the choice of implementation to the developers of FHIR servers and clients. See the FHIR [docs](https://www.hl7.org/fhir/security.html) for the latest security-related recommendations. Depending on the FHIR systems being integrated via OpenFn, you might employ a Basic Auth, API key, or OAuth authentication scheme. + +See this adaptor's [Configuration docs](/adaptors/packages/fhir-configuration-schema) for more on the required authentication parameters. + +See platform docs on [managing credentials](/documentation/manage-projects/manage-credentials) for how to configure a credential in OpenFn. If working locally or if using a Raw JSON credential type, then your configuration will look something like this to define your target endpoint and FHIR version: + +``` +{ + "baseUrl": "https://hapi.fhir.org", //fhir endpoint + "apiPath": "baseR4" //fhir version +} +``` + +### Helpful Links + +1. [API documentation](https://www.hl7.org/fhir/http.html) +2. [Digital Square on FHIR](https://digitalsquare.org/resourcesrepository/digital-square-on-fhir-4c78p) +3. [Basic guide to interacting with FHIR Server](https://smilecdr.com/docs/fhir_standard/fhir_introduction.html) +4. [Creating your first FHIR resource](https://medblocks.com/blog/fhir-101-creating-your-first-patient-resource-like-a-pro) +5. Google's [Open Health Stack](https://developers.google.com/open-health-stack) tooling for working with FHIR + +Have resources or links to share? Submit a PR to edit this page or post on [community.openfn.org](https://community.openfn.org). + diff --git a/adaptors/http.md b/adaptors/http.md new file mode 100644 index 00000000000..295cb231281 --- /dev/null +++ b/adaptors/http.md @@ -0,0 +1,39 @@ +--- +title: HTTP Adaptor +--- + +## About the HTTP "universal" adaptor + +Communicate with web apps using [HTTP (HyperText Transfer Protocol)](https://www.cloudflare.com/learning/ddos/glossary/hypertext-transfer-protocol-http/). +This adaptor enables out-of-box integration with any REST API! + +## Integration Options + +Use this adaptor to communicate with **any REST API** or any other app that can communicate via HTTP. + +**Note that OpenFn also supports Webhooks, but that is a workflow trigger type ([see docs](/documentation/build/triggers#webhook-event-triggers)), not an adaptor.** + +## Authentication + +HTTP itself does not enforce authentication, but many applications that use HTTP implement security mechanisms to control access. Common methods that can be used when integrating with OpenFn include Basic Authentication, API Keys and OAuth. See this adaptor's [Configuration docs](/adaptors/packages/http-configuration-schema) for more on the required authentication parameters. + +See platform docs on [managing credentials](/documentation/manage-projects/manage-credentials) for how to configure a credential in OpenFn. If working locally or if using a Raw JSON credential type, then your configuration will look something like this: + +``` +{ + "username": "test@openfn.org", + "password": "@some(!)Password", + "access_token": "00QCjAl4MlV-WPX", + "baseUrl": "https://instance_name.surveycto.com" +} +``` + + +### Implementation Examples + +1. UNICEF Primero - UNHCR Progres Interoperability: [https://github.com/OpenFn/primero-progres](https://github.com/OpenFn/primero-progres) +2. UNICEF Thailand Primero Interoperability: [https://openfn.github.io/primero-thailand/](https://openfn.github.io/primero-thailand/) + + + + diff --git a/adaptors/openmrs.md b/adaptors/openmrs.md new file mode 100644 index 00000000000..98eb0f3339a --- /dev/null +++ b/adaptors/openmrs.md @@ -0,0 +1,40 @@ +--- +title: OpenMRS Adaptor +--- + +## About OpenMRS + +[OpenMRS (Open Medical Record System)](https://openmrs.org/) is an open-source platform designed to manage electronic medical records (EMRs) in low-resource environments. It provides a framework that allows developers to extend its core functionality through custom modules and APIs. + +## Integration Options + +**1. Rest API:** OpenMRS offers a REST API that enables external applications to interact with its database and perform bulk operations. This option is ideal for applications requiring scheduled or bulk synchronization with OpenMRS. Refer to the OpenMRS REST API [documentation](https://wiki.openmrs.org/) for detailed guidelines on endpoints and payload formats. + +**2. Webhook:** OpenMRS does not natively support webhooks as a standard feature. However, the platform is highly extensible and allows for customization through its module system. More details can be found on the OpenMRS [documentation page​](https://wiki.openmrs.org/). + +## Authentication + +When integrating with OpenMRS via OpenFn, **Basic Authentication** is supported. See this adaptor's [Configuration docs](/adaptors/packages/openmrs-configuration-schema) for more on the required authentication parameters. + +See platform docs on [managing credentials](documentation/manage-projects/manage-credentials) for how to configure a credential in OpenFn. If working locally or if using a Raw JSON credential type, then your configuration will look something like this: + +``` +{ + "instanceUrl": "http://openmrs.com/instance/url", + "password":"test", + "username":"test" +} +``` + +### Helpful Links + +1. [OpenMRS Developer Guide](https://openmrs.atlassian.net/wiki/spaces/docs/pages/25476048/Developer+Guide) +2. Community Forums: [OpenMRS Talk](https://talk.openmrs.org/) + +### Implementation Examples + +1. OpenFn Prototype for Médecins Sans Frontières (MSF) LIME Project - OpenMRS -> DHIS2 sync: [https://github.com/OpenFn/openfn-lime](https://github.com/OpenFn/openfn-lime) + + + + diff --git a/adaptors/primero.md b/adaptors/primero.md index a1545169db7..155ce35c995 100644 --- a/adaptors/primero.md +++ b/adaptors/primero.md @@ -63,7 +63,7 @@ See the examples section more sample Primero jobs. ### Integration tips - Data forwarding can be enabled in Primero. There is a webhook that can forward - case information to a designated URL endpoint (e.g., OpenFn Inbox). This data + case information to a designated URL endpoint (e.g., OpenFn Inbox). This feature requires a backend configuration update that the Primero support team can help with. The data forwarding can happen automatically on insert of a new case, as well as on-demand when a user clicks the `Sync` button (which may be added to the page layout if this feature is in use). diff --git a/docs/contribute/openfn-roadmap.md b/docs/contribute/openfn-roadmap.md index e2b49175d20..4bb21dbb812 100644 --- a/docs/contribute/openfn-roadmap.md +++ b/docs/contribute/openfn-roadmap.md @@ -13,7 +13,7 @@ progress [here](#what-are-we-currently-working-on). ## Our approach to product development At OpenFn, we follow the [Shape Up approach](https://basecamp.com/shapeup) to -help our small engineering team build _meaningul_ products and features faster +help our small engineering team build _meaningful_ products and features faster without compomising on quality. With Shape Up in place, we typcially commit to _projects_ that can be delivered in a 4-6 week period with multiple releases based on QA approval within the building cycle. We also proiritize feedback and @@ -46,41 +46,41 @@ immediate roadmap. ### See [**_Now_**](https://github.com/orgs/OpenFn/projects/3/views/1) 🚧 for what's been funded and is currently being built -### See [**_Next_**](https://github.com/orgs/OpenFn/projects/3/views/2) 📝 for what's being shaped and _may_ be funded in the next cycle - ### See [**_Epics_**](https://github.com/orgs/OpenFn/projects/3/views/7) 🤔 for a list of projects that we're considering, roughly-prioritized ### See [**_Bugs_**](https://github.com/orgs/OpenFn/projects/3/views/22) 🐞 for reported bugs -We will update this site periodically (ideally after each cycle, typically -lasting between 2-6 weeks) to reflect our progress on major items. You can also -keep track of all new features, changes, and bug fixes in our +We will update this site monthly to reflect our progress on major items. You can +also keep track of all new features, changes, and bug fixes in real-time via our [Changelog](https://openfn.github.io/lightning/changelog.html). ## How to **get involved** -We use [Canny](https://openfn.canny.io/feature-requests) to receive, track, -engage and manage new feature requests from the community of users of OpenFn -globally whilst giving users the ability to the upvote their favoritie and -mission critical feature request. +We collect feedback and new feature requests via our +[Community](https://community.openfn.org/c/feature-requests/) site. This allows +OpenFn core team and users to track, engage by upvoting their favorite and +mission critical feature requests. ### Upvote features 👍 -1. Go to [openfn.canny.io](https://openfn.canny.io/feature-requests) +1. Go to the community + [feature request board](https://community.openfn.org/c/feature-requests/) 2. Scroll down or use the filter and search features to see existing feature requests -3. Click on the (^) beside the request to upvote +3. Click on the (Vote) button beside the title of the request to upvote 4. If you want more upvotes for this feature request, share a link to the feature with your network ### Request a new feature 💡 -1. Go to [openfn.canny.io](https://openfn.canny.io/feature-requests) -2. Provide a very clear, concise and descriptive title for the feature (e.g., +1. Go to the community + [feature request board](https://community.openfn.org/c/feature-requests/) +2. Click on `+ New Topic` to create a new request. +3. Provide a very clear, concise and descriptive title for the feature (e.g., "Make the new workflow button green") -3. Describe the feature request in detail and why it's important to you -4. Share the feature request on the OpenFn community and across your - professional network for upvotes +4. Describe the feature request in detail and why it's important to you. Helpful + if you can add reference images and links. +5. Share the feature request on across your professional network for upvotes :::info Tip @@ -116,26 +116,27 @@ OpenFn/Lightning is the fully open-source workflow automation platform at the core of the OpenFn Digital Public Good (learn more about the product [here](/documentation#openfn-v2-lightning-)). -| **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | -| --------------------------------------------------------------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1. Enable workflow snapshotting | Delivered | Q3 '24 | [Issue 1680](https://github.com/OpenFn/lightning/issues/1680) | Keep a snapshot of a snapshot based on a run or saved changes of the workflow. Allow users to be able to view snapshot and switch to the latest version of the workflow from a snapshot mode. | -| 2. Enable configurable concurrency by workflow | Delivered | Q3 '24 | [Issue 2002](https://github.com/OpenFn/lightning/issues/2022) | Allow users to control the limit of concurrent runs per workflow in a project. | -| 3. New workflow triggers (Kafka) | Delivered | Q3 '24 | [Issue 1801](https://github.com/OpenFn/lightning/issues/1801) | Enable a new trigger type that allows users to run workflows based on messages from a Kafka cluster. | -| 4. AI-enabled assitants | Delivered | Q3 '24 | [Issue 2193](https://github.com/OpenFn/lightning/issues/2193) | LLM based AI assitant that supports users with job writing, debugging and co-piloting their workflow design process. | -| 5. Invite new users as collaborators | Delivered | Q3 '24 | [Issue 1835](https://github.com/OpenFn/lightning/issues/1835) | Invite users who do not have OpenFn accounts to projects as collaborators. | -| 6. Allow users to create projects | Delivered | Q3 '24 | [Issue 1700](https://github.com/OpenFn/Lightning/issues/1700) | All users to create new projects from their dashboard. | -| 7. Allow users to export workorder history | Delivered | Q3 '24 | [Issue 1698](https://github.com/OpenFn/lightning/issues/1698) | Allow project users to be able to export workorder history. The workorder history contains ALL logs and data clips (Input and Output) associated with runs in a workorder. | -| 8. Project datastores and buffers | Shaped | Q4 '24 | [Issue 2190](https://github.com/OpenFn/lightning/issues/2190) | Allow users to configure a data store or buffer that allows temporary of storage of data that can be used in a workflow. | -| 9. Make User Onboarding better | Shaped | Q4 '24 | [Issue 2523](https://github.com/OpenFn/Lightning/issues/2523) | Control what is printed in run logs by specifying log levels and allow users to disable printing console.logs, for data privacy once workflows are handling production data. | -| 10. Snapshots and Audit Trail | Shaped | Q4 '24 | [Issue 2526](https://github.com/OpenFn/Lightning/issues/2526) | Control what is printed in run logs by specifying log levels and allow users to disable printing console.logs, for data privacy once workflows are handling production data. | -| 11. Implement Monaco Editor | Tracked | Q4 '24 | [Issue 2126](https://github.com/OpenFn/Lightning/issues/2126) | Implement monaco editor for code editor or log viewing across the platform | -| 12. Allow users to switch between sandbox and production modes | Tracked | Q4 '24 | [Issue 2524](https://github.com/OpenFn/Lightning/issues/2524) and [Issue 2525](https://github.com/OpenFn/Lightning/issues/2525) | Allow users to be able to switch between sandbox and production modes in their projects. | -| 13. Control log outputs | Tracked | Q4 '24 | [Issue 1755](https://github.com/OpenFn/Lightning/issues/1755) | Control what is printed in run logs by specifying log levels and allow users to disable printing console.logs, for data privacy once workflows are handling production data. | -| 14. Enable manual workflow triggers | Tracked | Q1 '25 | [Issue 2155](https://github.com/OpenFn/lightning/issues/2155) | Add funtionality that allows users to manually trigger workflow with JSON/CSV data as input data clip | -| 15. Redesign workflow canvas and inspector interface | Tracked | Q1 '25 | [Issue 2021](https://github.com/OpenFn/lightning/issues/2021) | Redesign the workflow canvas and inspector interface to make workflow design better to help user build workflow faster and easier. | -| 16. Improved History page filter | Tracked | Q1 '25 | [Issue 1791](https://github.com/OpenFn/lightning/issues/1791) | Extend workorder history page and enable cascading filtering. This is useful for debuging, failure recovery and auditability of the workflow. | -| 17. Enhanced websocket worker Monitoring | Tracked | Q1 '25 | [Issue 608](https://github.com/OpenFn/kit/issues/608) | Give users better visibility of what's happening on inside the worker, especially when an error occurs during run execution. | -| 18. Expanded Audit Trail and Node Authentication (ATNA) functionality | Tracked | Q1 '25 | [Issue 271](https://github.com/OpenFn/Lightning/issues/271) | Extend audit trail functionality to cover more aspects of ATNA, reference [OpenHIE IOL requirement IOLWF-1](https://guides.ohie.org/arch-spec/openhie-component-specifications-1/openhie-interoperability-layer-iol#openhie-iol-workflow-requirements). | +| **Feature** | **Status** | **Timeline** | **Link(s)** | **Description** | +| ---------------------------------------------------- | ---------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| • Workflow snapshots | Delivered | Q3 '24 | [Issue 1680](https://github.com/OpenFn/lightning/issues/1680) | Keep a snapshot of a snapshot based on a run or saved changes of the workflow. Allow users to be able to view snapshot and switch to the latest version of the workflow from a snapshot mode. | +| • Configurable run concurrency by workflow | Delivered | Q3 '24 | [Issue 2002](https://github.com/OpenFn/lightning/issues/2002) | Allow users to control the limit of concurrent runs per workflow in a project. | +| • Kafka workflow trigger | Delivered | Q3 '24 | [Issue 1801](https://github.com/OpenFn/lightning/issues/1801) | A new workflow trigger type that creates a new workorder when a Kafka message is received . | +| • Allow users to create new projects | Delivered | Q3 '24 | [Issue 1700](https://github.com/OpenFn/lightning/issues/1700) | Allow users to create new projects from the project list page. | +| • Export work order history with logs and data clips | Delivered | Q3 '24 | [Issue 1698](https://github.com/OpenFn/lightning/issues/1698) | Allow project users to be able to export workorder history. The workorder history contains ALL logs and data clips (Input and Output) associated with runs in a workorder. | +| • Project datastores and buffers | Delivered | Q4 '24 | [Issue 2190](https://github.com/OpenFn/lightning/issues/2190) | Allow users to configure a data store or buffer that allows temporary of storage of data that can be used in a workflow. | +| • Make User Onboarding better with resources | Delivered | Q4 '24 | [Issue 2523](https://github.com/OpenFn/Lightning/issues/2523) | Control what is printed in run logs by specifying log levels and allow users to disable printing console.logs, for data privacy once workflows are handling production data. | +| • Snapshots and Audit Trail | In dev | Q4 '24 | [Issue 2526](https://github.com/OpenFn/Lightning/issues/2526) | Control what is printed in run logs by specifying log levels and allow users to disable printing console.logs, for data privacy once workflows are handling production data. | +| • Enable Save and Sync on Canvas and Inspector | In dev | Q4 '24 | [Issue 2707](https://github.com/OpenFn/lightning/issues/2707) | Make version control more accessible to user by allowing users to save and sync their changes to GitHub via the canvas and inspector. | +| • Make AI Assistant available for all users | In dev | Q4 '24 | [Issue 2613](https://github.com/OpenFn/lightning/issues/2613) | Add AI Assistant to help users build workflows faster and easier. | +| • OpenFn Workflow JSON APIs | Shaped | Q4 '24 | [Issue 2126](https://github.com/OpenFn/Lightning/issues/2126) | Expose API endpoints that allows developers to interact with OpenFn from other platforms or within jobs. e.g create a new workflow with the jobs given a JSON payload. | +| • Manual Runs for Cron jobs | Shaped | Q4 '24 | [Issue 1880](https://github.com/OpenFn/Lightning/issues/1880) | Allow users to manually run cron triggered workflows with a custom cursor and run now button. | +| • Workflow library | Tracked | Q1 '25 | [Issue 2723](https://github.com/OpenFn/lightning/issues/2723) | Create a library of common workflows that users can easily access and clone for use in their projects. | +| • Load local adaptors into lightning | Tracked | Q1 '25 | [Issue 2155](https://github.com/OpenFn/lightning/issues/2155) | Enable lightning to use local adaptors to allow developers quickly test adaptors locally without deploying to npm | +| • Allow custom inputs for manual runs | Tracked | Q1 '25 | [Issue 2155](https://github.com/OpenFn/lightning/issues/2155) | Users should be able to trigger a manual run with a custom input data. The input data can a raw JSON, CSV, I/O data clip or dataset from project collections | +| • Redesign workflow canvas and inspector interface | Tracked | Q1 '25 | [Issue 2722](https://github.com/OpenFn/lightning/issues/2722) | Redesign the canvas and inspector to make user experience and workflow building better for users. | +| • Enable sandbox and production modes | Tracked | Q1 '25 | [Issue 2524](https://github.com/OpenFn/Lightning/issues/2524) and [Issue 2525](https://github.com/OpenFn/Lightning/issues/2525) | Allow users to be able to switch between sandbox and production modes in their projects. | +| • Control log output and levels | Tracked | Q1 '25 | [Issue 1755](https://github.com/OpenFn/Lightning/issues/1755) | Control what is printed in run logs by specifying log levels and allow users to disable printing console.logs, for data privacy once workflows are handling production data. | +| • Enhanced websocket worker Monitoring | Tracked | Q1 '25 | [Issue 608](https://github.com/OpenFn/kit/issues/608) | Give users better visibility of what's happening on inside the worker, especially when an error occurs during run execution. | _You can follow Lightning's progress and track delivered features in the [Changelog](https://openfn.github.io/lightning/changelog.html)._ @@ -147,23 +148,21 @@ databases, and even raw data files, enabling interoperability with any information system ([read more](/adaptors/)). Adaptors, alongside OpenFn's workflow engine, enable automated workflows that cut across digital systems. -| **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | -| ------------------------------------------------------------------------------------------------- | ------------ | ------------------- | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1. Add "magic" functions to existing, in-demand adaptors | Delivered | Q1 2024 | [Issue 243](https://github.com/OpenFn/adaptors/issues/243) | Add functions, dynamic lists, and shortcuts to fast-track workflow configuration for key adaptors including HTTP, [DHIS2](https://dhis2.org/), [CommCare](https://www.dimagi.com/commcare/), & [OpenMRS](https://openmrs.org/) | -| 2. New [`OpenMRS`](https://openmrs.org/) adaptor version | Delivered | Q2 2024 | [See existing adaptor docs](/adaptors/packages/openmrs-readme) | To ensure compliance with OpenMRS v3 | -| 3. Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Delivered | Q3 2024 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/get-started/standards#openhie-standard-architecture) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation#openfn-v2-lightning-#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google’s [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | -| 4. Enhancements to the [`OCL`](https://openconceptlab.org/) adaptor | Tracked | Q4 2024 | [See existing adaptor docs](/adaptors/packages/ocl-readme) | To ensure that mappings stored in OCLs can be more easily access and processed as inputs in OpenFn/Lightning workflows | -| 5. Implement [MOSIP](https://mosip.io/#1) Adaptor | Tracked | Q1 2025 | [Issue 737](https://github.com/OpenFn/adaptors/issues/737) | Enable OpenFn workflows to integrate with the MOSIP platform for identity management use cases across countries. | -| 6. Implement [OpenCRVS](https://www.opencrvs.org/) Adaptor | Tracked | Q1 2025 | [Issue 736](https://github.com/OpenFn/adaptors/issues/736) | Enable OpenFn workflows to integrate with OpenCRVS for CRVS workflows.| -| 7. Implement [ArcGIS](https://www.arcgis.com/) Adaptor | Tracked | Q1 2025 | [Issue 738](https://github.com/OpenFn/adaptors/issues/738) | Enable Geospatial data management in OpenFn Workflows.| -| 8. Support Personal Access Tokens in DHIS2 | Tracked | Q1 2025 | [Issue 697](https://github.com/OpenFn/adaptors/issues/697) | Extend the DHIS2 Adaptor to support Personal Access Tokens (PAT).| +| **Feature** | **Status** | **Timeline** | **Link(s)** | **Description** | +| ------------------------------------------------------------------------------------------------ | ---------- | ------------ | ------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| • Develop an [`OpenLMIS`](https://openlims.org/) adaptor | Delivered | Q3 2024 | [Issue 533](https://github.com/OpenFn/adaptors/issues/533) | Enable users to build workflows that interface with OpenLIMS | +| • Enhancements to [`FHIR`](http://www.hl7.org/fhir/) & [`OpenHIM`](http://openhim.org/) adaptors | Delivered | Q3 2024 | See existing adaptors for [FHIR](/adaptors/packages/fhir-docs) and [OpenHIM](/adaptors/packages/openhim-docs) | To rebuild the existing 2021 [OpenFn Instant-OpenHIE reference demo](/documentation/get-started/standards#openhie-standard-architecture) to highlight the exchange of data between existing non-FHIR digital health tools and a HAPI FHIR server. (OpenFn Lightning is OpenHIE-compliant and can be used as a workflow engine for the OpenHIE Interoperability layer - [learn more here](/documentation#openfn-v2-lightning-#standards-and-compliance-matter).) We also want to demonstrate data exchange between existing non-FHIR digital health tools and key components of Google's [Open Health Stack](https://developers.google.com/open-health-stack) and [Cloud Healthcare API](https://cloud.google.com/healthcare-api/docs/concepts/fhir) | +| • Enhancements to the [`OCL`](https://openconceptlab.org/) adaptor | Tracked | Q1 2025 | [See existing adaptor docs](/adaptors/packages/ocl-readme) | To ensure that mappings stored in OCLs can be more easily access and processed as inputs in OpenFn/Lightning workflows | +| • Implement [MOSIP](https://mosip.io/#1) Adaptor | Tracked | Q1 2025 | [Issue 737](https://github.com/OpenFn/adaptors/issues/737) | Add an adaptor that enables users to integrate with MOSIP for identity management use cases across countries. | +| • Implement [OpenCRVS](https://www.opencrvs.org/) Adaptor | Tracked | Q1 2025 | [Issue 736](https://github.com/OpenFn/adaptors/issues/736) | Enable OpenFn workflows to integrate with OpenCRVS for CRVS workflows. | +| • Implement [ArcGIS](https://www.arcgis.com/) Adaptor | Tracked | Q1 2025 | [Issue 738](https://github.com/OpenFn/adaptors/issues/738) | Add an ARCGIS adaptor for users to build weorkflow that manage data sync between source and online maps with OpenFn Workflows. | +| • Support Personal Access Tokens in DHIS2 | Tracked | Q1 2025 | [Issue 697](https://github.com/OpenFn/adaptors/issues/697) | Extend the DHIS2 Adaptor to support Personal Access Token(PAT). | ### Docs Roadmap -| **Feature** | **`Status`** | **Target Timeline** | **Related Links** | **Description** | -| ----------------------------------------------------------- | ------------ | ------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1. OpenFn and the [OpenHIE](https://ohie.org/) architecture | Delivered | 2024 | [See current docs](/documentation#openfn-v2-lightning-#standards-and-compliance-matter) | New page dedicated to how OpenHIE aligns with OpenHIE architecture; expansion of the existing small section on standards | -| 2. New Lightning User Guidance | In Progress | 2024 | To be hosted on docs.openfn.org | New documentation, videos, and other user guidance on how to use OpenFn/Lightning and how to migrate existing OpenFn/platform projects to Lightning (the new OpenFn "v2") | +| **Feature** | **Status** | **Timeline** | **Link(s)** | **Description** | +| ----------------------------- | ----------- | ------------ | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| • New Lightning User Guidance | In Progress | 2025 | To be hosted on docs.openfn.org | New documentation, videos, and other user guidance on how to use OpenFn/Lightning and how to migrate existing OpenFn/platform projects to Lightning (the new OpenFn "v2") | ## Have questions, feedback or found a bug? diff --git a/docs/get-started/standards.md b/docs/get-started/standards.md index 9972963b421..bdac96dc0c0 100644 --- a/docs/get-started/standards.md +++ b/docs/get-started/standards.md @@ -147,14 +147,14 @@ OpenFn solutions are: OpenFn is used by health organizations to connect multiple FHIR- and non-FHIR compliant systems in a secure, stable, and scalable manner. OpenFn can facilitate 2 categories of FHIR workflows: -### 1. Non-FHIR to FHIR +### 1. Non-FHIR to FHIR Data Exchange -OpenFn users can configure Workflows to convert non-FHIR data to FHIR-compliant formats, and then route to FHIR systems. +OpenFn users can configure workflows to convert non-FHIR data to FHIR-compliant formats, and then route to FHIR systems. For example, get data from CommCare mobile app, convert to FHIR, and send to national health system's FHIR store. ![nonFHIR Workflow](/img/workflow_nonfhir_fhir.png) -### 2.FHIR to FHIR +### 2. FHIR to FHIR Data Exchange OpenFn users can also configure Workflows to automate the exchange and routing of _already_ FHIR-compliant data to other FHIR-compliant systems. @@ -162,6 +162,14 @@ For example, get data from OpenMRS's FHIR API, and forward to the national healt ![FHIR Workflow](/img/workflow_fhir_fhir.png) +## FHIR Adaptors +OpenFn [adaptors](/adaptors) aim to fast-track integration setup with target applications (including FHIR endpoints!). The core team is currently working on a suite of FHIR-specific adaptors to enable interoperability with FHIR systems. + +- See [existing adaptors](/adaptors/fhir) +- See [Adaptors Wiki](https://github.com/OpenFn/adaptors/wiki/Generating-Fhir-Adaptors) for how to build your own FHIR adpator specific to your target FHIR Implementation Guide + +Version-specific adaptors (fhir-r4, fhir-r5) are coming soon! + ## Other Data Standards OpenFn Workflows can automate data transformation, cleaning, and formatting rules to ensure compliance with _your_ organization's specific standards.