/
2009 Implementers Group Meeting Program OpenMRS and National Reporting

2009 Implementers Group Meeting Program OpenMRS and National Reporting

Aug 18, 2010

OpenMRS and National Reporting

Issues for discussion:

  • Centralised data warehouse with anonymized patient data

  • Data validation and auditing

  • How to engage the ministry? (to be discussed in later session)

  • Harmonizing reporting systems

  • Data ownership/access

  • Importance of local data collection and use/ feedback down to the local level

  • National accountability to citizens

  • Lots of levels of information use; many needs up to the national level - need to interact with local and regional decisionmakers

  • Reporting definitions

Centralised Data warehouse

  • Could be:

o One central place where data can be stored; a master copy of OpenMRS for access

o A structure to allow many secondary uses of that data

  • Currently not very good at supporting large volumes of data from disparate sites

  • Issues:

  • Would like to use this to generate MoH reports, but then could also use analytical tools for data mining
    o What can be attached, eg SNOMED maps

  • SA in 1995 - created a data warehouse from Joburg Gen, Somerset Hosp HIV clinics. Data mining allowed demonstration of the value of Vit B supplementation in delaying AIDS onset. This was later prospectively proven

Individual vs. aggregate data:

  • Normally shy away for exporting whole patient record due to issues of confidentiality

  • Should data be analysed locally or at government level

  • SA example:

o Electronic TB register - patient level data off a TB register, compiled into a district register, then exported to the national level.
o Although can only see de-identified, anonymised data at higher levels, all patient data is still included.
o Could use similar architecture.

  • TB - represents a small slice of the population, but can you actually implement across all facilities in the primary health care system without computers?

  • Balancing the need for data collection with the need to protect data from unwarranted use is difficult - report only what is necessary

  • In places like the US, patient level data is usually managed by the health care facility - they are responsible for maintaining the privacy of those patients. Need to justify getting access

  • SA TB register - patient data is carried within the warehouse, can drill down to patients.
    o Very useful because started project long before HIV was being treated in SA - allowed several publications about HIV and TB links

  • Tension initially about doing research on systems like OpenMRS

  • Issue of architecture - where does that data live? Being able to get down to the patient level data has immense value, but better to keep patient level data out of the warehouse and link back instead - then have permissions in place, don't store all patient level data in the warehouse

  • Public health surveillance is all about building cohorts of data. Public health rationale for collecting this data.

  • US system pays for datasets to be extracted from individual level data - aggregate data doesn't serve this purpose

  • Don't confuse patient level data with identified patient level data - need identifiers at the clinic level, but this is about the need for role-level data (anonymised) vs. aggregated data. Aggregated data can't replace patient level data.

  • Need to validate data quality - how can you do this without holding individual records? Need to be able to trace back to the original site.

  • Could be paper records but need to be well designed so can be computerised and sampled in different ways.

  • May be valuable to de-identify higher up the tree.

  • Other tools which collect data in the primary healthcare facilities - lots of data needed in the warehouse, not all is collected by the EMR e.g. HR data, data on medicines - stock-levels etc, facilities, medical equipment

  • Policy issue about collecting individual records above the facility level - need to design who has access. Should be a policy governing how to drill down

Data validation

  • How to convince the ministry that what you're doing is what they want?

  • Completed an audit process, took a long time - painful. What have others done?

  • AMPATH - sent reports, where questioned, sent the 'recipe' - here's how we inferred the numbers, if you have suggestions, let us know.

  • Data quality assessment tools
    o look at data over a period, e.g. clinical data about new patients enrolled
    o get a representative sample of a range of facilities, done through MoH staff
    o go down to the source documents - patient cards and look over a three month period - need to literally go through every record, but in the end gives a very good picture of the data that is being received at higher levels

  • Have a feedback system to report back to the local level - two way understanding of the validation process

  • Australia - clinical level through a clinical governance framework, physicians validate the data, then goes to the quality branch of the ministry - they have tools

  • Need to provide documentation on medication errors or surgery that went wrong

  • NB to set expectations with the ministry - sometimes don't want to know this info - in the past data has been manipulated to look good.

  • Ghana - normally data is aggregated. Validating the data is difficult Don't have the patient data to validate. Orginally had patient data entered in CSPro, now are switching to OpenMRS and this how they'll be able to validate - moving down to a patient level to validate data.

Harmonizing reporting systems

  • Asked to furnish reports for multiple different stakeholders

  • strategies to harmonise, involving a concept dictionary

  • do others have the same challenges?