legal, social and ethical issues for consideration …lisarnelson.com/files/117948564.pdflegal,...

Lisa R. Nelson

40 Happy Valley Road

Westerly, Rhode Island 02891

[email protected]

Images from www.himss.org

MMI 407 LEGAL, SOCIAL AND ETHICAL ISSUES IN MEDICAL INFORMATICS

NORTHWESTERN UNIVERSITY

PROFESSOR KARIN LINDGREN, ESQ

Legal, Social and Ethical Issues For Consideration

During CDA Implementation Guide Public Comment

Expanding the Vision for CDA Implementation

In Support of HIT Adoption and Meaningful Use

Lisa R. Nelson

March 18, 2011

MMI 409 Biomedical Statistics Northwestern University

i

Contents

Expanding the Vision for CDA Implementation................................................................................................... 1

1 A Vision for CDA Documents that Includes Legal, Ethical and Social Concerns ................................. 1

1.1 Context and Background ............................................................................................................................... 4

1.2 Improvement of Legal Regulation ................................................................................................................. 5

1.2.1 Expected gains from considering legal, ethical and social concerns ..................................................... 5

1.2.2 Negative consequences and risk mitigation strategies, unintended consequences ................................. 6

2 Reaching Beyond Consolidation ........................................................................................................... 8

Expanding the Vision for CDA Implementation................................................................................................... 8

In Support of HIT Adoption and Meaningful Use ................................................................................................ 8

2.1.1 CDA Documents with clear Privacy Roles ............................................................................................ 8

2.1.2 Documents with granular consent control ........................................................................................... 13

2.1.3 Documents that support Meaningful Use and Quality Measures ......................................................... 14

2.1.4 Documents that meet Minimum Necessary Rule data requirements ................................................... 17

2.1.5 Evolution of the governance of technical standards ............................................................................ 19

3 Shifts in Compliance Burden ............................................................................................................... 20

4 Governance Issues ............................................................................................................................. 21

4.1.1 Federal-level governance for efficiency and effectiveness .................................................................. 21

4.1.2 State-level governance for tailored implementation to fit local preferences ........................................ 21

5 Conclusion ........................................................................................................................................... 22

6 Bibliography......................................................................................................................................... 24

7 Glossary .............................................................................................................................................. 29

7.1.1 Legal .................................................................................................................................................... 29

7.1.2 Ethical .................................................................................................................................................. 29

7.1.3 Social ................................................................................................................................................... 29

7.1.4 Privacy ................................................................................................................................................. 29

7.1.5 Security ................................................................................................................................................ 29


ii

7.1.6 Consent ................................................................................................................................................ 29

7.1.7 Health Information Portability and Accountability Act (HIPAA) ....................................................... 30

7.1.8 Protected Health Information (PHI) ..................................................................................................... 30

7.1.9 De-Identification .................................................................................................................................. 31

7.1.10 Patient Identifiers ................................................................................................................................. 32

7.1.11 Minimum Necessary Rule ................................................................................................................... 32

7.1.12 Health Information Technology for Economic and Clinical Health (HITECH Act) ........................... 33

7.1.13 American Recovery and Reinvestment Act (ARRA) .......................................................................... 33

7.1.14 Meaningful Use ................................................................................................................................... 34

7.1.15 Health Language Seven (HL7) ............................................................................................................ 34

7.1.16 The HL7 Clinical Document Architecture Release 2 (CDA R2) ......................................................... 34

7.1.17 Conceptual representation of CDA hierarchy and document form ...................................................... 35

7.1.18 CDA Implementation Guides .............................................................................................................. 35

7.1.19 CDA Consolidation Project ................................................................................................................. 35

7.1.20 The Baby Boomer Generation ............................................................................................................. 36

7.1.21 National Spending on Healthcare ........................................................................................................ 37


MMI 407-Legal, Social, Ethical Issues 1 Lisa R. Nelson

1 A Vision for CDA Documents that Includes Legal,

Ethical and Social Concerns

Why is this

topic

important?

What are CDA documents and why is it relevant to consider issues concerning the technical

specifications for CDA documents in a course focusing on legal, ethical and social issues in

medical informatics?

CDA stands for Clinical Document Architecture. It is one of the primary health information

technology (HIT) standards. The CDA standard specifies how electronic health information is

created and consumed in the delivery of care. A CDA document is comprised of atomic

information units called sections. Sections contain both human-readable narrative text and

corresponding machine-readable elements called entries. The entries encode the section’s

information in a way that supports computer processing. The entries preserve the semantic

meaning of the information in a section. The design of the entries and sections in a CDA

document permit the data being processed by a computer to be verified. The CDA rules

describing the information architecture for sections and entries of a document are recorded in

templates which are named and numbered using an object identifier (OID). The CDA standard

enables a new level of interoperability not previously possible for HIT systems.

The CDA standard, and our vision for it, is at the heart of the Meaningful Use (MU) criteria

established in the HITECH Act of 2009. MU is a two-pronged, phased approach to HIT

adoption. For care providers, MU incents specific levels of HIT capability over three stages

spread over five years. For vendors developing electronic health record (EHR) technology, MU

specifies certification criteria for the technology (EHR). MU specifies the use of CDA

documents for the interchange of health data. An example of language citing the use of CDA

states, “The primary method we proposed would require the eligible physician (EP), eligible

hospital, or critical access hospital (CAH) to log into a Center for Medicaid and Medicare

Services (CMS) designated portal. Once the EP, eligible hospital, or CAH has logged into the

portal, they would be required to submit, through an upload process, data payload based on

specified structures, such as Clinical Data Architecture (CDA), and accompanying templates

produced as output from their certified EHR technology” (Department of HHS, HIT Policy

Committee, Stage 2 Proposed Final Rule, 2011).

Extensive reference to specific requirements for the use of CDA and other derivatives such as

the Continuity of Care Document (CCD) and the HITSP C32 specification, are included in the



Office of the National Coordinator (ONC) Final Rule (Department of HHS, ONC Final Rule,

2010) which specifies MU stage 1 and the proposed final rule for MU Stage 2 (HIT Policy

Committee). As a result of these direct references to named implementation specifications, a

link has been established between the CDA standard and recent legislation within the

American Recovery and Reinvestment Act (ARRA).

The CDA standard is produced by the Health Level Seven (HL7) standards development

organization. It is in its second revision: hence the longer name HL7 CDA R2 is also used.

The HL7 CDA R2 standard is a powerful mechanism with the potential to address present

barriers to HIT adoption created by legal, ethical and social concerns about privacy and

consent for electronic health information. Presently, some of the major push back for HIT

adoption comes from resistance over a lack of capability to address people’s privacy and

security needs. Patient privacy safeguards are woefully missing from initial draft criteria for

Stages 2 and 3 of Meaning Use, according to Deborah Peel, M.D., founder of the Patient

Privacy Rights organization. “Like the criteria for Stage 1, the criteria for Meaningful Use Stage

2 and 3 are missing the key elements Americans expect from electronic system: the ability to

control who can see and use personal health information and the ability to segment information

so they can selectively share information”. According to Peel, “Segmentation is essential to

protect sensitive information, but also is absolutely critical for patient safety, so that erroneous

health information can be kept from disclosure.” Others’ comments have added, “The MU

Stage 2 criteria must enable each individual to selectively share parts of their health information

ONLY with the people they choose and prevent those they do not want to see their data from

having access (with rare exceptions under the law). The public expects their legal and ethical

rights to be built into health IT systems and data exchanges now” (Goedert, 2011, “Patient

Privacy”).

The existence of many different CDA standard implementation guides has caused a

compliance challenge for implementers attempting to meet MU Stage 1 requirements. To

address these issues, the Office of the National Coordinator (ONC) has recently convened a

project called the CDA Consolidation Project within the Standards and Infrastructure

Framework initiative (S&I Framework). A large group of stakeholders within the HIT community

are working to produce a single CDA implementation guide. The process they are going

through is called harmonization. Harmonization produces a “lowest common denominator”

across overlapping standards. The resulting consolidated standard can be used to gain

consensus and establish common ground-rules for a more “standard” standard. This in turn

enables greater interoperability.



Standards harmonization happens under very strict rules about scope. The S&I Framework

project is limited to the existing HL7 CDA R2 standard and the implementation guides selected

for the consolidation project. Many of the guides were produced before privacy and security

legislation was as mature as it is today.

The focus of HIT adoption is changing rapidly. The expanding vision reaches beyond the

hospital bedside to include physicians’ offices and consumers’ homes. However, simply

consolidating current standards doesn’t produce a standard that addresses these newer and

more futuristic needs. Building consensus is an important first step. It is a step that is needed to

take the first step and publish a proposal which can begin the process of soliciting public

comment. During the public comment period, the scope of a participant’s vision is not limited to

what has been established before. New ideas and new insight for the use of the CDA standard

can be put forth. After the consolidated CDA implementation guide is published, there will be a

window of opportunity to overlay a more updated view of current implementation needs on the

standard. It will be time to stretch the technical mechanisms available in CDA R2 and reach for

improvement of critically needed implementation issues. It will be a time when unmet

expectations, like better support for privacy and consent controls, can be creatively addressed.

If ignored, privacy and consent inadequacies may jeopardize HIT adoption and thwart progress

toward national goals for improved health outcomes to result from massive national investment.

Why is it

timely?

Management guru Stephen Covey, in his book titled The Seven Habits of Highly Effective

People, provides sound principles that ring true. “Start with the end in mind” is one of his

tenets. Clearly, a vision of the future is fundamental to determining the correct next steps. In

fact, it is impossible to rationally discern what next steps should be without a clear

understanding of the future goal.

The HIT industry is presently in the process of coming to a consensus. The multiple CDA

specifications which were confounding adoption and implementation will be consolidated into

one. Public comment on that work is scheduled for April, 2011. The opportunity exists to input

additional ideas into the new “implementation baseline” during this Public comment period.

Evolution of CDA R2 to a new CDA R3 standard is also on the radar. New thinking on the

technical infrastructure architecture needed to address the full spectrum of evolving health

care, legal, ethical and social issues will help to inform the public comment activity.



Why is it

valuable?

In 2009, ten years after the Institute of Medicine (IOM) released the epoch report exposing

challenges facing the US healthcare system titled, “To Err Is Human”, the political agenda

finally shifted. Healthcare challenges discussed in academia and government think tanks over

the prior decade finally became a national priority.

Solutions that address the changes in care made possible by new delivery models like

Accountable Care and Patient-Centered Medical Home, and the National Quality Measure

efforts that support evidence based medicine, are not possible without advances in HIT.

Present paper-based processes could not feasibly accomplish the requirements of these

envisioned changes.

National Health IT Coordinator Dr. David Blumenthal is pushing for progress saying, “even

though there are issues of timing, issues of electronic exchange that may or may not be there,

and all kinds of practical questions, the system will catch up with us eventually, and the work

done here will be valuable when the system catches us.” Mary Mosquera, a writer for Gov

Health IT, included Blumenthal’s remarks to support her assertion that the meaningful use

framework will become the “raw material” for the work of private and public providers and

payers whose goal is to improve quality through systematic change (Mosquera, 2011).

1.1 Context and Background

How would

the elements

of this

discussion be

visualized in

time?

Since the 1980’s, computer technology has been changing the way people work and live. The

healthcare industry’s adoption of 21st century technology seems to have lagged behind other

industries. The maturity, complexity and sensitivity of the medical profession, makes change

more challenging and technology adoption more difficult. Progress is however evident. The

growth of the Health Information Management Systems Symposium (HIMSS) convention

provides an interesting measure of the growth in the HIT industry over the past 50 years.

HIMSS was started in 1961 and had 47 charter members on its roster the first year. In 2011,

the organization has over 30,000 members.

Although electronic health records are coming closer to being a reality, shortcomings in the

area of privacy and consent are beginning to impede further progress. Implementation

questions are being raised about how the technology will be used to achieve stated goals.

While MU Stage 1 resolved many of the debates over which standard would prevail in different

areas, the questions have shifted to focus on implementation issues. Public comments on

proposed goals for MU Stage 2 indicate that current standards may not be adequate to

address, implement and sustain the envisioned leap in progress. The industry is struggling to



keep up with ambitious expectations set by those leading the transformation.

In a recent survey from the Certification commission for Health Information Technology, 468

respondents found proposed Stage 2 MU criteria too aggressive. More than half of surveyed

providers and 40 percent of vendors said syndromic surveillance was not ready to be a core

measure in Stage 2. Survey respondents also voiced substantial concern about initial proposed

criteria for medication reconciliation, patient access to their health information within four days,

submission of immunization data, exchanging key clinical information, use of clinical decision

support, submission of reportable lab results and, drug/drug or drug/allergy checks (Goedert,

2011, “CCHIT Survey”).

At times like this, creative thinking is needed. Novel approaches that push us “outside of the

box” must be considered or the needed advances may not be attained. What can we do to

meet the privacy and consent issues embodied in HIPAA? How can we address the quality,

safety and efficiency demands embodied in the HITECH Act and Meaningful Use?

With a commitment to continually evolve the CDA standard (Spronk, 2011) and additional

insight gained during harmonization analysis (S&I Framework, 2011), new possibilities are

beginning to be revealed. This proposal presents several novel ideas for consideration during

the public comment period on the proposed CDA implementation guide. Hopefully it will spur

discussion and generate breakthroughs that take us beyond harmonization to adopt CDA

implementation guidelines that support greater possibilities for the future. It also may serve to

influence thinking that contributes to the evolution of the CDA standard.

1.2 Improvement of Legal Regulation

1.2.1 Expected gains from considering legal, ethical and social concerns

In what ways

would the

envisioned

changes

improve our

legal

regulations?

The changes outlined in this proposal are aimed at improving our legal and regulatory position.

Considering additional legal, ethical and social issues creates a future vision that can align

work being done to consolidated the CDA implementation guides called out for Meaningful Use

Stage 1 in the Standards Final Rule.

The proposal presents ways to address needed technical mechanisms to support granular,

consumer-controlled consent controls. Support for patient consent, or a lack there of, which

continues to create resistance for HIT adoption. The ONC has also received feedback

regarding implementation challenges associated with existing implementation guides for the



specified CDA standards called out by Meaningful Use requirements.

The proposal aims to reduce resistance to the adoption of electronic health records by aligning

technical standards with privacy protection legislation. It also identifies a serious shortcoming in

the current implementation approach which prevents the data interoperability assumed to be

attainable with the use of CDA R2 standard.

Most importantly, the ideas contained in this proposal may help leverage the CDA

implementation guide creation efforts to achieve more than just consolidation of prior thinking.

Meaningful use of health information made possible by adopting HIT depends on

implementation capabilities that support the full range of issues affecting healthcare delivery.

1.2.2 Negative consequences and risk mitigation strategies, unintended

consequences

What are

possible

negative

consequences

and how could

they be

mitigated?

Improving the “implementability” of the CDA standard will help maximize the benefits of HIT

interoperability and adoption. Addressing the privacy and consent needs will help minimize the

regret associated with changing privacy and consent mechanisms through the use of

information technology. If these are the benefits of improved technological capabilities, what

are the costs which also need to be considered?

While HIT adoption makes healthcare delivery safer and more efficient and effective, it will

likely affect demands placed on the legal system and the consumer. Our legal system will need

to evolve its ability to govern and regulate the use of the technology. People – a.k.a

patients/consumers – will need new knowledge and skills to keep up with the changes

technology creates for their health and care. Negative consequences could ensue from not

recognizing these interdependencies. To successfully absorb these technological advances,

we must simultaneously develop new capabilities within the legal system and across our

population as a whole.

New programs like the Beacon Communities and Regional Extension Centers, present an

opportunity. They are national experiments to test the affect of HIT investment, regulatory

practices and consumer education on positive health outcomes. Lessons learned in these

areas will benefit larger-scale roll-out of HIT adoption initiatives.

To date, little progress has been made to implement technical mechanisms to fulfill the full

spectrum of health information privacy and consent needs. The development of technical

specifications to facilitate data interoperability has faced complicated technical challenges



which overshadowed these other legal and societal issues. Adding them, at this point in time,

will create new requirements and could have the unintended consequence of slowing progress

on the adoption of HIT. However, not addressing these issues could have a worse affect. It

could cause the natural barrier created by unmet legal, ethical and social issues, to deter

adoption.

Figure 1.

Historical view

of the

development of

the HL7 CDA

R2 Standard

and the CDA

Implementation

Guides.

Image from HL7 CDA R2 Training presentation delivered by Keith Boone, Chicago, IL, March 16, 2011.

A historical perspective may be needed to create a consolidated CDA IG that can move the HIT

community to consensus on the use of the CDA standard, but vision is needed push for greater

possibilities.



2 Reaching Beyond Consolidation

Expanding the Vision for CDA Implementation

In Support of HIT Adoption and Meaningful Use

2.1.1 CDA Documents with clear Privacy Roles

How do the

entity roles

used by the

CDA standard

relate to roles

defined in

privacy

legislation?

The HIPAA Privacy Rule defines categories for various types of healthcare providers and their

supporting vendors. Different privacy and security expectations are then defined for the

different types of entities, namely Covered Entities (CEs) and Business Associates (BAs).

Other legal arrangements such as Power of Healthcare Attorney, Legal Guardian or

relationships such as parent of a minor may also affect Privacy Rules relative to the care of a

patient. The Patient is also a participant in terms of being an entity that has legal rights and

responsibilities.

The CDA R2 architecture specifies a set of entities to record the various parties involved in the

act of delivering health care. Each entity has an identity. They are established in the header of

a CDA document and referenced within the body of the document. Within the body, an entity

may be the subject of the care or be involved in delivering the care. Together with human

readability, wholeness and persistence, context, stewardship and authentication make up the

six key properties of the CDA R2 architecture (Benson, 2010).

A mapping between the ontology of entities in the regulatory realm and the ontology of entities

in the CDA standard does not exist. The absence of this mapping makes it less clear how

privacy regulations apply when information is exchanged as CDA documents.

Proposal

details

The consolidated CDA Implementation guide should include a table linking the roles in privacy

and security regulations with each CDA R2 role. Creating the table would be an opportunity to

clarify within the HIT community how HIPAA roles relate to roles used within a CDA document.

A consensus could be formed around any issues requiring interpretation so that a shared and

common view could be attained and the legal implications would be more transparent.



Figure 2.

CDA R2 Roles mapped to Privacy Roles

CDA Entities

with Identity

HL7 CDA R2 Specification Definition (HL7,

2005, “CDA R2”).

HIPAA Entity (CE, BA, Self, or

another relevant role). Issues to be

needing to be clarified

recordTarget The recordTarget represents the medical record

that this document belongs to.

A clinical document typically has exactly one

recordTarget participant. In the uncommon case

where a clinical document (such as a group

encounter note) is placed into more than one

patient chart, more than one recordTarget

participants can be stated.

The recordTarget(s) of a document are stated in

the header and propagate to nested content,

where they cannot be overridden

The Patient. Based on the patient’s age

and presence or not of other roles, such

as a legal guardian, certain privacy

rights and rights to access the

information exist by law. State laws may

override Federal laws if they are more

stringent.

If a CDA Document were to have more

than one record.target, whose consent

controls would govern the release of the

information or access to the

information?

Author Represents the humans and/or machines that

authored the document.

Most likely, this is a Covered Entity

dataEnterer Represents the participant who has transformed

a dictated note into text.

This could be Covered Entity or a

Business Associate.

Informant An informant (or source of information) is a

person that provides relevant information, such

as the parent of a comatose patient who

describes the patient's behavior prior to the

onset of coma.

If an informants’ identity is included in

the record, what laws exist to protect

their privacy? Does their personally

identifying information have to be

redacted for the document to be de-

identified? Or, does just the personally

identifiable information of the record

target need to removed?



custodian Represents the organization that is in charge of

maintaining the document. The custodian is the

steward that is entrusted with the care of the

document. Every CDA document has exactly

one custodian. The custodian participation

satisfies the CDA definition of Steward. Because

CDA is an exchange standard and may not

represent the original form of the authenticated

document, the custodian represents the steward

of the original source document.

Is this a Covered Entity?

Information

Recipient

Represents a recipient who should receive a

copy of the document. NOTE: The information

recipient is an entity to whom a copy of a

document is directed, at the time of document

authorship. It is not the same as the cumulative

set of persons to whom the document has

subsequently been disclosed, over the life-time

of the patient. Such a disclosure list would not be

contained within the document, and it is outside

the scope of CDA. Where a person is the

intended recipient (IntendedRecipient class), the

playing entity is a person (Person class),

optionally scoped by an organization

(Organization class). Where the intended

recipient is an organization, the

IntendedRecipient.classCode is valued with

"ASSIGNED", and the recipient is reflected by

the presence of a scoping Organization, without

a playing entity. Where a health chart is the

intended recipient, the

IntendedRecipient.classCode is valued with

"HLTHCHRT" (health chart). In this case there is

no playing entity, and an optional scoping

organization (Organization class).

This would require some discussion. It

could be a CE, BA, or some other

person that the patient authorized to

receive a copy of the information. What

privacy responsibilities does the

information recipient have in the various

different cases?



legalAuthenticator Represents a participant who has legally

authenticated the document. The CDA is a

standard that specifies the structure of

exchanged clinical documents. In the case

where a local document is transformed into a

CDA document for exchange, authentication

occurs on the local document, and that fact is

reflected in the exchanged CDA document. A

CDA document can reflect the unauthenticated,

authenticated, or legally authenticated state. The

unauthenticated state exists when no

authentication information has been recorded

(i.e., it is the absence of being either

authenticated or legally authenticated). While

electronic signatures are not captured in a CDA

document, both authentication and legal

authentication require that a document has been

signed manually or electronically by the

responsible individual. A legalAuthenticator has

a required legalAuthenticator.time indicating the

time of authentication, and a required

legalAuthenticator.signatureCode, indicating that

a signature has been obtained and is on file.

Covered Entity.

authenticator This is the person or system responsible for

authenticating that the Entries correspond to

(balance against) the information in the Narrative

text.

If this is a system, what could the

Business Associate be held responsible

for? Would the Covered Entity who

accepted the system take responsibility

for its use and failures? If an application

was authenticating entries that didn’t

actually semantically match the

associated narrative text, who would be

at fault? What type of damages would

be appropriate?

Participant The Participant represents someone directly

associated with the encounter (e.g. by initiating,

Could be a Covered Entity. What if a

wife leaks private information about her



terminating, or overseeing care) or others

associated with the patient such as a parent or a

child or other family member.

husband’s medical condition? Or a

husband about a wife? What role do

family members play in preserving

privacy and responsibilities to they

have?

Performer The performer participant represents clinicians

who actually and principally carry out the

ServiceEvent. Performer.time can be used to

specify the time during which the performer is

involved in the activity. Performer.functionCode

can be used to specify additional detail about the

function of the performer (e.g. scrub nurse, third

assistant). Its value set is drawn from the

ParticipationFunction vocabulary domain, and

has a CWE coding strength.

How many performers need to be

listed? All of them, or just some? Which

ones? Most likely these are all Covered

Entities. What if a vendor was in the

room monitoring the use of the system,

would they need to be listed somewhere

in the document?

Are there any roles expressed within

HIPAA that have privacy responsibilities

which are not modeled in CDA R2?

Benefit

Aligning the roles would ensure that CDA implementations aligned with the legal framework

governing creation of and access to patient health information. Clear associations to the law

enable better stewardship and better detection of privacy violations. Automated

conformance checking would reduce the “cost of conformance” for HIPAA rules, which in

turn would improve the return on investment for utilizing the CDA standard.

Challenging Use

Cases

In the case of documenting birth of a child, of multiple children or the death of a fetus, how

many CDA Documents are produced? One for each person; Mother and each Child, where

each is a record Target of their own document? Or would there be just one document for the

mother with all children as participants. When the procedure is an abortion, at what point in

time does the fetus get represented as an entity. If the fetus is represented as an entity

(implying it has an identity), what legal ramifications does that technical implementation

legal issues surrounding abortion?



In the case of documenting a Group Therapy session, how many CDA’s are produced?

Which participant is the recordTarget? Whose consent controls apply to the information?

2.1.2 Documents with granular consent control

Issue There exists a need to provide granular consent and privacy controls for electronic health

information. The need arises from social expectations and ethical considerations. Also,

different legal treatment is sometimes specified for mental health data or sexually

transmitted disease (Lindgren, 2011). New Health Information Exchange (HIE) opt-in and

opt-out rules may also stipulate exceptions for certain types of information. To date, the MU

specifications do not address this need. Current CDA implementation guides do not provide

guidance on technical mechanisms to provide the needed granular consent functionality.

How will conformance and compliance be possible? What mechanisms will address these

needs?

Detailed Proposal The CDA R2 standard includes mechanisms for expressing and managing confidentiality at

a granular level. A confidentiality code and context is already a part of the CDA R2

architecture. Prior Implementation Guides simply don’t use these mechanisms. They don’t

prevent their use. They just don’t provide any instructive guidance or applicable

conformance for their use. The consolidated CDA implementation guide could add

demonstration of the use of these mechanisms.

“Augmenting” the CDA R2 implementation guide to add this content could be done in a way

that leads the way on addressing the issue, but allows for a phased approach to adoption.

Specification language in a technical specification expresses conformance requirements

using one of three levels of stringency:

MAY - protects implementers, ensuring that the added functionality will not cause non-

conformance.

SHOULD – identifies a best practice and implies that a SHALL requirement may follow.

SHALL – requires conformance, stipulating non-conformance if not present. This permits

expected practices to be enforced.

Adding conformance guidance to the consolidated CDA Implementation Guide through the

use of MAY-level conformance statements would get the ball rolling on addressing the



needed granular consent and privacy controls.

Benefit Adding MAY-level conformance guidance on granular consent and privacy controls will not

solve this complex challenge. It will however signal movement in that direction. In the grand

scheme of things, there are only two reasons for something not being done: one is not

having finished and the other is not having started. CDA implementers are not done

implementing consent and privacy controls because they have not started. Adding MAY-

level guidance in the use of available CDA R2 confidentiality control mechanisms would

move the effort across the starting line on this important issue. Showing how CDA

documents can help address these legal, ethical, and social needs will diminish the barrier

to HIT adoption.

Challenging Use

Case

Development of a consent and privacy mechanism, especially one that allows for granular

control, will shift the challenge to a new focal point. Esoteric questions, like if an adolescent

should be granted the ability to keep information about sexual health private from a parent,

will suddenly become more feasible to implement. Consequently, the underlying ethical

questions about what is right and wrong will need to be broached. New legal, ethical and

social issues will accompany the progress made possible by innovation.

2.1.3 Documents that support Meaningful Use and Quality Measures

Issue In the context of Meaningful Use, one of the primary use cases for machine readable data,

i.e. structured entries, is the support of Quality Measures which cannot feasibly be

computed manually, but could possibly be computed using computers. With that use in

mind as a prime goal, we must ask: What value is a Quality Measure if we don’t know (or

can’t know) that it is right?

If there is a mechanism that permits human validation to confirm that machine readable

data, i.e. Entries, reasonably represent the human account of the information, i.e. the

narrative text, then we would have a means to validate computed quality measures within

the context of the documentation. On a large scale, we could use statistical methods to

perform validation on reasonably-sized samples, to perform validation within tolerable levels

of uncertainty.

If we have no mechanism to connect a structured Entry with the original source data, then

how would we ever be able to know that the machine readable data in a document is

correct? How would we know if the National Quality Measures produced by processing



multiple documents are correct?

If there is no mechanism that permits us to validate the machine readable data, then we

have not met critical requirements we know will be needed to achieve one of our most

valuable intended goals for implementing HIT.

Detailed Proposal Based on this rationale, Test Assertions could be added to the Harmonized CDA

Specification to specify how Entry-level “content validation” SHALL be conducted. This

proposal is supported by the Conformance Specification specifications listed in section 9.2

of the OASIS Conformance Requirements for Specification v1.0. The OASIS specification

states:

“A specification MAY include test assertions as part of the specification. A test assertion is

a statement of behavior, action, or condition that can be measured or tested. It is derived

from the specification’s requirements and bridges the gap between the narrative of the

specification and the test cases. Each test assertion is an independent, complete, testable

statement for requirements in the specification. Each test assertion results in one or more

test cases. Including test assertions as part of the specification facilitates and promotes the

development of conformance test suites and tools. Specific benefits include:

helping to uncover inconsistencies, ambiguities, gaps, and non-testable

statements in the specification by developing test assertions in parallel with the

specification,

ensuring consistency between the specification and assertions,

allowing test assertions to be reviewed and accepted by the specification

developers and the public,

providing a common set of assertions (and thus interpretation of the

requirements) from which test developers can develop conformance tests,

encouraging the early development of conformance tests that can be used by

implementers during the development of their implementation,

achieving comparability between the results of corresponding tests developed

by different organizations, and

achieving confidence in the resulting tests as a measure of conformance.

Examples of specifications that included test assertions as part of their specification include

several IEEE and ISO standards, most notably IEEE POSIX and ISO 10303 (STEP).”

(OASIS, 2011)



This is not a new idea. Some of the previously developed CDA implementation guides

included Schematron rules which could be used to validate a document against the

conformance requirements expressed in the implementation guide.

Creating a “double entry system” where internal consistency can be verified is not a new

idea. This principle is at the heart of the double entry accounting methods developed in the

15th century by Luca Bartolomes Pacioli and Benedetto Cotrugli (Canham Rogers, 2001).

The integrity achieved in this systematic, balanced approach to recording information forms

the basis for every modern banking and finance application in the world.

Benefit Adding test assertions for entry content validation would build in a mechanism to assure that

any decisions regarding the conformance statements for entries and narrative text will

include a means to ensure that the machine-readable data can be verified relative to the

human readable text or other humanly verifiable information (in the case of device-

generated data the Entry content in a CDA can be humanly verified against actual machine

data).

This issue is too important not to get it right. Encoding data in a CDA document must

promote MU. MU must provide a sound foundation for future meaningful uses of health

information. To be sound the information must be verifiably correct.

Social and

Ethical Issues

Is the choice to reduce quality expectations in favor of more rapid progress a social issue?

Is it an ethical one as well? Who benefits and who loses when we sacrifice the quality of

things done in the present? How do we as a society acknowledge the rights and interests

of generations that will come after us? These are the people who will be affected the most

by current decisions. Who is their advocate now? When we relax our requirements in order

to make more progress sooner should additional sustainability issues weigh into our

decision?

We could be more certain of the quality of the information we are creating if we took the

time to produce Schemetron validation rules and other content validation rules as a part of

the CDA implementation guide. Can we afford to spend the extra time doing it? Can we

afford not to?

In data processing the old adage holds true: garbage in, garbage out. Without the potential

for proper semantic-level validation, we run the risk of polluting our world with electronic

health information that in the future could be garbage – a 21st Century sort of “carbon

emissions”. Do we have an ethical responsibility to foresee these problems and proactively



ensure that the data we create does not end up being garbage that future generations will

be left to sort out?

2.1.4 Documents that meet Minimum Necessary Rule data requirements

Issue Presently there are stipulations within our legal regulations affecting electronic health

information which are not specific enough to be enforceable. The Minimum Necessary Rule

is one example. Imagine how long it might take to legally prove what information was the

minimum necessary to be shared in a particular situation. Denial of claims could become a

litigation free-for-all pitting one medical expert witness against another.

Detailed Proposal The CDA Implementation Guide could be referenced as a definitive specification of the

Minimum Necessary Data required for a particular data inquiry. A CDA Implementation

Guide is very specific about the type of information in scope for a particular type of

document. It spells out which data is Required and which is Optional. If a particular type of

claim indicated that a CDA History and Physical (identified both by name and LOINC

document code) was the Minimum Necessary Data required to support the coverage

decision, then the CE would know both what information to send and how to construct a

document containing only the required data.

Benefit Developing tightly defined, use case-based CDA Implementation Guides would facilitate

compliance and enforceability of the law. It would transform the somewhat nebulous

concept of “minimum required” into a testable specification. This approach does not mean

debate would cease on what was the minimum required data for a certain use case. The

negotiation would be shifted to an implementation standards working group. A consensus

would be developed among a knowledgeable set of stakeholders and the agreement about

what constituted the Minimum Necessary Data would be encoded in the CDA

implementation guide. The judgment would not be pushed into the courtroom on a case-by-

case basis. The risk for time-consuming, costly and behavior-altering litigation could be

significantly reduced.

Real-time

example

On March 17th, HHS issued a notice proposing to amend the Privacy Act of 1974 to

establish a Computer Matching Program between CMS and the Department of Defense.

The examples shows that individuals need to be concerned with how much data is

accessible and only permit the minimum required. Data sharing agreements may have an

unexpected result. Secondary uses may be concerned with finding ways to avoid current



obligations to provide health care benefits.

The amendment explains, that current law requires the Office of the Assistant Secretary of

Defense (Health Affairs) / TRICARE Management Activity (TMA) to discontinue military

health care benefits to MHS beneficiaries who are Medicare eligible and under the age of

65 when they become eligible for Medicare part A because of disability/ESRD unless they

are enrolled in Medicare Part B. Current law also requires TMA to provide health care and

medical benefits to MHS beneficiaries who are Medicare eligible (commonly referred to as

the dual eligible population) over the age of 65 who are enrolled in the supplementary

medical insurance program under Part B of the Medicare program.

This amendment will allow CMS to combine both groups of the MHS beneficiary population

described above into one single database to more effectively carry out this matching

program. In order for TMA to meet the requirements of current law, CMS agrees to disclose

certain Part A and Part B enrollment data on this dual eligible population, which will be used

to determine a beneficiary's eligibility for care under CHAMPUS/TRICARE. The Defense

Enrollment and Eligibility Reporting System (DEERS) will receive the results of the

computer match and provide the information to TMA for use in its matching program.

This computer matching agreement supersedes all existing data exchange agreements

between CMS and DMDC applicable to the exchange of personal data for purposes of

disclosing enrollment and eligibility information for MHS beneficiaries who are Medicare

eligible.

Under the proposed implementation, DEERS will furnish CMS with an electronic file on a

monthly basis extracted from the DEERS systems of records containing social security

numbers (SSN) for all MHS beneficiaries who may also be eligible for Medicare benefits.

CMS will match the DEERS finder file against its “Medicare Beneficiary Database” system

of records (System No. 09-70-0536), and will validate the identification of the beneficiary

and provide the Health Insurance Claim Number that matches against the SSN and date of

birth provided by DEERS, and also provide the Medicare Part A entitlement status and Part

B enrollment status of the beneficiary.

CMS's data will help TMA to determine a beneficiary's eligibility for continued care under

TRICARE. Beneficiaries’ info will be released to CMS pursuant to the routine use set forth in

the notice. The notice also states that data may be released to HHS "for support of the

DEERS enrollment process and to identify individuals not entitled to health care."



The Privacy Act requires that CMS provide an opportunity for interested persons to

comment on the proposed matching program. Organizations interested in protecting

individual’s privacy could create a CDA Document which precisely defined the Minimum

Required Data needed to confirm duplicate status across TMA and CMS. That could be as

little as Date of Birth and SSN. The Access could be limited to ONLY the data needed to

fulfill the original stated purpose of the amendment. Without this sort of precise definition,

this amendment could inadvertently open up all the data available in CMS, allowing it to be

shared with HHS. The Minimum Required Data rule, made specific through the use of a

precisely defined CDA specification, could allow the objective of this amendment to be

achieved without giving full access to CMS data which HHS could use to identify individuals

not entitled to health care.

2.1.5 Evolution of the governance of technical standards

Issue As technical specification become entwined in legal regulation and society’s dependence on

the technical artifacts increases, the need for more formalized and more democratic

governance practices increases. Many technical specifications develop within organizations

which have expensive membership fees. The standards developed by these organizations

are protected as intellectual property and access can be blocked or used as a revenue

generation strategy. Access to the standard may be a secondary priority behind

development of the next and newer versions. Implementation of the existing standard may

be less of a concern than implementation of a trial supplement.

Detailed Proposal Access to standards that are adopted by Meaningful Use regulations need to have licensing

issues resolved so that the technical specifications are freely available for all to access

them. In order to get access to the HL7 CDA R2 Specification it must be purchased and it is

not a trivial expense. Access is free for HL7 members, but membership, at even the lowest

level, is $700 per individual. SDO’s intending to have their specifications utilized in national

legislation should be required to negotiate licensing with the US government so that access

can be obtained through the National Library of Medicine (NLM). All the needed “content

registries”, such as those required to catalog CDA IG conformance rules and templates,

should be available through the NLM.

Planning and governance of the adoption of newer versions of the standard should be

synchronized and overseen by a national organization, like the ONC, so that releases could

be orchestrated. Interdependency between standards creates a complex tapestry of

conformance requirements. To manage that complexity, it would be beneficial to address



the need at a national level. The interdependence between the 5010 standard and ICD-10

is a good example. Cutting over to these two standards needs to be coordinated and

mandated in order for evolution to be possible. HL7 CDA R2 and its successor, CDA R3

(which is already in the works), are based on the HL7 version 3 standard. The majority of

HL7 users are using HL7 v2.3.1 or v2.5. When will the move to HL7 v3.0 happen? What

will it cost? What is the cost, in terms of reduced interoperability, if we do not evolve to use

the newer standard? Who will bear these costs? How should issues like this get decided?

Benefit Increasing governance capabilities for HIT SDOs will carry a cost. But, it’s worth it. We must

preserve the incentives that inspire SDOs to develop beneficial new standards. We must

facilitate ubiquitous access to standards as they become a dominant design. We must

acknowledge this work is never ending. This will be ongoing development, implementation

and maintenance costs. A commitment to orchestrated change will cost the Healthcare

industry some autonomy. However, in return the benefits of being on a healthy regime of

continuous improvement will be gained.

This situation is no different than any other. Investments made in the present, benefit the

future. Long-term, regular investments can achieve significantly better returns than sporadic

investment made at irregular intervals. Similarly, a proactive governance and progress plan

for HIT standards evolution and adoption would produce better long-term results.

3 Shifts in Compliance Burden

Issue As privacy regulations change to address emerging issues created by electronic health

records, new mechanisms will be needed to ensure compliance with the laws. Manual

compliance processes will not be feasible to monitor and confirm electronic information

access and sharing. The new compliance burden will be electronic in nature and electronic

tools will be the only feasible approach. The new compliance capabilities will address the

new kinds of issues created by the use of EHRs. They also will help address compliance

issues that existed prior to making these electronic changes.

Recently proposed regulations provide examples of this shift toward the need for new

electronic compliance mechanisms. On March 17th, the Department of Health and Human

Services proposed changes that would allow states to receive matching Federal funding to

develop new data mining capabilities that help fight Medicaid Fraud (Goedert, Medicaid

Data Mining, 2011) The proposed final rule states: This proposed rule amends a provision in



HHS regulations that prohibits State Medicaid Fraud Control Units (MFCU) from using

Federal matching funds to identify fraud through screening and analyzing State Medicaid

claims data, known as data mining. To support and modernize MFCU efforts to effectively

pursue Medicaid provider fraud, we propose to permit Federal Financial Participation (FFP)

in the costs of defined data mining activities under specified conditions. In addition, we

propose that MFCUs annually report the costs and results of approved data mining activities

to OIG. (HHS, Office of Inspector General, 2011)

This example and others such as the Notice to Allow Computer Matching Program (HHS,

Notice of Computer Matching, 2011) cited in the discussion of the Minimum Data Rule,

demonstrate how changes in the compliance landscape are occurring as electronic health

information technology evolves. While some of these innovations ensure privacy in the new

era of EHRs, others help address issues like fraud, in a way we previously could not have

accomplished.

4 Governance Issues

4.1.1 Federal-level governance for efficiency and effectiveness

What role should

the federal

government play

and why?

Federal-level governance of HIT standards will produce efficiency and effectiveness. The

very nature of information sharing requires consistency and interoperability. If we expect

national-level data sharing, it can only be attained through orchestration at the national

level. It takes national-level initiatives to address the needed harmonization of our EHR

adoption efforts. The S&I Framework project, sponsored through the ONC, is an example of

the type of national coordination required to address nation-wide implementation issues

entangled within achieving Meaningful Use (ONC 2011).

4.1.2 State-level governance for tailored implementation to fit local preferences

What role should

the state

government play

and why?

If orchestration of EHR adoption issues were more orchestrated at a national level, what

role would state’s sovereignty play in these matters? Clearly the social culture of the United

States is steeped in the expectation that governance and policy needs to fit local

preferences. Unfortunately, differences from state to state in EHR adoption make comparing

national data ineffective and inefficient. The complexities make data sharing, more difficult

and can prevent the collection of information that supports the assessment of national



quality measures. Without the measure, health reform has no means for determining and

directing change. Is there any way to accomplish both national consistency and local

control?

One possibility would be to design “tailor-ability” into national initiatives aimed at achieving

meaningful use of information gained through EHR adoption. For example, consider the four

flavors of HIE strategies being deployed around the US: Opt-in, Opt-in with exceptions,

Opt-out, and Opt-out with exceptions. The use of specific tools, like CDA specifications that

detailed the type and nature of data to be recorded for exchanged, could permit conditions

to be crafted which support the variety of data participation models, but still allow national

quality measures to be captured and assessed. This method of specification would permit

“controlled flexibility”. It is an approach that would allow both objectives, data consistency

coordinated at a national level AND state-level flexibility to meet local preferences.

5 Conclusion

As national focus shifts from healthcare revitalization strategy to tactics for implementing

HIT, the vision for HIT needs to become more specific. We need to articulate how the

technology could be used to achieve the strategic goals that have been set. It is time to

move beyond consensus building around historical perspectives. It is time to consider how

to move the consensus forward. Planning is a future-focused activity. To lead IT-driven

change in heath care, HIT implementation standards need to be positioned to support

current and future needs--needs around privacy and consent, meaningful use and quality

measures. We must shift our focus to expanding the consensus. Aim must be on evolving

today’s implementation standards to be positioned to support the direction in which we

know we must head.

Our job as HIT professionals is to devise creative solutions that address our nation’s needs.

That includes the legal, ethical, and social needs that accompany care delivery. None of

these requirements can be sacrificed without negative consequences. Excluding some

factors will diminish our ability to meet national goals. To achieve positive health outcomes

from this massive national investment in HIT, all the constraints need to be considered in

crafting solutions. The vision must be comprehensive.

Without a clear and detailed view for the future, we cannot make optimal decisions in the

present. The public comment period is designed to solicit feedback and reveal new



possibilities. Contributing input during this policy phase allows every American to participate

in a important planning process. It is a decidedly democratic way to establish “go forward”

plans. We have an opportunity to participate in the democratic process of establishing the

new “go forward” implementation plan. If ever there were a time when the power of ideas

had big potential impact, public comment would be it.

The consolidated CDA implementation guide, now being prepared, merely establishes a

starting point for the public process of establishing the National standard. We are

challenged to think of new ways to solve current problems and address unmet needs. What

improvements merit inclusion in the CDA Implementation Guides? Can we produce a CDA

implementation guide that is more than just a lowest common denominator of prior work?

We may be able to produce an expanded CDA implementation standard that moves us

closer to meeting our Nation’s shared vision for HIT adoption and the meaningful use of the

electronic health information. Following the public comment period, revisions based on

information gained from the open discussion will be incorporated to form the new CDA

implementation standard to support MU Stage 2.This is our chance to start with that end in

mind.

We may not be able to anticipate every consequence of implementing this new technology,

but we can predict that as we proceed, adoption will cause additional friction in new places.

We may not know what all of the issues will be, but we can redouble our resolve, as a

nation, to remain committed to this needed change. We can prepare for greater challenges

ahead, and agree that we will remain committed to the goal of national adoption of

electronic health records, despite the unintended consequences we will need to overcome.



6 Bibliography

American Psychological Association (2010). Concise rules of APA style. Washington DC: American Psychological Association.

ASTM International (2011). ASTM E2369 - 05e1 Standard Specification for Continuity of Care Record (CCR) Downloadable from http://www.astm.org/Standards/E2369.htm (Cost of specification is $75.00 no membership affiliation required to purchase the specification.)

Baby Boomer-Magazine.com. Who Is the True Baby Boomer Generation? Retrieved from http://www.babyboomer-magazine.com/news/165/ARTICLE/1096/2010-03-28.html

Benson, T. (2010). Principles of Health Interoperability HL7 and SNOMED. Springer: UK.

Canham Rogers (2011). History of double entry bookkeeping. Retrieve from: http://www.canhamrogers.com/HDEB.htm

Centers for Medicare and Medicaid Services (2011). ICD-10 and Version 5010 Compliance Timelines. Retrieved from https://www.cms.gov/ICD10/03_ICD-10andVersion5010ComplianceTimelines.asp

Cichon, M. (1999). Modeling in health care finance: a compendium of quantitative techniques. United Kingdom: International Labour Organization

Commission on U.S. Federal Leadership in Health and Medicine: Charting Future Directions (2009). New horizons for a healthy America: recommendations to the new administration. Washington, D.C.

Commission on U.S. Federal Leadership in Health and Medicine: Charting Future Directions (2010). A 21st

century roadmap for advancing America’s Health: the path from peril to progress. Washington, D.C.

Continuity of Care Document (2011). Retrieved from http://en.wikipedia.org/wiki/Continuity_of_Care_Document

Department of Health and Human Services, Centers for Medicare & Medicaid Services (2010). 42 CFR Parts 412, 413, 422 et al. Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Final Rule. Federal Register of the National Archives and Records Administration

Department of Health and Human Services, Centers for Medicare & Medicaid Services (2011). Privacy Act of 1974, CMS Computer Match No. 2011-02, HHS Computer Match No. 1007. Retrieved from http://www.ofr.gov/(S(24xcfy32ttfejwz0xkvc3jkz))/OFRUpload/OFRData/2011-06273_PI.pdf

Department of Health and Human Services, Office of the National Coordinator for Health Information Technology (ONC) (2010). 45 CFR Part 170. Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology.

http://www.astm.org/Standards/E2369.htm



Federal Register of the National Archives and Records Administration

Department of Health and Human Service, Office of Inspector General (2011). 42 CFR Part 1007, Federal Register Volume 76, Number 52 Retrieved from http://www.gpo.gov/fdsys/browse/collection.action?collectionCode=FR&browsePath=2011%2F03%2F03-17%5C%2F5%2FHealth+and+Human+Services+Department&isCollapsed=false&leafLevelBrowse=false&isDocumentResults=true&ycord=788

Dolin, R., Alschuler, L., Boyer, S. Beebe, C., Behlen, F. M., Biron, P. V., and Shabo, A. (2006). HL7 Clinical Document Architecture, Release 2. Journal of the American Medical Informatics Association. V.13(1); Jan-Feb 2006

Elmedorf, D. W. (2010). Health Costs and the Federal Budget. Congressional Budget Office presentation to the Institute of Medicine. Retrieved from http://www.cbo.gov/ftpdocs/115xx/doc11544/Presentation5-26-10.pdf

Flat Rock (2011). Population Pyramids – The Boom moves along. Retrieved from http://www.flatrock.org.nz/topics/money_politics_law/boom_moves_along.htm

Goedert, J. (2011). Consumer groups: hold strong on MU. Health Data Management. http://www.healthdatamanagement.com/news/meaningful-use-criteria-comments-consumers-42080-1.html

Goedert, J. (2011). Patient Privacy Right Comments on Stage 2. Health Data Management. http://www.healthdatamanagement.com/news/privacy-ehr-meaningful-use-stage-2-onc-comments-42089-1.html?techlabs=1

Goedert, J. (2011). Rule to enable Medicaid data mining for fraud. Health Data Management. http://www.healthdatamanagement.com/news/medicaid-hhs-rule-data-mining-claims-fraud-42161-1.html

Health Level 7 (2011). Clinical Document Architecture Release 2.0. HL7 Standards. Retrieved from http://en.wikipedia.org/wiki/HL7#HL7_standards

Health Level 7 (2009). HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD). HL7 Version 3 Standard. Specification available on CD to members only. (Note: This specification is a CDA implementation of the ASTM E2369-05 standard specification for Continuity of Care Document (CCR).

Health Level 7 (2009). HL7 Version 3 Standard. Specification available on CD to members only. (Cost of membership is US$702.00, Cost of HL7 CDA Document training US$1,800.00)

Health Level Seven (2010). The Health Story Project and Health Level Seven International to host webinar on how to exchange basic records and meet early meaningful use. Health Level Seven. Requirementshttp://www.hl7.org/documentcenter/public/pressreleases/HL7_PRESS_20100714.pdf



HIT Policy Committee (2011). Meaningful Use Workgroup request for comments regarding meaningful use Stage 2. Retrieved from http://healthit.hhs.gov/media/faca/MU_RFC%20_2011-01-12_final.pdf

HITECH Survival Guide (2011). HITECH Act of 2009 and HIPAA background. Retrieved from http://www.hipaasurvivalguide.com/hipaa-survival-guide-21.php

HITECH Survival Guide (2011). HITECH Act Summary. Retrieved from http://www.hipaasurvivalguide.com/hipaa-survival-guide-02.php

HITSP (2011). C32 - HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component. Retrieved from http://www.hitsp.org/ConstructSet_Details.aspx?&PrefixAlpha=4&PrefixNumeric=32

HITSP (2011). C83 - HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component. Retrieved from http://wiki.hitsp.org/docs/C83/C83-1.html

Indian Health Services (2011). American Recovery and Reinvestment Act, HITECH Act, EHR Certification and meaningful use. Retrieved from http://www.ihs.gov/recovery/index.cfm?module=dsp_arra_meaningful_use

Institute of Medicine (2001). Crossing the quality chasm. Report brief retrieved from http://www.iom.edu/~/media/Files/Report%20Files/2001/Crossing-the-Quality-Chasm/Quality%20Chasm%202001%20%20report%20brief.pdf

Integrating the Healthcare Enterprise (2011). Patient Care Coordination Technical Framework, Vol. 1. Retrieved from http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Rev6-0_Vol_1_2010-08-30.pdf

Institute of Medicine (2000). To Err Is Human. Report summary retrieved from http://www.iom.edu/~/media/Files/Report%20Files/1999/To-Err-is-Human/To%20Err%20is%20Human%201999%20%20report%20brief.pdf

Integrating the Healthcare Enterprise (2007). Patient Care Coordination. Vendor’s Workshop. Retrieved from http://www.ihe.net/Participation/upload/pcc1_ihe_wkshp07_pcc_overview_boone.pdf

Leape, L. L., Berwick, D. M. (2005). Five years after “To Err Is Human”: What have we learned? Journal of the American Medical Association. May 18

th edition

Lindgren, K. (2011). Legal, Ethical and Social Issues in Medical Informatics. Northwestern University, Medical Informatics MMI407.

LOINC (2011). LOINC [Document Codes and Regenstreif LOINC Mapping Assistant (RELMA) tool]. Downloadable from http://loinc.org/relma

Lubinski, D., Ruggeri, R. (2003). Implementing ASTM CCR and 7 CDA. Retrieved from http://www.centerforhit.org/PreBuilt/chit_CCR_CDA.PPT

http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Rev6-0_Vol_1_2010-08-30.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_PCC_TF_Rev6-0_Vol_1_2010-08-30.pdf

http://loinc.org/relma



Mosquera, M. (2011). Panel weighs decisions for stage 2 quality measures. Government HealthIT. Retrieved from http://www.govhealthit.com/newsitem.aspx?nid=76410

National Quality Forum. eMeasures for Public Comment. National Quality Forum. Retrieved from http://www.qualityforum.org/Projects/h/QDS_Model/Quality_Data_Model.aspx

National Quality Forum (2010). Driving quality and performance measurement – a foundation for clinical decision support. National Quality Forum. Retrieved from http://www.qualityforum.org/Publications/2010/12/Driving_Quality_and_Performance_Measurement_-_A_Foundation_for_Clinical_Decision_Support.aspx

Organization for the Advancement of Structured Information Standards (2002). Conformance Requirements for Specifications v1.0. OASIS. Retrieved from http://www.oasis-open.org/committees/download.php/305/conformance_requirements-v1.pdf

Office of the National Coordinator (2011). CDA Consolidation Project. ONC S&I Framework. Retrieved from http://jira.siframework.org/wiki/display/SIF/CDA+Consolidation+Project

Shattuck, J. (1984). Computer matching is a serious threat to individual rights. Communications of the ACM. Vol. 27, Number 6. Retrieved from http://web.cs.wpi.edu/~hofri/Readings/CompMatch(b).pdf

Smith, B. (2008). Flavors of Null [Web log post]. Retrieved from http://hl7-watch.blogspot.com/2008/10/flavors-of-null.html

Sobel, R. (2007). The HPAA Paradox: the privacy rule that’s not. Hastings Center Report 37, no. 4: 40-50

Spronk, R. (2011). The H7 roadmap for CDA R3 and the CCD. Ringholm. Retrieved from http://www.ringholm.com/column/hl7_cda_r3_ccd_roadmap.htm

Standards and Interoperability (S&I) Framework Organization (2011). CDA Harmonization Project. Retrieved from http://jira.siframework.org/wiki/display/SIF/CDA+Consolidation+Project

Tessier, C. (2004). Continuity of Care Record. Retrieved from http://www.astm.org/COMMIT/E31_CCRJuly04.ppt

United States Census Bureau (2011). Projected Deaths by Sex, Race, and Hispanic Origin for the United States: July 1, 2000 to June 30, 2050 [Data file and format guide]. Retrieved from http://www.census.gov/population/www/projections/downloadablefiles.html

United States Census Bureau (2011). Projected Population by Single Year of Age, Sex, Race, and Hispanic Origin for the United States: July 1, 2000 to July 1, 2050 [Data file and format guide]. Retrieved from http://www.census.gov/population/www/projections/downloadablefiles.html

Unicharts (2011). What is CCR? Retrieved from http://www.unicharts.com/ccr.html



United States Census Bureau (2011). USA people Quick Facts. US Census Bureau. Retrieved from http://quickfacts.census.gov/qfd/states/00000.html

Wikipedia (2011). American Recovery and Reinvestment Act. Retrieved from http://en.wikipedia.org/wiki/American_Recovery_and_Reinvestment_Act_of_2009

Wikipedia (2011). Baby boomer generation. Retrieved from http://en.wikipedia.org/wiki/Baby_boomer

Wikipedia (2011). Health Insurance Portability and Accountability Act. Retrieved from http://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act

Wikipedia (2011). Continuity of Care Record. Retrieved from http://en.wikipedia.org/wiki/Continuity_of_Care_Record



7 Glossary

This glossary is organized as a logical progression rather than as an alphabetical index. It is intended to be

read sequentially to provide background information that enriches the context of the paper.

7.1.1 Legal

The use of governance mechanisms, such as legislation, to establish right from wrong both going forward,

for enforcement practices in the present (deciding what acts need to be deterred or prevented and which

should be incented), and for assessing punitive measures for wrongful acts committed in the past or

holding free from blame for acts committed in the past that were not wrongful.

7.1.2 Ethical

The use of logical reasoning to decide right from wrong. (In practice it may reflect current thinking or be

influenced by future, present or past events, but by design is meant to be a “timeless” technology.)

7.1.3 Social

The things people do, as a group or in groups

7.1.4 Privacy

The intension to limit access within an entity so as not to expose to others, i.e. to oneself and not in view or

providing access for others.

7.1.5 Security

Mechanisms developed to meet expectations resulting from Privacy with the goal of preventing unwanted

access.

7.1.6 Consent

Mechanisms developed to meet expectations resulting from Privacy with the goal of permitting wanted



access.

7.1.7 Health Information Portability and Accountability Act (HIPAA)

HIPAA was enacted by the U.S. Congress in 1996. The Act is massive in scope with five separate Titles.

Title II of HIPAA, called the Administrative Simplification provisions, requires the Department of Health and

Human Services (HHS) to draft rules to implement HIPAA. A little behind schedule (it took 12 years rather

than 5), but per the requirements of Title II, HHS promulgated five rules regarding Administrative

Simplification:

1. the Privacy Rule,

2. the Transactions and Code Sets Rule,

3. the Security Rule,

4. the Unique Identifiers Rule, and

5. the Enforcement Rule.

So, while the original HIPAA law remained the same as enacted by Congress, HHS published the Security

Standards Final Rule at chapter 45 CFR Parts 160, 162, and 164 and the Privacy Rule Final Rule at 45

CFR Parts 160 and 164 (Lindgren, 2011). These rules require the establishment of national standards for

electronic health care transactions and national identifiers for providers, health insurance plans, and

employers. The provisions also address the security and privacy of health data. The standards are meant

to improve the efficiency and effectiveness of the nation’s health care system by encouraging the

widespread use of electronic data interchange (HITECH Survival Guide, 2011).

7.1.8 Protected Health Information (PHI)

PHI is any oral or recorded information relating to the past, present, or future physical or mental health of

an individual; the provision of health care to the individual; or the payment for health care.

It is comprised of a set of information types specified under HIPAA privacy regulation 45 CFR 164.514(b)

(2) (i). It consists of 18 categories of data that support personal identification. (See section 6.1.7 for a list of

patient identifiers.)

“A covered entity may not use or disclose PHI except as permitted or require by [the final HIPAA Privacy

Rule]” (45 CFR 164.502(1a)). The rule allows for six (6) ways to “use or disclose” PHI:

1. treatment,

2. payment,



3. healthcare operations (a broad range of activities ,

4. by operation of lay (e.g. subpoena, court order or public health),

5. Covered Entity obtains written patient authorization/consent

6. Obtain waiver of patient authorization from IRB or Privacy Committee.

The law is intended to give patients more control over how their medical records are “used” and

“disclosed”. However, rather than broadly protecting privacy, the amended HIPAA rule generally constitutes

a disclosure regulation. Effective April 2003, the federal government gave six hundred thousand covered

entities, such as health care plans, clearing houses, and health maintenance organizations, “regulatory

permission to use or disclose protected health information for treatment, payment, and health care

operations” (known as “TPO”) without patient consent (Sobel, 2011). Some of these “routine purposes” for

which disclosures are permitted are far removed from treatment. In fact, “covered entities” and their

“business associates” may share patients’ sensitive personal information for treatment, payment, and

health care operations without the patients’ knowledge, over their opposition, and even if patients pay for

treatment out of pocket or request the right to be asked for consent to disclosure of their medical records.

Particularly troubling is the governmental authorization for covered entities to use patients’ confidential

health information without their consent for health care operations that are unrelated to payment or

treatment. As distinguished from “core” treatment and “routine” payment purposes, health care operations

permit the legal disclosure of information that could be inappropriately used for purposes that patients

might not approve, and thereby may lead to consequences patients might not like (Sobel).

7.1.9 De-Identification

De-identification is the HIPAA “safe harbor”. There are four ways to de-identify a healthcare data set:

1. Remove all individual patient identifiers from any protected health information,

2. Create a limited data set,

3. Obtain “certification” by a qualified statistician, or

4. Waiver from an Internal Review Board (IRB) or Privacy Committee.

The HIPAA Privacy Rule does not cover de-identified data (Lindgren, 2011).

Removing all of the patient identifiers (listed below) from the data creates a de-identified data set. A limited

data set is similar to a de-identified data set except it can have up to five patient identifiers added back in. A

limited data set may be used and disclosed for research, health care operations, and public health

purposes only, provided the recipient enters into a Data Use Agreement promising specified safeguards for

the PHI in that limited data set. A limited data set allows a researcher and others to have access to: dates

of admission and discharge; dates of birth and death; and five-digit zip code or “other geographic



subdivisions” other than street address.

7.1.10 Patient Identifiers

Patient identifiers describe the type of data that must be removed from Protected Health Information to

meet de-identification requirements. The list of 18 identifiers includes:

1. Patient Names;

2. All geographic subdivisions smaller than a state, including street address, city, county,

precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip

code if, according to the current publicly available data from the Bureau of the Census:

The geographic unit formed by combining all zip codes with the same three initial digits

contains more than 20,000 people; and

The initial three digits of a zip code for all such geographic units containing 20,000 or fewer

people is changed to 000.

3. All elements of dates directly related to an individual, including birth date, admission date,

discharge date, date of death; and all ages over 89 and all elements of dates (including

year) indicative of such age, except that such ages and elements may be aggregated into

a single category of age 90 or older;

4. Telephone numbers;

5. Fax numbers;

6. Electronic mail addresses;

7. Social security numbers;

8. Medical record numbers;

9. Health plan beneficiary numbers;

10. Account numbers;

11. Certificate/license numbers;

12. Vehicle identification and serial numbers, including license plate numbers;

13. Device identifiers and serial numbers;

14. Web Universal Record Locators (URLs);

15. Internet Protocol (IP) address numbers;

16. Biometric identifiers, including finger prints and voice prints;

17. Full face photographic images and any comparable images; and

18. Any other unique identifying number, characteristic or code (Lindgren, 2011).

7.1.11 Minimum Necessary Rule



The Minimum Necessary standard is a key protection of the HIPAA Privacy Rule. It is based on current

practice that PHI should not be used or disclosed, when it is not necessary to satisfy a particular purpose or

carry out a function. The Minimum Necessary standard requires covered entities to evaluate their practices

and enhance safeguards as needed to limit unnecessary or inappropriate access to and disclosure of

protected health information (45 CFR 164.502(b),164.514(d)). Under this rule, whenever a Covered Entity

(CE) uses or discloses PHI (e.g. to a payer, provide, or for other “TPO” activities), the CE must make

reasonable efforts to limit the information to the minimum amount necessary to accomplish the intended

purpose of the use or disclosure (Lindgren, 2011). In certain circumstances, the Privacy Rule permits a

covered entity to rely on the judgment of the party requesting the disclosure as to the minimum amount of

information that is needed. (Lindgren, 2011).

7.1.12 Health Information Technology for Economic and Clinical Health (HITECH Act)

The HITECH Act focuses on the establishment of a national health infrastructure and on providing

incentives for the adoption of electronic health records (EHRs). It also provides for “enhanced” privacy

protections. Subtitle D of the HITECH Act was enacted as part of ARRA. It addresses the privacy and

security concerns associated with the electronic transmission of health information (Lindgren, 2011). It

makes the HIPAA Privacy Rule and the HIPAA Security Rule a key issue for health care providers because

it establishes compliance requirements and penalties for violations, and it raises the expectation for privacy

and security practices in general. Under the HITECH Act, Non-compliance may prevent access to financial

incentives for EHR adoption and to obtaining full reimbursement down the road (HITECH Survival Guide,

2011, “HITECH Act of 2009 and HIPAA: Background”).

7.1.13 American Recovery and Reinvestment Act (ARRA)

ARRA was signed into law on February 17th, 2009. The Act makes supplemental appropriations for job

preservation and creation, infrastructure investment, energy efficiency and science, assistance to the

unemployed, and State and local fiscal stabilization, for the fiscal year ending September 30, 2009, and for

other purposes. The Act includes over $155 billion in funding for healthcare with $25.8 billion for HIT

investments and incentive payments (Wikipedia, 2011, “American Recovery”).

ARRA implementing regulations are being published now in the CFR. For example: 45 CFR parts 412,

413, 422, and 495 were published by CMS to implement incentive payments to eligible professionals (EPs),

eligible hospitals, and critical access hospitals (CAHs) participating in Medicare and Medicaid programs

that adopt and successfully demonstrate meaning use of certified electronic health record (EHR)

technology. (Department of Health and Human Services, Centers for Medicare and Medicaid Services,



2010). 45 CFR part 170 was published by the Office of the National Coordinator (ONC) to complete the

adoption of an initial set of standards, implementation specifications, and certification criteria, and to more

closely align such standards, implementation specifications and certification criteria with final meaningful

use Stage 1 objectives and measures. (Department of Health and Human Services, Office of the National

Coordinator for Health Information Technology, 2010).

7.1.14 Meaningful Use

Meaningful Use is a precisely defined state of EHR adoption which is required to qualify for CMS incentives

established in the HITECH Act. The definition was segmented into three stages called, Stage 1, Stage 2,

and Stage 3 to support a phased approach for gradually increasing the level of capability available in

certified EHR systems and modules, and the level of capability implemented by a Physician Entity (PE) and

eligible hospitals (Department of Health and Human Services, Office of the National Coordinator for Health

Information Technology, 2010).

7.1.15 Health Language Seven (HL7)

Health Level Seven is a Standards Development Organization (SDO). It is an all-volunteer, non-profit

enterprise involved in development of international healthcare informatics interoperability standards. “HL7”

is also used to refer to some of the specific standards created by the organization. HL7 standards are used

to provide a framework for the exchange, integration, sharing, and retrieval of electronic health information

(Wikipedia, 2011, HL7).

7.1.16 The HL7 Clinical Document Architecture Release 2 (CDA R2)

The HL7 CDA R2 is an XML-based markup standard specifying the encoding, structure, and semantics of

clinical documents for exchange. CDA R2 is the second release of the CDA specification. It is part of the

HL7 version 3 standard. Akin to other parts of the HL7 version 3 standard. It was developed using the HL7

Development Framework (HDF) and it is based on the HL7 Reference Information Model (RIM) and the

HL7 Version 3 Data Types. CDA documents are persistent in nature. The CDA specifies that the content of

the document consists of a mandatory textual part (which ensures human interpretation of the document

contents) and optional structured parts (for software processing). The structured part relies on coding

systems (such as from SNOMED and LOINC) to represent concepts. The CDA standard doesn’t specify

how the documents should be transported, making the standard applicable for data exchange using HL7

version 2 messages, HL7 version 3 messages, as well as by other mechanisms such as DICOM, Direct

Project, or the IHE Retrieve Form for Data Capture (RFD) (Wikipedia, 2011, Clinical Document



Architecture).

7.1.17 Conceptual representation of CDA hierarchy and document form

Content Modules for CDA R2 Documents

Section

Document

“Uber" Section

Entry

Entry detail

Basic Heirachy

A Section is the “Atomic Unit”

Conceptual form of a Document Content Module

Parent Templates (additional templates that this document conforms to)

Tem

pla

tes

Ref

eren

cin

gTh

is T

emp

late

This Template’s identity

Header

Section 1

Section 2

Uber-Section 3

Section 5

Section 4

Structured Body

7.1.18 CDA Implementation Guides

Several organizations, such as HITSP, Health Story, HL7 and IHE, have developed CDA implementation

guides which describe constraints placed upon CDA to satisfy a particular set of requirements for a named

Use Case. A Use Case is a particular set of business and clinical requirements involved in supporting a

care scenario. The HITSP C32 defines a CDA document that records a Summary of episode note. The

Health Story project defined eight (8) different types of CDA documents which record eight different types

of care documents, such as a Discharge Summarization note. The IHE Technical Framework includes five

(5) different types of CDA document definitions including for example, a Discharge Summarization note, a

Summary of episode note and a Referral Summary. HL7 Continuity of Care Document (CCD) defines a

Summary of episode note which is a CDA version of the Continuity of Care Record (CCR) defined by

ASTM (ONC, 2011, S&I Framework).

7.1.19 CDA Consolidation Project

Meaningful Use anticipates the widespread exchange of clinical information, and the Standards Final Rule

prescribes a number of clinical content standards. ONC has received feedback regarding implementation

challenges associated with these standards, specifically HITSP C32. At the same time, the Health Story

Project, HL7, and IHE have received implementer feedback expressing the need to consolidate the

Implementation Guides addressing exchange of common types of clinical documentation and to provide a

comprehensive library of reusable data elements based on "Templated CDA". HL7 initiated a project

to consolidate the numerous Clinical Document Architecture (CDA) implementation guides upon which C32

and other clinical content specifications are based and to address the high-priority items for harmonization.



Health Story, IHE, and HL7 are collaborating in this initiative to harmonize and consolidate current CDA

implementation guides in order to address that feedback. This volunteer effort is being hosted within

ONC's Standards and Interoperability (S&I) Framework and facilitated with the support of ONC S&I

Contractors (ONC, 2011, S&I Framework).

7.1.20 The Baby Boomer Generation

7.1.20.1 Chart Showing the Affects of Boomers on the US Population

Boomers are people born during the two decades spanning 1945 through 1964.

US Population

2

Population Pyramids – The Boom moves along. (Flat Rock ,2011)

Baby Boomer-Magazine.com reported in 2008 that, “According to the U.S. Census Bureau, approximately

69 million people are between the ages of 50 to 59. Every seven seconds, another Baby Boomer turns 50.

That equates to 12,000 people a day, or nearly 4.5 million people per year” (Baby Boomer-Magazine,

2011)

A baby boomer is a person who was born during the demographic Post-World War II baby boom. The

term "baby boomer" is sometimes used in a cultural context. Therefore, it is impossible to achieve broad

consensus of a precise definition, even within a given territory. Different groups, organizations, individuals,

and scholars may have widely varying opinions on what constitutes a baby boomer, both technically and



culturally. Ascribing universal attributes to a broad generation is difficult, and some observers believe that it

is inherently impossible. Nonetheless, many people have attempted to determine the broad cultural

similarities and historical impact of the generation, and thus the term has gained widespread popular

usage.

In general, baby boomers are associated with a rejection or redefinition of traditional values; however,

many commentators have disputed the extent of that rejection, noting the widespread continuity of values

with older and younger generations. In Europe and North America boomers are widely associated with

privilege, as many grew up in a time of affluence. As a group, they were the healthiest and wealthiest

generation to that time, and amongst the first to grow up genuinely expecting the world to improve with

time.

The baby boom has been described variously as a "shockwave” and as "the pig in the python." By the

sheer force of its numbers, the boomers were a demographic bulge which remodeled society as it passed

through it. (Wikipedia, 2011, “Baby Boomers”)

7.1.20.2 Chart showing J-curve used to model healthcare consumption

As people age, their consumption of healthcare increases. Micheal Cichon has written a book on this

subject titled, “Modeling in health care finance: a compendium of quantitative techniques”. In it he explains

that the healthcare consumption curve is J-shaped.

7.1.21 National Spending on Healthcare

7.1.21.1 Chart Showing the Affects of Boomers on the US Population



(image from http://economix.blogs.nytimes.com/tag/health-care/

Spending on healthcare is rising as a percent of GDP in many nations about the world, but the growth is

greatest in the US.

7.1.21.2 National Health Spending as a % of GDP

Statistics about National Health Expenditures (NHE) are available on the CMS website and can be

retrieved from https://www.cms.gov/NationalHealthExpendData/25_NHE_Fact_Sheet.asp.

Historical NHE, including Sponsor Analysis, 2009:

NHE grew 4.0% to $2.5 trillion in 2009, or $8,086 per person, and accounted for 17.6% of Gross

Domestic Product (GDP).

Medicare spending grew 7.9% to $502.3 billion in 2009, or 20 percent of total NHE.

Medicaid spending grew 9.0% to $373.9 billion in 2009, or 15 percent of total NHE.

Private health insurance spending grew 1.3% to $801.2 billion in 2009, or 32 percent of total NHE.

Out of pocket spending grew 0.4% to $299.3 billion in 2009, or 12 percent of total NHE.

Hospital expenditures grew 5.1% in 2009, slower than the 5.2% in 2008.

Physician and clinical services expenditures grew 4.0% in 2009, slower than the 5.2% in 2008.

Prescription drug spending increased 5.3% in 2009, faster than the 3.1% in 2008.



The federal government share of health care spending increased just over three percentage points

in 2009 to 27 percent, while the shares of spending by households (28 percent), private businesses

(21 percent) and state and local government (16 percent) fell by about 1 percentage

Projected NHE, 2009-2019:

Growth in NHE is expected to increase 5.7 percent in 2009 and average 6.1 percent per year over

the projection period (2009-2019).

The health share of GDP is projected to reach 17.3 percent in 2009 and 19.3 percent by 2019.

Medicare spending is projected to grow 8.1% in 2009 and average 6.9% per year over the

projection period.

Medicaid spending is projected to grow 9.9% in 2009 and average 7.9% per year over the

projection period.

Private spending is projected to grow 3.0% in 2009 and average 5.2% per year over the projection

period.

Spending on hospital services is projected to grow 5.9% in 2009 to $761 billion. Average growth of

6.1% per year is expected for the entire projection period.

Spending on physician and clinical services is projected to grow 6.3% in 2009 to $528 billion.

Average growth of 5.4% per year is expected for the entire projection period.

Spending on prescription drugs is projected to grow 5.2% in 2009 to $246 billion. Average growth

of 6.3% per year is expected for the entire projection period.