Measuring Health in the Primary Care Context: Unlocking the Value

• Abstract
• Introduction
• Encouraging the Systematic Recording of Clinical Data by General Practitioners
  • Data Transfer: How Do You Write "Good" XML?
  • Disease Coding Issues
  • Transferring Prescriptions
  • Smoking Status - a Case Study
  • Privacy Issues
• Using the Information Collected to Achieve the Measuring Health Objectives
  • Improve the Management of Chronic Disease
  • Inform Funding Decisions and Programme Planning
  • Demonstrate Improvements in Quality of Clinical Care
  • Creating Value Opportunities
• Conclusion

Abstract
ProCare has embarked on a project, "Measuring Health", to establish the means to collect clinical information from its general practices and then to use it to improve the management of chronic disease; to better inform funding decisions and programme planning; and to demonstrate improvements in the quality of clinical care provided by ProCare’s members. This paper describes how ProCare is working towards these goals by: encouraging clinicians to record clinical information systematically; defining an XML-based standard for the transmission of this information; and determining how the information collected might be used to achieve the objectives of the project.

As part of "Measuring Health" ProCare has commissioned the development of a "Patient Dashboard" within the MedTech32 practice management software to make it easier for clinicians to identify where clinical information has not been systematically recorded, and also make it easier for clinicians to record this information in a standard manner.

ProCare developed an XML-based standard that allows the collected clinical data to be exported from the practice management software for central collection and analysis, taking into account the pragmatic constraints of how information is currently recorded within practice management software.

A range of options as to how the important issue of patient privacy can be addressed are being considered.

ProCare is optimistic that in the near future they will be able to collect meaningful clinical information in the primary care context and can start to unlock the hidden value in this data.

Introduction
ProCare Health Limited is a company owned by 370 general practitioners that aims to be New Zealand’s leader in managing the provision of high quality community-based health care. Its members provide primary health care to approximately 650,000 patients in the greater Auckland region.

In October 2002, ProCare commissioned a project called "Measuring Health" in response to an important need to understand the health needs of its patients and to ensure that funding is directed where the greatest health outcomes can be achieved. The project is designed to:

1. Improve the management of chronic disease by identifying opportunities for improving patient care.
2. Inform funding decisions and programme planning by taking into account:
   • The incidence and severity of disease;
   • The incidence of risk factors;
   • The cost of treating disease.
3. Demonstrate improvements in the clinical quality of care delivered by ProCare’s members, measured using clinical outcomes.

Measuring Health has three concurrent work streams created to contribute to these objectives. They are working on:

1. Encouraging the systematic recording of clinical data by general practitioners.
2. Regularly collecting this clinical information.
3. Using the information collected to achieve the project’s objectives.
   

This paper presents ProCare’s approach to Measuring Health, and discusses in detail the issues faced in collecting clinical information and how these have been (or are being) addressed.

Encouraging the Systematic Recording of Clinical Data by General Practitioners
Seventy-seven percent of ProCare’s practitioners use MedTech 32 as their practice management system. Accordingly, we considered and addressed MedTech32’s barriers to systematically recording clinical information^{[ a ]}. We identified the following issues:

1. READ codes are used to systematically record the presence of disease in a patient (and can also be used to record other data such as social history). Our experience is that this is a barrier to the systematic coding of disease by practitioners because:
   • The process of coding is counter-intuitive and the amount of time taken to accurately code a disease is often perceived to be unacceptable.
   • There is not always a good match between the READ codes and the diseases that are commonly encountered in primary care.
   • There is no enforced consistency of coding. Different GPs will code the same disease differently (and even the same practitioner may code the same disease differently over time).
   • Practitioners do not perceive there is any value to be derived from the process of coding.
   • Practitioners have not been provided with any assistance or training in coding.
2. There are a variety of ways of recording clinical observations within MedTech32 and each practitioner may choose a different way. There are no formal guidelines to advise GPs exactly how to systematically and consistently record height, weight, cardiovascular risk, blood pressure, alcohol consumption or smoking status.
3. Different projects often require what is essentially the same information to be recorded in different ways. For example, both the "Diabetes Get Checked" project and ProCare’s own programme for assessing cardiovascular risk have different ways of recording smoking status.

To encourage GPs to record patient data consistently, in a collectible form, such that analysis can then provide ongoing benefits to them and their patients, ProCare has commissioned the development of a "Patient Dashboard" to be used within the MedTech32 practice management software. The Dashboard is a new form that will:

• Alert GPs to the absence of information that should have been systematically recorded but cannot be located. For example, if a practitioner has not recorded the blood pressure of a patient within a defined time period, then the practitioner will be alerted to this. [It may be that the blood pressure has been taken, but it has not been recorded systematically and therefore does not "count" in terms of the Patient Dashboard].]
• Simplify the process of coding patients for a set of sentinel diseases, through a process of "check boxes", without practitioners having to ever know or interpret a READ code. This process will also be used to allow GPs to indicate the absence of a disease, which is also important when determining the extent to which disease has or has not been identified within a given patient population (ie, to correctly quantify the denominator). This illustrates the important principle that the way that data is entered and recorded can and often should be different from how it is stored.
• Alert GPs to ProCare health care programmes that patients qualify for and that the practitioners might not otherwise have been aware of.
• Simplify and standardise the recording of clinical information according to best practice, eg, smoking status.

Our intention is that practitioners will receive significant value from this information and will thus be encouraged to use the Dashboard when seeing nearly every patient.

Collection of Clinical Information and Transfer From Practitioners to the Primary Health Organisation^{[ b ]}
The most difficult part of Measuring Health has been to define a standard way of collecting clinical information that would work across multiple practice management systems taking account of the many real-world constraints of what is currently held within practice management systems and how such data are held.

There are some important principles we wanted to adhere to during this process, because we believe they are important to project success. Specifically:

• Data collection should be a by-product of normal clinical workflow, rather than a separate activity that exists outside what GPs feel is necessary to manage patients’ health.
• Innovation and new developments in how information is recorded by GPs should not be constrained - the format in which data is sent should not constrain how information is collected and used within the practice management system.
• The processes of data "cleaning" and "transformation" required to produce data in a suitable format for reporting should be done centrally, not within practice management systems. We are of the view that activity adds unnecessary complexity to practice management software and requires significant manual involvement.
• The format specified for data transfer should be effective within a wide range of applications where clinical data needs to be transferred.
• Whatever ProCare does must ultimately work for all practice management systems and Primary Health Organisations (PHOs).

To define a standard for the collection of this data, we formed an expert committee that comprised representatives of ProCare’s members, HealthLink, intraHealth, MedTech and Next Generation. This committee met over several months to draft a standard for exporting clinical information from practice management systems to PHOs. It is our intention to publish this first draft for public comment and then to produce a final version to be adopted by any vendor who wishes to use the standard within their own practice management system and/or PHO management system.

Some of the major issues confronted during this process have included: having selected XML as the best format for our data transfer, how is "good" XML to be written; how to ensure consistency of disease coding such that useful reports and analysis can be run; how to transfer prescriptions and other issues arising from lack of consistent codes for drugs; and how to ensure patient privacy and confidentiality while recording, transferring, reporting on and analysing health data.

Data Transfer: How Do You Write "Good" XML?
Early in the project, we quickly determined that using the XML format for data transfer provided a much higher degree of flexibility than alternatives such as pipe-delimited formats. We encountered little support for using pipe-delimited formats such as that used by HL7 version 2. However, figuring out how to write good XML proved problematic.

Whilst developing our XML schema, we came across a number of issues. The first was to figure out how to choose between the various options for writing good XML. Most of the books and articles we reviewed used examples that did not apply to health data, but were typically used to describe documents and text that had little relevance to transferring structured data.

As an example of the kind of problem encountered, consider which of the following is correct:


or:

There are advantages and disadvantages of both approaches, and we expected to find a wealth of guidelines on how to resolve these dilemmas and determine the most appropriate conventions. Instead, we were stunned to find that exactly these kinds of debates are being carried on around the world and authoritative guidelines on how to write good XML have yet to be developed.

A further issue arises from a basic conflict of structures. XML is inherently hierarchical, whereas good data design is relational. For example, when defining the schema for XML purposes, it becomes necessary to determine the hierarchy for the various elements. That is to say, which should be preferred:


or:


Both structures imply a hierarchy, yet neither structure is correct in all contexts. Only relational design solves this problem yet XML does not cope particularly well with relational data.

Whilst there are obvious answers to some of these examples, we came across many where there was no easy answer and there were valid arguments supporting each of the available choices.

We also needed to determine whether we would define specific or generic XML. With specific XML, we would define:



whereas if we were to be more generic, we would define:



The second example appears to be more flexible, as should a new type of measurement be invented, no change to the XML schema is required. However, we have argued that all one does in using generic XML is to shift the onus of defining the information required from how the elements are named to the values one expects for each element name. We are of the view that the first example above is more helpful and useful because of its inherent clarity and specificity.

To resolve the dilemma of whether to use specific or generic XML, we decided to be cognisant of how the information is actually recorded within practice management systems. If the information we wanted to collect were typically stored generically, then we would define generic XML. Conversely, information typically stored in discrete elements would result in use of a discrete XML element. For example, laboratory results are typically stored generically (a lab result for blood glucose is stored in the same way as a lab result for Creatinine) whereas Height and Weight are discreet items of data typically stored separately and not in a generic "measurements" table.

In conclusion, XML is a less then perfect language for transferring relational data from one place to another, but still provides a significant improvement over other options.

Disease Coding Issues
One of the critical pieces of information we are hoping to collect is the "problem list" or list of diseases that a GP has identified for each patient. The difficulty with achieving this is that, as noted above, there is no standard way that GPs code diseases, and even where such standards are available and are used, there is still widespread variation in how diseases are coded. Within MedTech32, READ codes are used to formally code diseases in each patient record, however:

• not all practice management systems use READ codes
• different GPs will use different codes for the same disease
• a single practitioner may use different codes for the same disease over time.

To resolve this issue, we decided to simply collect whatever information is available and, we have defined a format that provides for the entry of both structured, coded data and "free text" data. Data-cleaning and transformation techniques will then be used to analyse the data and "standardise" the coding of diseases for the purpose of analysis and reporting.

In addition, standard coding systems do not exist (or are not implemented) for drugs and laboratory tests, which again will require us to collect whatever is available and then use data transformation and cleaning techniques to present the data in a consistent manner for analysis and reporting. We are of the view that this is best done centrally than to require this to be done in each practice management system due to the amount of manual effort and processing required.

Transferring Prescriptions
New Zealand continues to suffer from the lack of a standard for identifying prescription drugs. Although there are a number of systems in use by various communities (Pharmac codes being the most common), no standard way of identifying a specific prescription drug has been agreed. Because there is no national terminology or taxonomy, each practice management system vendor must maintain their own list of drugs that can be prescribed and must give each GP the freedom to add any missing or new drugs to the table. This means that it is not possible to reliably transfer information about prescriptions in a coded form between GPs and PHOs.

Smoking Status - a Case Study
We have been surprised at the lack of readily available information about how to systematically record information in the primary care setting. Whilst a number of organisations have mounted individual efforts, we could find no widespread evidence of widely agreed standards for the recording of information.

This problem is well illustrated by looking at the specific case of how general practices record information about patients’ smoking status. ProCare’s members are involved in a number of programmes that require patients’ smoking status to be recorded.

For example, a search for "smoking status" on Google, the New Zealand Health Information Service web site (www.nzhis.govt.nz), and the HL7 site (www.hl7.org) confirms that there are more questions than answers on this somewhat tricky subject. The following table shows the various permutations and combinations of how smoking status is defined in New Zealand and recorded within various programmes:

Privacy Issues
Ensuring the privacy and security of patients’ health data in collecting, and transferring such data for meaningful analysis is essential. Unless privacy and security of information can be guaranteed, GPs will simply not send their clinical information anywhere (and rightly so). Further, if patients do not believe that their clinical information is safe with GPs, the quality of care that can be delivered by GPs will be compromised.

ProCare is of the view that an NHI number identifies a patient and, therefore, using NHI numbers in health care data used for larger purposes does not ensure patient privacy.

We are currently exploring two models that would enable information to be provided by GPs whilst maintaining patient privacy.

1. Encrypted NHI numbers: By "one-way" encryption of an NHI number, we can determine that two records belong to the same patient without being able to determine the identity of the patient. There is, however, much debate about whether there is any such thing as "one-way" encryption of an NHI number.
2. Policy based privacy: Maintenance of patients’ privacy not through any inherent technology, but rather through a set of policies outlining how information should be handled. For this approach to work, practitioners must accept that sending identifiable clinical information is not itself a breach a patient privacy - a breach occurs only if identifiable information is disclosed. For example, one could envisage an approach whereby a GP sends identifiable clinical information to a PHO, and that the PHO agrees never to disclose this information (including to the PHO’s own employees). This would be implemented both by appropriate security within the information systems that manage the data and through agreed policies that employees are required to comply with.

The down-side of the policy-based approach is that it requires complete trust between the sender and recipient, and it requires the recipient to have a foolproof method of ensuring that identifiable information is never disclosed. Even a single breach of patient privacy would irrevocably damage this trust.

Using the Information Collected to Achieve the Measuring Health Objectives
The last link in the "Measuring Health" chain is to use the data! The risk of creating a "data cemetery" is great unless due consideration is given to how we might provide the PHO and its practitioners with meaningful information gleaned from the collection of clinical data.

Although this phase of the project has yet to commence, we expect to meet the project’s objectives as follows.

Improve the Management of Chronic Disease
We expect to help our practitioners improve their management of patients’ chronic disease by:

• Providing GPs with a list of patients potentially receiving sub-optimal care, eg, patients who are hypertensive but have not been prescribed appropriate medication.
• Identifying diseases where incidence is lower than expected, perhaps suggesting a screening programme or training opportunity, eg, under-identification of diabetes in a particular practice or region.
• Identifying opportunities to develop new health programmes targeted at specific chronic disease issues, eg, perceived under-prescribing of statins for patients with high risk of CVD.
• Providing GPs with peer-comparison reports, eg, comparing treatment options for patients with heart disease.

Inform Funding Decisions and Programme Planning
It is anticipated that Measuring Health will ultimately improve funding decisions and programme planning by producing data that will:

• Identify diseases with high prevalence.
• Identify diseases with high severity.
• Correlate risk factors to incidence and severity of disease.
• Quantify the cost of treating patients with specific diseases.

Demonstrate Improvements in Quality of Clinical Care
By collecting information over time, we expect Measuring Health will provide evidence for the efficacy of the various programmes our practitioners participate in. For example, we may be able to demonstrate that practitioners who participate in the Diabetes Get Checked programme are improving outcomes for diabetics compared to practitioners who do not.

Creating Value Opportunities
There is an obligation on ProCare to seek opportunities whereby its practitioners can avail themselves of additional revenue-earning opportunities from the information they systematically record. For example, ProCare currently runs a project that allows suitably qualified patients to be enrolled in a fully funded smoking cessation programme, which extends the services provided by general practice. Measuring Health will encourage the systematic recording of a patient’s smoking status and, thus, allow the practice management system to more efficiently identify patients that qualify for this programme.

Conclusion
ProCare’s "Measuring Health" project is still in its infancy. There are still many more hurdles before we can claim a successful conclusion to the project, and we are very aware that the path before us is littered with the similar projects that have failed.

We are, however, optimistic that we will be successful, because:

• The Ministry of Health has defined a number of Clinical Quality Indicators with the promise of significant financial reward to practitioners who meet agreed targets. The imperative and incentives of the Clinical Quality Indicators are therefore promoting focus to the effort
• The scope of our project is small which in itself decreases risk
• We have the privilege of having a membership who largely trust us
• We have experience in influencing our members and assisting them to change their behaviour
• We are taking a very practical and pragmatic approach
• We have some talented staff, vendors and members helping us
• We recognise that our first implementation will be less than perfect and that further development will be required.