Hacking Healthcare

Reading notes

Chp 1. Introduction

• “When you’ve seen one medical practice, you’ve seen one medical practice.”

Chp 2. An Anatomy of Medical Practice

• There is an important distinction between inpatient and outpatient terms. Inpatient facilities we define as those that treat patients primarily in 24-hour cycles or fractions therefor. Outpatient facilities we define as treating patients primarily in distinct visits, which could be only a few minutes or could run most of a day.
• Visit or encounters are outpatient terminology

Outpatient	Inpatient
Interaction with patient is episodic Refer to intake of patient as visits or encounters Refer to the location as exam rooms.	Treat patient continuously in small increments of time regularly running over several 24-hour cycles Refer to intake of patient as admission or admits Refer to the location as beds or number of beds (medium = 80 bed, large = 250 bed)
Patients reach outpatient facility in two fundamental ways:  by contacting hospital or by referral by another doctor.	Patients reach inpatient facility in four possible ways: patient comes with acute condition or a trauma and admitted in ER;  patient has received a diagnosis from an outpatient facility that required more investigation or a complex treatment or surgery; patient has a complex or chronic condition that he self-identified as being best handled by an inpatient facility, or patient is choosing to have an elective procedure performed that can only be done on an inpatient basis
Centered around transactional visits or encounters with the patient. Outpatient facilities depend more on partnerships and referrals to outside parties.	Centred around small and continuous increments of time. Inpatient care typically operates on a larger scale, with many services and types of care contained within a single facility’s walls

• Elective procedure: a surgery that is not trauma related, or is something that could be delayed without adverse medical consequence, such as hip replacement.
• Trauma: patients facing imminent risk of severe injury or death, known as morbidity and mortality. Example: car accident patient who has internal bleeding. The patient is likely to die quickly and the longer wait the more the odds for survival decrease.
• Acute case: Patients who are facing a serious or potentially life-threatening condition but who might have some amount of time for their care to be coordinated. Example: someone who has suffered a heart attack. The patient might be kept reasonably healthy while in hospital but would be at severe risk for further disability or death if he tried to return to normal life without treatment. For reasons of cost control and improved outcomes, the patient is typically scheduled for treatment within days rather than on an emergency basis.
• Acute and trauma care present the most challenging environment and bring a weighty importance to the notion of a mission-critical system. Failure or a degradation in performance of such a system can result in the injury or death of a patient in a very direct way not common in most other IT. It is absolutely imperative that the worst case scenarios be accounted for, including power loss, network failures and many other events with suitable alternative workflows. California has legislation that requires specific steps to mitigate the risks to patients in those scenarios.
• Triage: the first course of action in emergency care to determine the relative priority of patients. STAT=immediately. One of the deceptively complex areas for managing triage involves imaging. Most hospitals have a resource constraint when it comes to MRI, CT scans. The machines are typically used in diagnosis rather than treatment, scheduling them is a very complicated endeavor. A patient might have been in an auto accident, appear with only minor injuries, but need an MRI to make a determination about a head injury.
• Two motivations that brought about meaningful use: when vital statistics (height, weight, pulse, respiration, pulse oximetry, etc)  are performed on a large scale, it can reduce costs in the system as a whole and increase positive outcomes for patients.
• Practice management system – specifically for billing, sometimes as a component of HER
• PACU – post anesthesia care unit – immediately following the completion of a surgery, a stable patient will be moved to PACU, which is responsible for seeing that the patient is able to come off life support, administering pain management medications as well as prophylactic measures and monitoring for complications.
• At each step of the way of all the activities, supplies, and events occurring with the patient are documented in several forms that inolve paperwork, dictation, and in some cases direct computer entry. Those records wend their way to the billing department for disposition into claims. Those claims represent units of time, typically in 15-minute increments as well as individual line items for each unit of drug, unit of supply and unit of personnel involved in the care.
• Hospitals differ from outpatient facilities in that typically contain both an on-premises pharmacy and an on-premises lab.

Chp 3. Medical Billing

• CMS1500/HCFA1500 outpatient, CMS1450/UB-04 inpatient
• Eligibility – determination about the patient’s ability to pay for the services to be received.
• Meaningful use guidelines require a health facility to have electronic eligibility verification available, but it does not necessarily have to be used.
• Fee schedule – each facility assigns a distinct price to a specific code from the CPT or HCPCS list. That table of prices or fees is commonly referred to as fee schedule
• superbill – to help organize the code selection process, facilities compile a list of their most commonly employed procedure and diagnosis codes into a document or screen commonly called a superbill.
• The easiest place to surrender money in a medical workflow is to lose track of services, supplies and treatments that were provided.
• Two cottage industries have developed within the system to facilitate medical billing: billing services and clearinghouses
• A billing service is really an outsourced billing department that receives either the paper or the electronic data about interactions and performs the billing activities on behalf of the facility. Billing services most commonly take a percentage of claim revenue recovered as payment for services. Billing service are seeing declines in business as providers install EHRs and do more electronic claims processing from start to finish.
• Clearinghouses act a as a go-between from the provider’s billing system to the payer’s electronic claims systems. The clearinghouses have experience addressing the more common problems that payers might introduce. One other very popular service many clearinghouses provide is called combined ERA. clearinghouses typically charge a flat monthly fee per provider or a flat fee for each claim they transmit.
• On the claims, for each procedure code, the biller constructs a claim line that consists of, at a minimum, the procedure code, one or more justifying diagnosis codes, and the billed amount based on the facility’s fee schedule.

For each individual procedure, one or more diagnosis codes must be used to justify the procedure, taking into account the order of the diagnoses. The first listed diagnosis is considereed the primary justification, with the additional ones considered supplementary.

• Adjudication is the payer’s process for resolving a claim and – if it is deemed valid- determining a payment. Usually, facilities get paid much less than the face value of the claims.
• Electronic claims generally pass through several specific adjudication steps: 1. the format of the claim is validated. 2. payer’s system evaluates the enclosed demographic, policy and coding information. It is routine for claims to be denied at this point for very minor problems, including subtle mismatches of name, address, and policy information.  3. should a claim successfully complete validation, it is then reviewed on clinical and contractual grounds. 4. payments are made on a procedure code by procedure code basis. the collective feedback on a particular claim is called an explanation of benefits (EOB), or electronic remittance advice (ERA).
• In summary, the overwhelming complexity of medical billing lies in:
  • The concept of “other people’s money” and the hurdles that this introduces
  • The inability to make broad generalization because of the diversity of scenarios
  • The magnitude of work it takes to get any payment at all in healthcare versus other industries

Chp 4. The bandwidth of paper

• Paperwork is a token in clinical workflow. Consider the record without considering the workflow is a simple mistake that is easy for technologist to repeatedly make. Often, a paper form will have been designed and cemented in the worflow so long ago  that no current employee can remember why the form was designed in a particular way.
• There is no such thing as a typical healthcare workflow.
• The primary benefit of EHR systems is that they coordinate care within a healthcare organization. This is why EHR adoption has been so strongly correlated with the size of a clinical organization. The more an organization needs to communicate with itself about a given patient, the greater the benefit of an EHR system. Conversely, single-clinician practices get the least benefit from computerization.
• The first thing that a computer technologist must free themselves is the notion that computers are the “solution” to information flow in a clinical environment. If computer specialists do not understand everything that a paper process is doing, or fail to respect the ways in which a paper-based information system handles something well, then they will appear arrogant to the clinical staff, who understand perfectly how effective the paper forms can be. When you introduce a system that makes a process that used to take 30 seconds take 10 minutes, then your solution will instantly be met with derision by clinical staff who already overworked.
• Clinical staff, especially nurses, are well-practiced in silent rebellion against unreasonable directions by a multitude of “pointy-haired” bosses, especially when those directions interfere with their care of patients. Countless deployments of healthcare IT software have failed because of this type of rebellion. This problem is so prevalent that you should assume healthcare staff have always reverted back to a paper process, until random spot checks have proved otherwise for months.
• The first step in combating user abandonment is to be realistic and humble about the benefits of any health IT system in comparison to a paper system. This cannot happen without fully respecting how really brilliant paper forms can be in healthcare workflow.  Being arrogent is the first rookie mistake in deploying healthcare IT software. The second is to attempt to replicate patient chart in software. Sadly, almost all early attempts to computerize clinical worflows began life as an attempts to clone a patient chart in software.
• A technologist should be given a five-minute lecture on any given clinical data point and its role in the clinical workflow. this is the heart of the technologist plus clinician collaboration that has made the most successful clinical software deployment work.

Chp 6, 7, 8. Patient-Facing Software, Human Error, Meaningful use

• The two dominant PHR platforms are Microsoft HealthVault and Indivo X.
• Best practices to prevent human error
  • Survey and provide training regarding basic computer skills.
  • Study carefully the history of errors, both reported and unreported, that your facility has made
  • Create workflow diagrams that describe the on-the-ground, real-world process for patient workflows
  • Do not use generic training material. Create organizationally specific training programs in coordination with your vendors.
  • Review comprehensively the defaults of your chosen system and whether they present any danger to patients, especially in unusual circumstances
  • Conduct periodic retraining of staff and process audits
  • IT personnel must be told about the seriousness of care-related IT systems versus non-care systems.
• Meaningful use objectives are broken down into two distinct groups for determining stage 1 compliance: a core set of objectives and a menu set. There are outpatient guidelines and inpatient guidelines.

Chp 9. A selective history of HER technology

• Important attempts to computerize healthcare date back slightly earlier than the advent of C and Unix, which explains one of the central differences in health IT: MUMPS. It stands for Massachusetts General Hospital Utility Multi-Programming System. It is typical nerd humor that a programming language sponsored by a hospital was named after a disease. Unlike C and Unix, there was no strong separation between the programming language of MUMPS and the operating system of MUMPS. In fact, originally, MUMPS was a programming language, database and operating system all rolled into one. MUMPS was built by Dr. Octo Barnette in his animal lab and became the foundation of a hospital information system.
• From the beginning, MUMPS was built to be a hierarchical database, rather than the table-based SQL database that most programmers and information managers are familiar with. Until recently, this was something difficult to explain about MUMPS, but now databases with a similar hierarchical structure are on the market. Much of the recent NoSQL movement has been a return to design principles that have been in MUMPS for more than four decades.
• As a fundamental data model, SQL works really well for data that is highly repetitive so that it can be well-modeled using a table. SQL starts to break down when the data structure varies greatly for each individual, which is the norm in healthcare. MUMPS is significantly different from C=based languages. The syntax can be much terser, and it is not whitespace-invariant. This makes a block of MUMPS code look very intimidating to programmers who are not familiar with it- which is everyone. At one time there was several important vendors for MUMPS and the language was commonly used in finance as well as healthcare, but as the financial industry moved away from MUMPS the vendors consolidated. Now there are only two common MUMPS providers; Intersystems. You might have seen Intersystems advertising an object database; they are talking about MUMPS. They call it language M.
• At least three of the most important health IT systems still available are based on MUMPS: MEDITECH, Epic, and VA VistaA. VistaA is feature rich. MEDITECH is the largest proprietary hospital health IT vendor. Epic is regarded as the leading provider of health IT systems for very large hospitals.
• GE employee Keith Boone is a full=time standards geek. He is often found either participating or leading efforts at IHE, for good healthcare interoperability standards.
• Healthcare IT market is fragmented. The largest health IT vendor at the clinic level is Allscripts. By some estimates, Allscripts has 15% of its market. Even that 15% is not the result of organic growth. Today’s Allscripts is the result of a merger between Misys and the original Allscripts.
• To establish a fair market, both the buyer and the seller must have access to the same amount of information. Economists sometimes call this concept information parity. In the market for EHRs, a typical vendor has substantially more information than any potential buyer and this is particularly difficult to remedy.  There are several services that offer to provide insights into the performance of HER. The most famous is KLAS, which bills itself as “Accurate, Honest, and Impartial.” Admittedly, they are hones in being open about receiving about 50% of their income directly from HER vendors. But accepting money from the companies that they evaluate (which is the norm for the HER evaluation companies) is not even the most significant issue with KLAS’s evaluation method. The main problem is subtly tied in with their use of survey tools to have the technical leadership of hospitals and clinics evaluate the results of HER deployments. That method tends to undervalue the impact of the HER on front-line clinicians, and ignores important intangibles such as the financial stability of a given vendor.
• The real problem si that the HER industry is very difficult to evaluate objectively, no matter how honest the evaluator is. One fundamental reason for the limitation on evaluator’s data is the clauses in most agreements between proprietary HER vendors and their customers, stipulating that the customer cannot discuss or criticize the product publicly, or even say how much they paid for it. In many ways, it’s surprising that CIOs and other technical leadership at clinics and hospitals responded to the KLAS survey at all. Most contracts with HER companies serve to ensure that the information parity needed to build a fair market can never reach the market. Indeed, only a small percentage of the information that KLAS gathers is ever publicly released.

Chp 10. Ontologies

• AMA views the CPT ontology as an “intellectual property” asset that it ferociously protects. A health IT vendor (PMI) went up against them in court and lost. Recent legislation supports and extends the CPT monopoly for claims transactions. Specifically, CMS is authorized under HIPAA to dictate what coding standards are used for medical billing. CPT licensing is not a trivial cost. A large hospital system might pay the AMA hundreds of thousands of dollars a year to license CPT codes. Small providers regularly ignore the AMAs licensing requirements and hope to slide under the radar of the AMA’s enforcement. This can backfire drastically. Deployer of health IT systems might be the first person to point out that the practice owes thousands of dollars a year in licensing fees to the AMA. The CPT terminology system is so focused on medical billing it is widely regarded as clinically impoverished. The most significant impoverishment of CPT relates to its interaction with ICD codes.
• ICD is disease ontology. Claims data is composed of CPT procedure codes justified by ICD diagnosis codes. Together the combination of the two ontologies used in medical claims transactions forms a “billing ontology” that only applies to the US.
• CMS has been developing its own additional code set that is used alongside CPT codes to communicate other claim data. This is called HCPCS (Healthcare Common Procedural Coding System). It has three levels. The first level is actually identical to CPT-4, the second level is what are normally thought of as HCPCS and the third level has been retired. For the most part, the levels of HCPCS serve only to confuse; when someone says HCPCS, they normally mean codes that are not included in CPT-4.
• CMS also mandates NDC (National Drug Code) for drug descriptors.
• Maintaining a drug database is thankless, difficult work that requires tremendous patience and attention to detail. Several drug database providers download the drug database from the VA and maintain proprietary drug databases. The leading provider of proprietary drug data is First DataBank, which is owned by the Hearst Corporation, along with other database proiders including Micromedex, MediSpan, Gold Standard Alchemy and Multum. Thankfully, there is a meta-ontology that serves to map the different coding schemes of various drug database providers called RxNorm. RxNorm is maintained by the NLM at the National Institutes of Health. Well-designed HER systems can support multiple drug database source data, and use RxNorm to reconcile differences between them. RxNorm is the first component of the Unified Medical Language System (UMLS) which is a broad meta-ontology that unifies many different ontologies that we will discuss later.
• If there was a winner in the clinical ontology space it would be SNOMED CT – Systematized Nomenclature of Medicine – Clinical Terms. Since the 1960s College of American Pathologist (CAP) had been working on a clinically accurate ontology that could be broadly applied to all sspects of medicine. In 1997 the trademarks and copyright for SNOMED were transferred to a new international body IHTSDO. In 1999 SNOMED was merged with similar efforts from UK Clinical Terms project. The result is SNOMED CT, which is generally regarded as the most complete clinical ontology in any language. SNOMED CT is liberally licensed to any IHTSDO “member country”. Because so many people have free access to it, it has rapidly become the de facto standard for encoding health information in a clinically valid way, and is regarded as the “right” way to populate popular health information exchange formats such as CCR/CCD/CDA.
• LOINC is an ontology of lab result coding that is discussed in Chapter 11.

Chp 11. Interoperability

• Health IT vendors lack motivation to properly support interoperability standards. True interoperability means that it is much simpler for one EHR to replace another, and therefore one EHR vendor to be replaced by another. As it stands, without widespread interoperability, it is almost impossible to migrate from one EHR to another. EHR vendors know this, and have a similarly mixed motivation regarding interoperability. Most EHR vendors claim that they are interoperable because they provide tools to migrate data into their EHR system. Happily, the advent of cheap open source third-party data integration toolkits, such as Mirth Connect have reduced the impact of this problem.
• The best example of a successful HIE in the United States is the Indiana Health Information Exchange. It went through three crisis points:
  • Hospital CIOs argued that ICC competed with individual hospitals’ IT strategies to link to physician offices. General HIE is viewed as competitive with the efforts to affiliate physician to hospitals.
  • Hospital CFOs opposed it because they did not see any significant return on investment for their individual organizations.
  • The HIE had no initial funding, so the Indiana HIE partnered with the Regenstrief Institute for grant funding.
• Not all standards are strong, and some technical standards have long been criticized for a weakness that hampers or eviscerates interoperability. A weak standard means that different implementation of a protocol are so different that they are incompatible. HTML and Ipsec have been historically criticized for this problem. When a standard is weak, different implementations require considerable work to communicate. Sometimes a standard can be so weak that no amount of tweaking can get different implementations to work together. Generally, standards that are more complex are more difficult to implement correctly in different applications. As a result, simpler standards tend to become strong standards faster than complicated ones.
• Most HIE protocols are weak standards, The only way for any standard to become strong is (a) when users make lots of attempts at communication between different implementations of that standard and (b) when this pressure drives progress toward standardization. This cross communication must occur until either the standards are changed into something that can be conformed to, or implementations changed to match the standard. Either way, the only way for this progress to occur is through lots of attempts at communication. Without any motivation to interoperate, this has not yet happened in the healthcare. Meaningful use provides a strong new motivation, and this is now changing. Interoperability workshops are now common among EHR vendors.
• The problem with many early HIE protocols is that their design encourages individual customization over true standardization. This can happen with real languages, too. For instance, researchers have discovered instances of sign language being reinvented or significantly changing among isolated groups of the deaf. Although communication was occurring, enabled by the new language being built, there was no progress toward the standard. Obviously, for any single group, enabling communication is more important than the long-term strengthening of a standard. If any protocol lends itself to building new languages for fast local communication, rather than enforcing standards, there is typically no progression form a weak standard to a strong standard. Modern HIE protocols specifically focused on addressing the underlying tension of enabling both flexible communication and enforcing standards to ensure widespread interoperability.
• As we discuss the strength of protocols, from a practical perspective, we will refer to the perspective of a “third” implementation. Basically, a standard can be considered strong if, after two different implementations of the protocol succeed in configuring communication, a third implementation can then participate with one of the two original implementations without reconfiguration. If things work from the perspective of the third implementation, the protocol is strong. If the third implementation finds itself shut out, the protocol is weak. A protocol is only as strong as the conformance of its most popular implementation. Standards bodies that design protocols cannot really make a protocol strong or weak, only protocol implementers can do this.
• The oldest electronic HIE protocols, being widely adopted in the 1980s, are billing exchange standards based on electronic data interchange (EDI) protocols.
• Another tried and true HIE protocol is HL7. The most substantial problem with HL7 v2.x is its capacity to support local communication at the expense of standardization. A standard’s capacity to build new dialects of itself hinders widespread interoperability. HL7 v2.x has two main mechanisms that lead to a lack of standardization.
  • First, because it is simple to place more data at the end of a given line, implementers often “extend” the standard by simpley placing more data they want at the end of what should be a standard segment. Of course, because this ignores the standards, there is no way that a third implementation can account for this kind of variation.
  • The second de-standardization mechanism is the Z segment. Z segments are segments that are defined by the user. Like all segments, Z segments must begin with a three-letter name. However, HL7 allows that if a name begins with a Z, it can be entirely user defined. Usually, a Z segment is an indication of a workaround that was the result of a historical issue with HL7 v2, or the result of ignorance or laziness on the part of the implementer.
• HL7 is an expansive standard that can now be used to automate the majority of common health information systems communications, at least those that respond well to a message-based approach. For instance, if you want to export a summary of a patient’s record, HL7 v2 cannot really help. A summary of a  patient’s record includes lots of divergent information all bundled together, but an HL7 message speaks to one single clinical data point at a time. HL7 was not always so expansive though. Version 1 was so short lived that it might as well be considered a beta, making early 2.x versions the first reliableHL7 messaging system. At that time, having Z segments was a critical part of ensuring that HL7 could meet unexpected clinical use-cases. Streams of HL7 that continue to use Z segments extensively come with a stiff penalty. Late versions of HL7 2.x carefully support most valid use-cases for system-to-system messaging in health IT. Best practices when setting up new HL7 channels include completely forbidding HL7 Z segments until it is proven that no other predefined segment type can work. This ensures that at least new implementations of HL7 v2 can contribute to a semantically interoperable HIE process. Because Z segments are custom containers, it is not possible to rely on their contents semantically in any kind of formulaic way.
• Upgrading a working stream is rarely worth it, but when streams break, often an upgrade is the only way to restore functionality. Often software upgrades in other parts of a health IT infrastructure will force an upgrade to a new HL7 version.
• Besides billing data, HL7 v2.x traffic is by far the most common form of interoperability. However, HL7 channel requires ongoing maintenance and monitoring. We know of at least one person who was killed because of an interface was down. In this case, the clinician misinterpreted the signal in the EHR UI that the interface was down to mean that no lab result existed. The result did exist and required immediate attention. A young child died as the result of the error. Most HL7 streams rely on a chain of single servers. This makes automated log and uptime monitoring critical to the safe deployment of HL7 streams. Also be aware that the logs from interface engines could often contain HIPAA-covered data, and must be protected accordingly. No HL7 interface engine infrastructure should be considered without a monitoring solution. There have been many reports of immature HL7 products that do not properly support logging and monitoring so this should be part of your acquisition requirements.
• A whole health IT sub-industry exists specifically from larger vendors, has integrated HL7 functionality. Most of the industry exists specifically to solve the problem of repairing, modifying and re-reouting streams of HL7 v2.x data. Software that does this is typically called an integration engine. Fortunately, some excellent HL7 integration engines are available. There are several competent vendors of interface engines including InterfaceWare, and Intersystems with its Ensemble product.
• Developing an HL7 channel is a lot like flying a plane. Just moving around in the air is simple because airplanes are very stable and there is little to run into, but takeoff and landing are very difficult, experience and training matter a lot, andmistakes are costly. For HL7, creating and validating a new stream of HL7 data is very complicated, but once that work is done, maintaining a stream is a much easier, if constant, task. Usually, It is worth the money to hire experienced HL7 consultants, but frequently no money is set aside for non-core health IT projects. If you have more than one internal health IT systems, or you know you need to communicate with organizations in a message-oriented fashion, you need to budge either time or money to solve the problem with an HL7 engine of some kind.
• HL7 v2.x was designed to represent what is happening to a patient right now, and CCR was designed to be a summary of everything that has happened to a patient up till now. Like HL7, CCR can be thought of in terms of messages, but with a very different style. CCR is a really big message saying everything (summary) and HL7 v2 is a series of really small messages that say just what recently happened.
• HITSP announce its exclusive support for HL7 CCD over CCR. Later the final rule of meaningful use changed that. Both are supported.
• HL7 v3 should probably be considered a completely different standard from v2, and really merits a different name, rather than merely a new version number. Version 3 is capable of replicating the message-oriented use case of v2, but it is also capable of far more. In reality, version 3 of HL7 is not one standard at all, but a family of standards that are used for different purposed. CCD and the underlying CDA are part of HL7 v3. The heart of HL7 v3 is the reference implementation model (RIM). The HL7 3 RIM is an information model that generally describes how entities, who play roles can act on other entities over time. If that sounds pie-in-the-sky abstract, it is only because it is. RIM is not actually healthcare-specific, but rather a high-level way of establishing fundamental relationships. RIM is a controversial idea. Some people regard RIM as too abstract and to distant from real life to be useful. Others believe that this super-high-level model is critical for ensuring that very different healthcare standards still share the same underlying notions.
• There are only six basic object types in the RIM model. First are Acts, Roles, and Entities, which can be connected by ActRelationship (between acts), Participation (connections between Entities and Acts, which have Roles), and RoleLink (between roles). The backbone of RIM is simply that everything being modeled is an Entity in a Role that is Participating in an Act. Everything else in RIM is either some kind of extension of or modifier for one of the basic object types.
• IHE attempts not to redefine already working standards, but to specify other, already well-defined standards where appropriate.

Chp 12. HIPAA, Chp 13 open source

• HIPAA coverage and responsibility summary pg 209 – 215
• Open source: ClearHealth, OpenMRS, MirthConnect