This post is meant to serve as an overview and concept note for the OpenMRS Facility Registry project. Any and all questions, suggestions, or concerns are welcome!
Enable OpenMRS to upload and synchronize the implementation-specific Location hierarchy with a centralized Facility Registry.
(See the Facility Registry Workflow Epic for related issues)
- How would external facility lists be used within current OpenMRS Workflows?
- Would OpenMRS be solely a consumer of Facility Registry data, or would there be a need to upload data as well?
- Does the scope of the mCSD profile align with the OpenMRS approach to locations, referrals, and healthcare service information?
2. Explore the mappings between the mCSD Data Model and the OpenMRS
Draft Mapping Spreadsheet: mCSD -OpenMRS FHIR Mappings - Google Sheets
3. Document the proposed OpenMRS FHIR Module support for mCSD-related resources in the FHIR2 Module Implementation Guide.
Any relevant information obtained from the FR can be stored as tagged
Locations in the OpenMRS data model. We can leverage custom attributes to add required data that does not currently have dedicated support in the OpenMRS
6. Determine the utility of being able to synchronize the OpenMRS Location hierarchy with a centralized representation.
Similar to communication with a Client Registry or Terminology Service.
The FHIR2 Module should support:
- Creating and updating a local representation of a FR dataset as an independent
- Translating the OpenMRS Location hierarchy into a FR-compatible form for upload into a GoFR partition
8. Develop an IG-based testing framework for validating OpenMRS support for the mCSD profile and the related FR workflows.
- Overview of FHIR Implementation Guides: HL7.FHIR.UV.HOWTO\IG Home Page - FHIR v4.0.1
- Official FHIR IG Documentation: ImplementationGuide - FHIR v4.0.1
- Way of Working Artifact Metamodel: HL7.BE.FHIR.WOW\Home Page - FHIR v4.0.1
- OpenHIE Testing Concept Note
- Testing (against) FHIR Specifications
- drop down population in UI
- transfer in/outs
- source of required information - Facility ID (national identifier not internal), Name, Address/Location, Active/Not-active, Services Offered, Facility Type
- To what extent does the scope of our work overlap with the efforts to provide referral functionality in OpenMRS? (See Referrals in OpenMRS for more context)
- How should we architect the communication and use of centralized HIE components such as a Facility Registry, Client Registry, or Terminology Service by OpenMRS in general?
- Should data from these sources be integrated with the OpenMRS data model?
- Should OpenMRS strictly act as a consumer of these resources?
- In what cases does instance-specific data need to be uploaded from OpenMRS to such a service?