We propose to enhance the Open Concept Lab (OCL) suite of tools to serve as an authoritative, FHIR-compliant source for codes, value sets, disaggregates, and other metadata required to support the FHIR/mADX approach to aggregate data exchange. OCL is actively supporting a proof of concept for aggregate data exchange using the TX_PVLS indicator and would use this award to build out FHIR terminology services functionality, publish all metadata needed by the point of service, health information exchange and data warehouse layers, and to develop a thin-client web interface for browsing and searching this metadata.
This award would be used for the following: 1. Build a FHIR terminology services layer onto the existing OCL terminology server, specifically the FHIR CodeSystem and ValueSet resources. * OCL would provide FHIR-based code/code system lookups, validations, and value set expansions that would be used by the CQL execution engine in the HIE layer. * Optionally, OCL would provide point of service systems, such as OpenMRS, with access to the metadata needed to capture data in a format compatible with the aggregate data exchange process and to prepare FHIR messages. * Along with a FHIR Measure, OCL would have all the metadata required to set up a data warehouse or aggregate reporting system, such as DHIS2, to store the results of a FHIR Measure Report. 2. Model and publish definitions for all codes, value sets, disaggregates, and other metadata required to support the aggregate data exchange process. * The model to represent these definitions in OCL was already implemented for the TX_PVLS proof of concept with PEPFAR. * Optionally, store links to FHIR Measure resources in the definitions of the corresponding measures published in OCL, so that client systems may easily access the full package of metadata needed to evaluate a measure regardless of which service they access first. 3. Enhance the OCL Metadata Browser Prototype to support intuitive browsing, searching and downloading of all metadata published to OCL as part of this project and easy access to view or download the associated FHIR resources. * The OCL Metadata Browser (currently in development) is designed to be the primary method for browsing, searching, and visualizing metadata published in OCL. It is an open-source, ReactJS tool that can be used in the cloud or customized for a local implementation. It would be enhanced for this project to provide intuitive, hierarchical navigation of indicator metadata. 4. Demonstrate OCL terminology service facilitating the aggregate data exchange workflow with a selected point of service system. * We will be able to demonstrate the full workflow with a selected point of service system assuming that compatible HIE and Data Warehouse components are available. Additional information to be added soon.
Open Concept Lab Regenstrief Institute Apelon
Ethiopia PEPFAR global implementation CIEL interface terminology publication
Comments
It's interesting to see the
It's interesting to see the adaption and extension to have FHIR interfaces exposed here. How do you see this working as per ftp://ftp.ihe.net/Quality/2019_2020_YR_13/QRPH%20Technical/Whitepapers/ (from notice). Will be interested in seeing any discussions of how the system is envisaged to play out in the overall solution architecture. Please elaborate the narrative of how the solution will function as per the use-cases.
Is there interface opportunities with this proposal (https://applications.digitalsquare.io/content/integrated-hie-approach-patient-level-indicator-reporting)?
Thanks Carl. Very interested
Thanks Carl. Very interested in the apprach that Jembi proposed as well and let me see if I can provide a brief explanation here. A FHIR-enabled OCL would provide a level of support for all 3 scenarios (standalone, paired, integrated) and for all 3 levels of systems (POS, HIE, and HMIS/DW), and we'll elaborate on these in the concept note. At the most basic level, OCL would serve as a reference for implementers and developers of the codes, value sets and indicator metadata involved in a transaction. This could be, for example, OpenIMIS building its data model against this metadata. A step up from there would be OpenMRS using the OCL Subscription Module to actually subscribe to the required codes (as specified in the minimum data set message (MDSM)), pulling them into its local concept dictionary. A third model would be using OCL to map a local data model to the MDSM, enabling automated metadata transformation, which could be used to perform ETL on the local data to get it into the required format. Within the HIE, where the FHIR measure is actually evaluated, OCL would provide structured indicator metadata, which could be used by a CQL execution engine, for example, to lookup and validate the codes from the relevant value sets for the indicator being evaluated. In the PEPFER TX_PVLS proof of concept, OCL exposes the indicator reference definition, the data element definitions, and the disags (category/category options in DHIS2) along with the expressions used to filter data from the POS for each disag (e.g. the expression for the age band, gender, etc.). Hope this all helps!
Interesting -- this project
Interesting -- this project plus the FHIR-SmileCDR one could be "available" artifacts in our Policy and Artifact Generator Tool -- (see my question on semantics at the FHIR-SmileCDR comments section) --
Hi Alvin- Is there a FHIR
Hi Alvin- Is there a FHIR SmileCDR concept? I don't see it in the list of applications but maybe I'm missing something! Is the Policy and Artifact generator tool a service of AeHIN? Could you provide a link? Thank you!
What's up it's me, I am also
FYI in the spirit of
FYI in the spirit of collaboration, we have joined forces with Jembi, OpenMRS and Bluesquare on the concept note "Towards an Integrated HIE Approach to Patient-Level Indicator Reporting" (https://applications.digitalsquare.io/content/towards-integrated-hie-approach-patient-level-indicator-reporting)
This means that we are no longer moving forward with this independent concept note. Thanks!