Underlying Standards that Support Population Health Improvement

Laura Bright, Johanna Goderre, Laura Bright, Johanna Goderre

• Publisher: HIMSS Publishing
• Year: 2017
• ISBN:
  9781351649261
• Edition: 1
• Topic: Medicina
• Subtopic: Sanità, amministrazione e assistenza pubblica

This book highlights success stories and challenges to implementing health IT standards. The narrative of each chapter demonstrates how standards further interoperable health data exchange, especially in the service of advancing tools to monitor population health. These are critical stories that demonstrate to an international community of health and IT experts how to bring the right stakeholders together and bridge classic divides between software architects and clinical end users, health system decision-makers and standard authors.

Chapter 1

Introduction: Standards and Health IT

Tone Southerland

Contents

Standards and Health IT

What Is a Standard Anyway?

Software Engineering: From There to Here

Methodologies, Philosophies, and Complexity

Business Analysts Are the Secret Ingredient to Product Success

Emerging Technical Solutions

APIs and Optionality

Intersection of Software, Health IT, and Standards

Policy, Payers, and Medical Records

What’s Next?

Standards and Health IT

What Is a Standard Anyway?

According to the International Organization for Standardization (ISO), “A standard is a document that provides requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes and services are fit for their purpose.” However, this is not exactly what standardization has always meant; it has differed in form depending on setting and purpose. Standardization dates back to the beginning of time, being key in forming civilizations, allowing various nations and peoples to converge on approaches to farming, military strategies, roads, currencies, measurements, public health, and other areas in the interest of their survival.^* Standardization was not optional if these civilizations were to not only survive but ultimately thrive and grow in wealth, knowledge, and influence.

While standards can be traced back several thousand years to developments such as currency and road building, it was not until the Industrial Revolution, which arguably started in the 1770s and ran into the 1830s, that the use of standards began to increase in a significant way. This was a major turning point in history for improving the lives of masses of people all across the world. It was also a key initiator of what we understand today as formal standardization. Although standardization certainly existed across all areas of life prior to this time, it began to take on a more formal approach during this era out of the necessity of managing the growth of various industries across the globe. Industries such as rail and steel and those that were driven by the development of the steam engine created new opportunities not only within various countries but also across international borders. When quality materials could not be obtained locally, they would be sourced from another country, oftentimes resulting in much higher costs that would be passed down to consumers. This problem encouraged producers to find ways to lower their prices, and these producers found that by instituting agreements between buyers and sellers of various materials that required the materials to be produced to a certain specification, this ultimately resulted in higher quality material for a better price. These benefits could be passed along to their customers, resulting in a greater volume of sales at significantly lower prices.^†

Specific to the American experience was the case of rail manufacturing, where higher quality rail could be acquired from England; however, it was also substantially more expensive. Purchasers of American-made rail would create very specific work orders for those producing the rails in England to ensure the product they received was of high enough quality. Testing tools were even developed to ensure the quality of these rails. These testing tools were custom designed for specific situations and for specific versions of the materials being produced; each end product was put through unique testing. Modern-day testing tools, however, are designed to test many different products looking to achieve conformance or certification in a specific market or industry space.

The development and use of railway testing tools led to new understandings about the properties of the metals being used in the rails. Eventually, this led to the realization that the data collected from testing could feed into the creation of standards, resulting in a better situation for everyone involved. The result of these efforts was the creation of the American Society for Testing and Materials (ASTM) in 1898, and as they say, the rest is history.^* Fast-forward more than 100 years and one will find that ASTM, in conjunction with Health Level Seven International (HL7), created the “Continuity of Care Document” (CCD)^† implementation guide, which has become the backbone of content standardization in the medical record space. This signifies the ongoing development of new standards over time in order to continue to meet consumer needs for higher quality products at reasonable costs.

Businesses will always have a pressing need for their own standards that solve immediate problems related to ensuring quality products; however, this approach does not support standardization across entire industries to provide more choices to consumers and business partners. Standards are created either intentionally or unintentionally. That is, they are created for a specific purpose by an interested society that could be a government, a standards development organization (SDO), or some other group; or they are created without intention as a result of market forces providing the impetus for the broad success of a particular way of accomplishing something.^‡ Within the intentional realm of creating standards we see, in the context of this text, that there are a couple of ways that this can be accomplished: (1) a government can implement a regulation and require significant numbers of businesses to comply, or (2) a volunteer-led society or consortium can be created requiring the buy-in of enough industry stakeholders to drive forward the creation of the standard. Either approach has the same end in mind: to have the majority, if not all, of the stakeholders in a particular society converge around following the same rules for creating products and services. While the latter is typically a better approach, as it is driven by market needs and not government mandates, the two approaches are often leveraged together in the interest of more efficiently and effectively driving forward market changes while minimizing production costs.

Community-led initiatives were created as a result of businesses realizing the value of standard approaches to some particular business activity. Two organizations would create an agreement between their companies that supported some mutual business interest. This would be expanded to include other organizations, and as a result, a community-based standard would be created. Many of these initial standards were created merely as by-products of business activities, not as intentional standards development activities. As time moved on, standards were scaled up and across industries when they made the work of some activity more efficient and the end result was of higher quality. The collaboration across so many organizations eventually led to a multi-stakeholder environment where many organizations came together to influence the standards for both the good of the industry as well as for specific practices that the participating organizations may have previously invested in developing.

One example of a joint approach involving multiple stakeholders in recent years is the creation of the Nationwide Health Information Network (NHIN) in the United States. This initiative was initially only available to participants that received their funding through US federal government grants. Later, the program evolved to include vendors operating outside of the public-funding realm, resulting in a boom in the number of participants. Today, this is known as the Sequoia Project eHealth Exchange Participant Testing Program. The Sequoia Project itself is governed by a coordinating committee consisting of representatives from many different organizations. The standards this program utilizes are published primarily out of Integrating the Healthcare Enterprise (IHE) and HL7. In addition, both IHE and HL7 are multi-stakeholder organizations in their own right, representing a very broad swath of the healthcare and information technology–based companies across the world.^*

How is this history of standardization and the healthcare domain relevant to the role of a software architect in healthcare? Understanding the domain in which a software developer operates is very much needed to write software that is effective for end users. If one does not comprehend the basics of the field in which they need to operate, then they will not be able to understand the experience from the users’ perspective, and thus will be likely to build a solution that might appear great in design but will perform poorly in actual use. The concept of domain-driven design was first introduced in 2003 by Eric Evans in his book of the same title, and Evans directly addresses this challenge by exploring the concept of creating models in software based specifically on use cases found within the domain in which they operate. Most, if not all, standards development organizations begin their work by identifying and developing use cases that describe specific steps taken within a scenario or set of scenarios that a customer or industry is focused on. These use cases feed into functional requirements that in turn drive the technical requirements, the sum of all of these parts resulting in the creation of the standard specification itself. Understanding that the world of health information technology (health IT) is driven strongly by formal standards as well as by the market is key to being successful in this space. By studying not only the standards themselves but also peeling back the proverbial onion to better understand the processes used to develop the standards provides for a great deal more insight into why certain decisions are made in health IT standards. This in turn provides software architects with the necessary insight to drive their designs to a place of success for their end users.

Software Engineering: From There to Here

The concept of machines doing physical work in place of humans dates back thousands of years; however, the concept of machines doing mental work of the same dates back only a few hundred years, beginning with Charles Babbage and Ada Lovelace, leading up to and beyond the invention of digital computers in the Alan Turing and John Atanasoff era. In order to expand the opportunities for digital computers to deliver on the promises of their ancestors, a new paradigm was needed to provide the opportunity for computers to scale to meet societal needs. This paradigm arrived in the form of computer programs that are built from developing software. The domain in which software is created is known as software engineering. According to Merriam-Webster, software engineering is defined as “a branch of computer science that deals with the design, implementation, and maintenance of complex computer programs.”^* The Institute of Electrical and Electronics Engineers (IEEE), the main society for engineers, refines this definition of software engineering to “the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.”^* Regardless of which definition one might align more closely with, it is well known that the discipline of software engineering is critical to the current and future success of most, if not all, business domains.

As advancements in software were made, initially with the creation of languages such as Fortran, COBOL, and LISP in the 1950s, and then later with the development of parallel processing technologies allowing for software programs to be written and executed in more efficient ways, there became a need to manage the sheer volume of code that was being written by programmers. Solutions to address these problems arose as software programming paradigms and software development methodologies. Paradigms addressed the problem from the perspective of how the code was written (e.g., object oriented, aspect oriented, procedural), whereas methodologies (e.g., Waterfall, Agile, Rational Unified Process) addressed the problem from the perspective of how the code was managed throughout the development life cycle. Similar to the market’s need to standardize across many domains, the field of software engineering also had this same need, and it was addressed through the creation of these programming paradigms and software development methodologies. In both of these areas, many standards have been and continue to be published to provide value to the citizens of the software engineering universe.

While software development methodologies will go a long way to satisfy the needs of individual software vendors internally, they do not address the larger challenge of standardization across the many different vendor products on the market today. Thus, further guidance in the implementation of such software programs is quite important in regard to attaining widespread use of these software applications in the healthcare domain. This ensures that such systems can interact in ways that are reasonably attainable by both the vendors and end users alike.

Methodologies, Philosophies, and Complexity

The IT field continues to struggle with keeping projects on time, under budget, and meeting end-use...