"HIT-assisted care" means health care and services that incorporate and take advantage of health information technologies and health information exchange for the purpose of improving the processes and outcomes of health care services. HIT-assisted care includes care supported by and involving: EHRs, clinical decision support, computerized provider order entry, health information exchange, patient engagement technologies, and other health information technology used in clinical care.
There are two separate questions:
1. What technologies, properly used, improve safety?
2. Given that automation can introduce new types of errors, what can be done to ensure that HIT itself is safe?
To explore these topics, let's take a look at Health Information Exchange (HIE). What HIE technologies improve safety and how can we ensure the technologies are safe to use?
At Beth Israel Deaconess Medical Center we exchange many types of data for care coordination, patient engagement, and population health. Below is a detailed summary of the HIE transactions implemented in our recently certified hospital systems.
Most of these transactions are sent via the New England Healthcare Exchange Network (NEHEN) using AES256 and SHA-1 to encrypt and hash data, ensuring the privacy and integrity of information shared among payers, providers, patients, and government in Massachusetts.
1. Patient Summary Exchange for Transitions of Care
We produce a Continuity of Care Document for each patient handoff i.e. from inpatient, ED and outpatient (coming soon) to home, skilled nursing facilities, or other hospitals. The CCD includes
Problems
Procedures
Medications
Allergies and Adverse Reactions
Results
Encounters
Safety is improved by ensuring each provider has a complete problem list, medication list, allergy list, and recent results. Such a document is useful for medication reconciliation, drug/drug and drug/allergy decision support, and managing the entire patient by understanding all active problems.
However, summaries exchanged at a point in time are just that - a summary or abstract of the lifetime record that is accurate at a point in time. They do not provide access to the complete record such as inpatient notes, operative notes, history and physicals, and historical data such as discontinued medications or resolved problems. Many clinicians believe that a patient summary at a point in time is good enough for transitions of care, so the risk introduced by abstracting the record into just the salient handoff details may be minimal. A compromise may be a fresh look at what elements should be required for transitions of care. Last week, Massachusetts was awarded an ONC challenge grant to study this question by piloting innovative additions to the standard CCD using CDA Templates.
Here's a CCD for transitions of care, displayed in human readable form via a stylesheet.
2. Patient Summary Exchange from EHRs to PHRs
We produce a Continuity of Care Record when a patient initiates a transfer of their records from our EHR to the PHR of their choice (Google or HealthVault). The CCR includes
Demographics
Problems
Medications
Allergies
Additional Information About People and Organizations
Safety is improved by sharing data between providers and patients, making the patient the steward of their own records. This transparency encourages a dialog about treatment plans, patient care preferences, and the accuracy of data in the medical record.
However, most commercial Personal Health Records do not provide for exchange of clinician office notes such as we've piloted in BIDMC's Patientsite OpenNotes Project, nor do they include a consistent way to map EHR data to PHR displays. For example, BIDMC's EHR considers an allergy list entry to be the substance, the reaction, the observer (doctor, nurses, your mom), and the level of certainty. Google considers an allergy to be the substance and a mild/severe indictor. Thus, a transmission of an allergy "Penicillin, Hives, Doctor, Very Certain" to Google results in "Penicillin" with no other information. Use of an agreed upon list of data elements (i.e. what constitutes an allergy list) for data exchange would resolve this problem.
Here's a CCR transmitted from an EHR to a PHR, displayed in human readable form via a stylesheet.
3. Patient Summary Exchange for Discharge Instructions
We produce a Continuity of Care Document with discharge instructions for patients via a multidisciplinary web application used by doctors, nurses, social workers, and case managers. The CCD includes
Discharge Medications
Discharge Instructions
Final Diagnosis
Recommended Follow-up
Major Surgical or invasive procedures
Condition at discharge
Safety is improved by ensuring the patient understands the next steps after they are discharged from the hospital. Inpatient medications are reconciled with outpatient medications, dietary or activity restrictions are noted, and followup appointments are documented.
However, at present, Meaningful Use does not require a specific electronic format for patient discharge communications. Patient discharge instructions are generated by humans and include a distillation of the record, not a complete copy of the record. A printed report, a PDF, or a web page all suffice. Although we have used the Continuity of Care Document format, it is not optimized for structured discharge instructions. Likely CDA Templates with specific fields for the data elements most commonly used in discharge communications would be better.
Here's a CCD for patient discharge instructions, displayed in human readable form via a stylesheet.
4. Patient Summary Exchange for Quality Measurement
We produce a Continuity of Care Document with key process and outcomes measures for transmission to the Massachusetts eHealth Collaborative (MAeHC) Quality Data Warehouse. MAeHC computes all our ambulatory PQRI measures and all our pay for performance metrics. The CCD includes
Payers
Problems
Procedures
Results
Medications
Encounters
Safety is improved by providing our clinicians, administrators, and government agencies with the metrics needed to evaluate our process and outcomes quality.
However, quality measures require precise coding of concepts into SNOMED-CT and other vocabularies. It is up to the clinician to translate their observations into the correct structured data and this is challenging. Better tools to automatically map physician plain language into controlled vocabularies would help.
Here's a CCD for quality measurement, displayed in human readable form via a stylesheet.
5. Patient Data Exchange for Public Health Activities
We produce numerous submissions to government agencies to support population health and public health goals. The messages are sent to public health in batch every day based on results filed into patient records. They are exact duplicates of patient results, diagnoses, and immunization records without any loss of completeness.
Reportable lab results are sent to the Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for labs.
Syndromic Surveillance is sent to the Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for surveillance.
Immunizations are sent Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for immunizations.
Safety is improved through monitoring of results, symptoms, and immunizations in support of public health.
However, syndromic surveillance is limited by the accuracy of the structured signs and symptoms data captured by EHRs. Ensuring that clinician observations are captured in an accurate, structured and timely way, then transmitted to public health requires more advanced vocabulary tools than exist in many EHRs.
Summarizing my observations:
1. Summary data is an abstract captured at a moment in time. Data corrections/updates are not sent. Thus, data about the patient becomes incomplete and stale over time. However, for the purpose intended, ensuring a transition of care is safe, a point in time summary may be good enough.
2. Enhanced vocabulary tools that translate clinician observations into structured data (such as Kaiser's recent contribution of its intellectual property) are useful to convey the meaning of information exchanged.
3. Implementation guides that specify required data elements are important so that receivers can accurately display the information exchanged.
4. Testing approaches already used as part of the certification process validate that data in the EHR is exported into interoperable formats accurately. NIST tools ensure that interoperable formats are compliant with standards. The challenge is getting the data into structured electronic form to begin with and deciding what to exchange for a given purpose
5. Although not specifically discussed above, patient identification can be a challenge given the lack of a national patient identifier or an agreed upon way to link the same patient's data among multiple institutions. The combination of labs, medications, and summaries from multiple sources might indicate a safety issue. Having a consistent approach to link these records would be helpful.
A number of these issues are part of the PCAST Workgroup discussion - should data be sent in context rich documents or separated into individual "atomic" data elements? How granular is an atom - is it a problem list, a single problem, or a single field within a single problem (i.e. problem onset date)? How should patient matching be done? How should searching be done? Should data be structured and vocabulary controlled or unstructured?
The IOM, ONC, and the PCAST efforts are raising all the right issues. I believe the Standards and Certification criteria for Stage 1, exemplified by all the standards samples documented above, is moving the country on the right trajectory to enhance the safety of care while ensuring HIT-assisted care is safe.
5 comments:
Hi John,
Thanks for the public surveillance message. Since there is no validators to test the conformance of the message, how can I verify the message? Against which one I'l verify that? NIST asked to do manual verification of the message based on message type (if HL7 2.5.1 is version, then what is the message type which is used to test the conformance of the message generated). Could you please shed some light on this?
Manual inspection is all that is done because at this point, no tools are available. Hopefully this will change soon as an implementation is issued.
Hi John,
Does the public health surveillance message must contain OBX segment? Is there any message definition available for this?
Thanks for your time and help
Hi Dr. Halamka,
Does BIDMC save each CCD/CCR that is generated as a discrete document in the medical record for reference at a later date? Or are these not saved as a stand-alone document. Thank you.
Hi John,
Your points about data consistency when sharing between different systems is probably the key to interoperability. Exchange, by comparison, is relatively simple. Safety risks are huge if there is inconsistency in data, and also if the data structure is not ratified as 'fit for use' by clinicians.
Your example of adverse reactions/allergies is critical for patient safety. A common and agreed structure for representing an adverse reaction in disparate systems, plus appropriate terminology binding will prevent some of the issues you raise. You can find an example of an evolving model that is undergoing review by the Australian clinical and stakeholder community here - http://bit.ly/dTaTij - under the auspice of NEHTA.
The potential disparities of data being sent and received are very real and can be solved with collaboration, but I'd also like to point out that data structure and definitions need to be considered carefully and by clinicians and informaticians who understand how clinical data can be used in EHRs, for exchange in messages, for aggregation and to support knowledge-based activities such as decision support. For exmaple, recent advice coming from UK NHS includes avoiding sharing information about 'mild' allergies or 'moderate' adverse reactions - as these statements usually relate only to the severity of reaction that was experienced during one exposure event. However these qualifiers are often captured in receiving systems and then displayed in such a way that the the severity qualifier is represented (incorrectly) as the future propensity for the reaction. It is not safe for a mild reaction on first exposure to be persisted in an EHR or exchanged with other providers as a mild propensity for future reactions.
Regards
Heather
Post a Comment