I work in Tanzania and have been participating in some task teams and TWGs here looking at interoperability.
I would like to learn more about how OpenHIE applies to different types of use cases. For example the use case that seems to be most commonly discussed is EMRs sharing data with each other and/or with a shared health record, but there are also many other types of interoperability use cases in the health sector. I am still trying to understand how OpenHIE applies to other use cases, and in particular, what advantages there are to using mediators/interoperability layers in each of these other use cases.
I have written below an extract from a brainstorm about interoperability use cases in Tanzania. I would be very interested in learning more about mediators in particular and how mediators could make interoperability easier (or more difficult) in each use case.
My background is as a field implementer, connecting point of service applications. I feel that the teams at Mohawk and Jembi would also have an informed opinion on supporting more use cases within health systems.
The list in your message covers a broad range of activities with many nuances. As I look across the list, I see a few commonalities. The first is the difference between moving individual patient records vs. aggregate data. From my perspective, OpenHIE is under rapid development to support many of the use cases in the patient/provider space that you mention. Saving patient data appears on the v2.0 Workflows on the roadmap and is under development. Support for the movement of aggregate data between the point of service system and OpenHIE is in the testing phase and is scheduled to be deployed this fall.
With that said, there’s a general assumption that any health data can move once these features are deployed. The features are written so that the specific data points and indicators are configurable, often through the user interface. If we consider the movement of aggregate data, a number of the use cases in your list involve moving supply chain, commodity, population demographics, program indicators etc. Assuming that DHIS2 is the HMIS, one can create the programs and data sets through the DHIS2 user interface and connect to it using the ADX standard. As long as your system can handle the ADX standard, it can exchange aggregate data with OpenHIE once v 1.5 is released.
Some of these use cases may not add value to the HIE. Each data element in the HIE needs to be considered to see how it adds value to different parties who interact with the HIE.For example, a lab result that supports a particular diagnosis may not need to get pushed to the shared health record. Instead of pushing the lab result, the shared health record may store the diagnosis, date, and provider that made the diagnosis. In these cases, a point-to-point connection between point of service systems may be appropriate. These point to point connections are accomplished in many ways. One open source example is how OpenMRS connects to OpenELIS, OpenERP and a billing system in the Bahmni implementation. These systems connect through Application Programming Interfaces (APIs) to support the desired workflows and only bubble up the appropriate aggregate data that’s needed to support population based workflows.
Finally, we need to consider who owns the HIE. It makes sense in my mind for an organization to own their own HIE or a subset of HIE components to support their populations and share the appropriate information with a “public” HIE that can be consumed by other organizations. It would be interesting to see how other implementers have approached this and whether a community owned HIE implementation can support the specific operational needs of each community member.
Sincerely,
Craig
···
On Monday, June 27, 2016 at 8:02:19 AM UTC-7, Elaine Baker wrote:
Hello everyone
I work in Tanzania and have been participating in some task teams and TWGs here looking at interoperability.
I would like to learn more about how OpenHIE applies to different types of use cases. For example the use case that seems to be most commonly discussed is EMRs sharing data with each other and/or with a shared health record, but there are also many other types of interoperability use cases in the health sector. I am still trying to understand how OpenHIE applies to other use cases, and in particular, what advantages there are to using mediators/interoperability layers in each of these other use cases.
I have written below an extract from a brainstorm about interoperability use cases in Tanzania. I would be very interested in learning more about mediators in particular and how mediators could make interoperability easier (or more difficult) in each use case.
Thanks!
Best wishes
Elaine
Health records, service
delivery and payments data
EMR/mHealth app/facility admin system to share
health records with each other for referrals / continuity of care
EMR/mHealth app/facility admin system to share
health records (to back up claim), service delivery data and claim amounts into
insurance claims systems
EMR/mHealth app/facility admin system can send
an “order” (prescription, diagnostics order) to another EMR/mHealth
app/facility admin system or to a dedicated pharmacy or laboratory system
Laboratory system can send a “result” (test
result, image etc) to an EMR/mHealth app/facility admin system
Laboratory system can send a “result” (test
result, image etc) to a patient/client directly
EMR/mHealth app/facility admin system can send
health records data into IEC system to enable more customized IEC messages
Supply chain data
(data on availability of commodities, ordering of commodities and delivery of
commodities)
Facility admin systems can send orders, drug
availability data and delivery confirmation data into supply chain systems
Supply chain systems can exchange data among
themselves (eLMIS, MSD Epicor, ILS Gateway etc)
Data for cross-system
analysis
Some data go into DHIS first and from there to data
warehouse ?
EMR/mHealth app/facility admin system send
aggregated facility data into DHIS
Pharmacy council system send data from ADDOs (dispensing outlets) into DHIS
Some data go first into OpenLDR lab data repository and from
there to data warehouse
Lab systems send data to OpenLDR (lab data repository)
OpenLDR send data into DHIS
Data going into data
warehouse
DHIS sends data into data warehouse
OpenLDR sends data into data warehouse
EMR/mHealth app/facility admin system send
de-identified patient level data into data warehouse for statistical analysis
Facility admin system send aggregated payments
and insurance data into data warehouse
Insurers send aggregated insurance enrollment
and claims data into data warehouse
Assessment and performance management systems
send facility data into data warehouse
PlanRep (district planning and budgeting software) and Epicor (Government accountancy software) send planning and expenditure
data into data warehouse
Human resource and training systems send aggregated
data into data warehouse
Supply chain systems send aggregated data into
data warehouse
Data warehouse or DHIS send data out to other systems to
help in decision making and planning
DHIS sends data (eg burden of disease data) into PlanRep (budgeting tool) - (to inform planning)
Data warehouse sends data into WISN (HR planning tool) for HR
planning