NeoTool — Singular Focus, Healthcare Integrated

The Continuity of Care Document (CCD) defines a detailed set of constraints, or templates, for CDA elements. Each template may have further supporting templates as required. The data contained in each of the templates is set by CCR.

Below is an overview of the templates (excludes supporting templates) and how they are used.

Header
Defines the type of document being created, who the document is regarding (patient, physician, author) and how the document relates to other existing documents (if applicable).

Purpose
States the reason the document was generated, but only if a specific purpose is known (i.e., a referral, transfer, or by request of the patient).

Problems
Provides a list of relevant clinical problems, both current and historical, that are present for the patient at the time the document was created.

Procedures
Provides a list of all relevant and notable procedures or treatments, both current and historical, for the patient.

Family history
Gives relevant family health information that may have an impact on the patient’s healthcare risk profile.

Social history
Describes the patient’s lifestyle, occupation, and environmental health risks plus patient demographics such as marital status, ethnicity and religion.

Payers
Provides payment and insurance data pertinent to billing and collection, plus any authorization information that might be required.

Advance directives
Includes information about wills, healthcare proxies and resuscitation wishes, including both patient instructions and references to external documents.

Alerts
Provides a list of allergies and adverse reactions that are relevant for current medical treatment.

Medications
Provides a list of current medications and relevant historical medication usage.

Immunizations
Gives information the patient’s current immunization status plus pertinent historical information about past immunizations.

Medical equipment
Provides a list of medical equipment and any implanted or external devices relevant to patient treatment.

Vital signs
Details information about vital signs for the time period including at a minimum the most recent vital signs, trends over time, and a baseline.

Functional stats
Details information about what is normal for the patient, deviations from the norm (both positive and negative) and extensive examples.

Results
Lists lab and procedure results, and at a minimum lists abnormal results or trends for the time period.

Encounters
Details relevant past healthcare encounters including the activity and location.

Plan of care
Lists active, incomplete or pending activities for the patient that are relevant for ongoing care - including orders, appointments, procedures, referrals and services.

For additional information on getting started with CCD, please read the post on the quick start guide provided by EHRVA.

Any “feed”, whether an ADT feed, ORU feed or ORM feed, is basically a streamlined way of getting messages. In the HL7 standards world, ADT, ORU (order messages) and ORM (results messages) are the most common HL7 messages. Of those three, ADT messages are the most commonly used.

ADT stand for “admissions, discharges, and transfers”. It basically means demographics; anytime you think of ADTs, think demographics: the patient’s name, the patient’s location in the hospital, his or her address, phone number, gender, etc.

There are many different types of ADT message types, such as:

• Registering a patient
• Discharging a patient
• Merging patient files to avoid duplication

An ADT feed is one way an application or a provider can get all that information from a clinic or hospital information system (HIS). With the constant updating of a client, customer or patient’s data, ADTs comprise the most HL7 messaging traffic. Change of address, addition of a middle name, and addition of next of kin are all examples of the type of data updates that make up ADT messages. Upon updating, this clinical data will then flow out to different places such as outpatient clinics or laboratories, dependent on who needs that information in their database.

Typically, a hospital registration database will have the master of the patient data and information. Each time patient information is updated, the updates will be pushed out in the form of an ADT message to the appropriate applications in facilities such as labs or clinics.

ADT feeds are usually received through either an interface engine or direct (point-to-point) interface.

In the case of an interface engine, clinical data can be provided to a variety of places. An export can be set up so there can be a one-on-one connection where, for example, a hospital registration system can establish a connection to a lab outside of the hospital. “Data dumps” are also possible, where one end of the application has all the files and the other doesn’t and through the connection, the patient data can all be transferred.

In summary, ADT feeds are the most common and high volume feed used. The updating of patient information eclipses the volume of order and result feeds. Having up-to-date patient information, though, is a critical component in streamlining and improving the continuity of patient care.

Tim Gee with the Medical Connectivity wrote a great review of the recent Healthcare Unbound conference that was held in San Franciso. Tim did an excellent job of providing good detailed insights from the conference.

The Center for Business Innovation hosts the conference, and they describe Healthcare Unbound in the following manner:

Innovative technologies are driving opportunities to serve consumers in new ways and in new settings. Forrester Research coined the term “Healthcare Unbound” to encompass the trends toward technology-aided self-care, mobile care and home care. More specifically, Forrester describes “Healthcare Unbound” as “technology in, on and around the body that frees care from formal institutions.”

As healthcare IT evolves and changes, it is interesting to read the thoughts and activities happening at the consumer level.

As noted in HIS-Talk, Former Meriter Hospital CIO Peter Strombom has written an interesting article on Wisconsin’s progress towards a regional health information exchange (RHIO). Peter’s history and thoughts are very pragmatic and, IMO, on target; I thought I would share some quotations.

The motivation behind Peter’s article is that, like many areas of the US, Wisconsin has been talking about building a RHIO (or two) for a long time. The current challenge is architecting the system and ultimately paying for it. The state has issued an RFP asking for help designing the architecture. Costs for the total deployment are estimated at $1.2B and are, presumably, to be funded by the providers.

Peter makes some great points about:

1. The fact that we’ve been at this “regional interoperability game” for a long time.
2. RHIOs are the latest name for an old idea
3. Peer-to-peer communication (rather than centralized “control”) has a better chance of success
4. Good discussion of political v. economic v. quality of care motivations for interoperability
5. Providers must be using electronic records before they can be exchanged, well, electronically
6. On-going work to firm up standards will help with interoperability

Two counter points I would make to Peter’s thoughts:

1. I do not think that the banking analogy Peter uses is a good one. The banking world has (effectively) centralized control over the SWIFT and related networks. A better analogy would be peer-to-peer file sharing networks — heck, if we can share MP3s in an ad-hoc-yet-organized-way, surely we can share healthcare records.
2. IMO, the CCHIT is not the total driver for peer-to-peer interoperability. HL7 (among others) has been working on this problem for a long time and, again IMO, CCHIT is effectively profiling existing standards rather than creating new standards.

Selected quotations from Peter’s article:

[In November 2005 Wisconsin’s Governor] called for “a statewide eHealth infrastructure […]. [P]resident Bush’s State of the Union Address [in January 2004] stated that “By computerizing health records, we can avoid dangerous medical mistakes, reduce costs, and improve care.”
…
The statements were both politically appropriate at the time, but as of June, 2008, little has been achieved in Wisconsin.

We have been at this for a long time. The CHINs (community health information networks) of the mid-1990s were an idea that had merit but was not adequately supported by the technology of the day. The RHIOs (regional health information organizations) of later times were also a great attempt at interoperability but suffered from lack of community acceptance and viable business plans to sustain them. It is telling that only a handful of RHIOs continue in business from the several hundred that were founded on initial seed money only to fail when those funds became exhausted. The poor support from the healthcare providers and the payer community, and the absence of inspirational insight into the opportunity being presented to us by the technology, contributed to the lack of success of what I will call the second generation of this approach at interoperability.

Presumably, the healthcare provider and payer will bear the cost of this process. […] Importantly, to be viable, the plan further assumes that all healthcare providers in the State of Wisconsin will maintain patient records electronically. This is not the current or the foreseeable situation, as many small hospitals and physician practices do not have the available funding to achieve this goal with only their own resources.
…
Application (systems) vendors in healthcare are working together under the auspices of the Certification Commission for Healthcare Information Technology (CCHIT) to develop standards for interoperability. By working together it is planned that their output will become accepted as was the HL7 interface standard. A peer-to-peer network with communications between healthcare providers using software from the same or different software vendors and based on the CCHIT standards could follow a model based on the Banking system model.
…
This peer-to-peer network lends itself to progressive growth and expansion, as warranted as additional providers implement electronic medical records systems. Importantly, a sustainable business plan at the operations level is not needed to finance the exchange of key clinical information in a time of need.

There is an interesting blog post in BNET entitled Electronic Medical Records:  Bad for Health? The discussion around EMRs is fascinating. There are many differing perspectives on various topics:  privacy, interoperability, usability, acceptance, failure, etc.

This article consolidates some of the recent negative articles or perspectives on EMRs, including:

• Privacy - exposing patient data to outsiders.
• Savings - insurers gain more than physicians
• Copy-and-paste - copying notes from one patient record to another, because it helps with billing
• Too much information - no human selection of relevant information
• Physician insensitivity - “Dr. Computer”
• “Cookie-cutter” medicine - just using the template

These points may be valid, but is the status quo better? Continuing with a paper-based system does not seem to be the better answer. Having the right sense of responsibility to deliver the right approach in using EMRs seems to address many of the potential issues.

With Stark Law changes, there is increased interest in what hospitals can and cannot do as it relates to giving Electronic Medical Record (EMR) software to physician practices. A recent article in Physicians Practice highlights the fact that there is no such thing as “free.”

Although some EMR costs are covered (e.g., software purchase, order and results integration), there are other costs that will be required. For example:

• Hardware costs
• Technical support costs
• Ongoing application support costs
• Hosting costs (if SaaS or ASP model is used)

The article points out the obvious point:  With Stark and other “free” options, the overall costs of an implemented EMR are still lower than if the physician practice implemented it on their own. Implementing the EMR application still creates benefits such as potentially higher pay-for-performance payments, possible payer subsidies and, of course, more accuracy in patient care. “Free” may not be completely free, but it is a reasonable starting point.

HIMSS EHRVA developed a Quick Start Guide for implementing the Continuity of Care Document (CCD). HIMSS EHRVA is a trade association of Electronic Health Record (EHR) vendors. Included in the file are two sample CCDs. The guide seems to be a useful resource for implementers of integrated healthcare systems.

A few past posts and insights that you may want to explore:

• What is the CCD?
• EMR Interfacing Best Practices
• Get the Workflow Right First
• Comparing HL7 Messages to HL7 Documents

Please post any experiences that you have in implementing the CCD or using this Quick Start Guide.

As noted in HIS-Talk and HANYS News, CMS released an advisory opinion that allows for hospitals to pay the cost of EMR interfaces without violating the Stark Law. Hospitals are restricted under the US law regarding compensation arrangements between physicians and hospitals. HANYS News wrote:

Specifically, a hospital system can pay for the creation of an electronic interface between unique electronic health record (EHR) systems of individual physician practices and the hospital network’s EHR system. The interface would allow physicians, from their practices, to order and communicate the results of tests and procedures performed.

The CMS news was delivered in “Advisory Opinion No. CMS-AO-2008-01″. There are many words used in the advisory; here is a quote that is the meat of the opinion:

The Requestor … owns and operates … hospitals … [and] contracted with a third-party … Vendor … to install a proprietary health care software information …System …, customized to the Requestor’s specific requirements, including a software interface engine that facilitates access by the custom Physician Practice Interface(s).

Pursuant to the contract between the Requestor and the Vendor, the Vendor provided software licenses to the Requestor that permit the Requestor and its controlled affiliates to use the System.

Currently, the medical staffs of Requestor’s … hospitals have the option to view laboratory reports for the Requestor’s patients over a protected internet connection to the System. The Proposed Arrangement would permit also the ordering or communicating of laboratory tests or procedures performed by the Requestor using the Physician Practice Interface(s).

Numerous physicians on the Requestor’s medical staffs have begun to purchase and use electronic health records (“EHR”) systems for their private practices. Requestor would like to integrate its System with individual information systems maintained by the Affiliated Physician Practices to promote the secure transfer of patient data between the parties. Integrating the System with each Affiliated Physician Practice requires the custom development of an interface that can extract data from the System and transfer it to the Affiliated Physician Practices’ EHR systems. The Requestor may need to develop several versions of the Physician Practice Interface to accommodate the various EHR systems. The Requestor would limit the functionality of the Physician Practice Interface to the ordering or communicating the results of laboratory tests or procedures furnished by the Requestor.

Under the Proposed Arrangement, the Vendor would develop, and the Requestor would pay the development cost of, a Physician Practice Interface customized to the Affiliated Physician Practice’s existing EHR software. … Physician Practice Interface would be used only to order or communicate the results of tests and procedures furnished by the Requestor and could not be used for any purpose other than the ordering or communicating of the results of tests or procedures furnished by the Requestor.

…

Therefore, we have determined that the Proposed Arrangement does not meet the definition of “compensation arrangement” for purposes of the statute’s prohibition on physician self-referral
…

The National Alliance for Health Information Technology (NAHIT) recently released new definitions of certain healthcare IT terms. This project was completed for the Office of the National Coordinator of Health Information Technology; this office was created by the President on April 27, 2004 to promote the adoption of electronic health records by most Americans by 2014.

Outlined below are the definitions published by NAHIT. These healthcare IT definitions were published in the report entitled Defining Key Health Information Technology Terms (PDF).

• Electronic Medical Record: An electronic record of health-related information on an individual that can be created, gathered, managed, and consulted by authorized clinicians and staff within one healthcare organization.
• Electronic Health Record: An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be created, managed, and consulted by authorized clinicians and staff across more than one healthcare organization.
• Personal Health Record: An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared, and controlled by the individual.
• Health Information Exchange: The electronic movement of health-related information among organizations according to nationally recognized standards.
• Health Information Organization: An organization that oversees and governs the exchange of health-related information among organizations according to nationally recognized standards.
• Regional Health Information Organization: A health information organization that brings together health care stakeholders within a defined geographic area and governs health information exchange among them for the purpose of improving health and care in that community.

The greatest understatement in the report is: “Interoperability is the common thread running through health IT terms. Interoperability is the essential factor in building the infrastructure to create, transmit, store and manage health-related information.”

For more definitions, check out our healthcare interoperability glossary.

A recent Radinformatics article entitled CIO at the Table highlights the fact that most radiology practices have not welcomed their CIOs to sit at the executive committee table. Nevertheless, research indicates that having the CIO at the management table will facilitate the practice’s growth more effectively.

Creating a competitive advantage for your radiology practice is critical in today’s market. Healthcare IT is a critical strategic element that can automate, streamline, enable, etc. radiology workflow. Having the CIO present at the business level can only help your radiology practice meet the growth and operational goals.

Many of the radiology practices we work with have a CIO who has a strong involvement in the operational discussions, and they have produced impressive results. The results can include improved turn around times (TAT), improved billing cycle times, or other elements of the radiology workflow.

The Radinformaticsarticle highlights some important insights about radiology CIOs, including the valuable role they can play and the skills they can bring to the management table.