Documente Academic
Documente Profesional
Documente Cultură
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 1
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Table of Contents
Introduction......................................................................................................................................................3
Introduction......................................................................................................................................................3
Solution Types..............................................................................................................................................3
Cerner Responsibilities at a General Level..................................................................................................4
Glossary of Terms.............................................................................................................................................4
Common Capabilities.......................................................................................................................................7
EDI...............................................................................................................................................................7
Current Capability in Millennium 2007.19 and 2010.01.........................................................................7
Identifiers......................................................................................................................................................7
Privacy..........................................................................................................................................................9
Security.......................................................................................................................................................15
Ancillary solutions..........................................................................................................................................18
EDI.............................................................................................................................................................18
Current Capability..................................................................................................................................18
Privacy........................................................................................................................................................18
Current Capability..................................................................................................................................18
Direct Patient Care solutions..........................................................................................................................21
EDI.............................................................................................................................................................22
Current Capability..................................................................................................................................22
Privacy........................................................................................................................................................22
Current Capability..................................................................................................................................22
Revenue Cycle solutions................................................................................................................................26
EDI.............................................................................................................................................................27
Current Capability..................................................................................................................................27
Privacy........................................................................................................................................................28
Current Capability..................................................................................................................................28
Security.......................................................................................................................................................31
Current Capability..................................................................................................................................31
HIM solutions.................................................................................................................................................31
EDI.............................................................................................................................................................32
Privacy........................................................................................................................................................32
Current Capability..................................................................................................................................32
Security.......................................................................................................................................................35
Claims Attachments........................................................................................................................................35
Supplemental Documentation and Resources................................................................................................36
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 2
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Introduction
The Health Insurance Portability and Accountability Act (HIPAA) of 1996 presents great
challenges and requirements for healthcare providers as covered entities to meet
compliance requirements of the major rules that comprise the Administrative
Simplification provisions of the Act. In reviewing the requirements of the rules that can
be taken as having import for information systems, Cerner has attempted to identify the
most significant areas where Cerner’s Millennium application suite can assist Cerner’s
clients in achieving their organizational compliance objectives for HIPAA. Additionally,
with the signing into law of the American Recovery and Reinvestment Act (ARRA) of
2009, a number of new provisions were enacted under the HITECH portion of the Act
that extend the HIPAA Security and Privacy Rule requirements for certain patient rights
such as the patient right of access to an electronic copy of their record, the right to receive
an accounting of disclosures when made from an electronic health record for treatment,
payment or healthcare operations and to restrict disclosures of patient information to a
health plan for services the patient paid for out of pocket. ARRA HITECH also instituted
breach notification requirements for breaches involving electronic health records and
personal health records, and some new requirements were introduced connected to safe
harbor requirements under the breach notification rules issued by the federal government
in 2009 that involve use of encryption. The purpose of this whitepaper is to review the
major areas of compliance requirement and the role in compliance played by each major
Cerner solution type based upon current capability as Millennium 2007.19 and 2010.01.
Introduction
Solution Types
For the purposes of this whitepaper, there common capabilities and then there are four
families of Millennium solutions. These are as follows:
These classifications are important because the requirements of each kind of solution
under HIPAA are distinct to each of these categories as to the role that Cerner clients
should expect each of these solutions to play in enabling compliance with the major final
rules under HIPAA for EDI, Privacy and Security. These solution groupings will be used
as references rather than individual solution names within this whitepaper.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 3
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Cerner Responsibilities at a General Level
Cerner’s responsibilities to all of Cerner’s clients for HIPAA is to help enable the
compliance of provider organizations by providing for a reasonable level of system
capability to meet the main objectives clients will have. These include:
Glossary of Terms
Use
Use under HIPAA applies to accessing patient information within the provider
organization for any particular purpose. For our purposes, provider staff member or
clinician end user accesses to the electronic patient record Millennium for any purpose
constitute “use”.
Disclosures
Disclosure under HIPAA applies to any sharing of information outside the provider entity
for any particular purpose. For our purposes, these primarily apply to print events and
incidental disclosures. Once information has been printed, we can often assume that it is
for the purpose of disclosure to some outside party. Incidental disclosure can happen if
someone is looking over the user’s shoulder while the user is accessing a patient record
online. In either case, we are beyond our effective reach to play a role once the disclosure
occurs.
Treatment
Treatment is one of three categories of permissive use for providers under the HIPAA
Privacy rule. It applies broadly to most any direct or indirect care providing activity. It
extends not only to uses by provider staff but also disclosures for treatment related
purposes of other providers. A specific permission from the patient for such purposes is
not required as long as the patient has received a notice of privacy practices from the
provider that may be making the disclosure.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 4
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Payment
Payment is the second of the three categories of permissive use for providers. It applies
broadly to most any activity necessary to code services, submit claims for payment,
receiving payment, adjudicating a claim, following up on a claim, engaging in collections
activity for account follow up, etc.
Healthcare Operation
Healthcare operations are the third of the three categories of permissive use. They apply
to those activities necessary to maintain quality, credential provider staff and physicians,
perform peer review, perform audit, perform health planning, etc as long as the activity
applies to those needs of the provider rendering care to the patient. They do not have to
be specific to the patient, but they do need to be necessary for the provider to operate
generally.
Consent
Consent applies to seeking permission from the patient to use or disclose their
information for a purpose related to treatment, payment or healthcare operations. Under a
revision to the Privacy rule, consent is discretionary to the privacy practices of the
provider, and no longer a mandatory requirement. Most providers will not administer
privacy related consent unless required to do so by state law.
Authorization
The notice of privacy practices is the informational step of informing the patient of their
rights under HIPAA and educating them as to how their information may be used or
disclosed by the provider according to the provider’s privacy policies. The provider must
give each patient notice upon first point of service (usually taken to be face to face) after
April 14, 2003 (Privacy rule compliance date). The notice need only be given once even
if it changes, but many providers plan to re-notice the patient on a regular periodic basis
(annually) or as material changes occur to the policy.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 5
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
The provider must make a good faith effort to obtain the patient’s written
acknowledgement of receiving and understanding the notice of privacy practices from the
provider. This acknowledgement status must be recorded in the patient’s medical record,
and be available to staff for reference as needed.
Standard Transaction
A standard transaction is any one of the specified electronic transactions outlined in the
HIPAA Transaction and Code Set rule. Specific to Cerner’s interests, these are for
eligibility determination, filing a claim (institutional or professional), inquiring into the
status of a claim, receiving payment from a payer and performing referral certification
and authorization.
Standard medical code sets include ICD-9 v.I-III, HCPCS, CPT 4 and ADA Dental
Codes. Cerner is customarily expected to support the first three sets. These are required
for diagnosis and procedure/service identification under the Transaction and Code Set
rule. ICD 9 v.I-III will be replaced as of October 1, 2013 by ICD 10 CM (for diagnosis
coding in all care venues) and ICD 10 PCS (for procedure coding for inpatient
procedures).
Under the Transaction and Code Set rule, there are requirements as referenced by the
ANSI X-12 v.4010A transaction set for standard electronic transactions per the above to
use particular required code sets for such things as race, gender, place of service, revenue
code, medical service, provider data, etc. These are many of the things we would think of
as person, visit and service demographics. It should be noted that the v.4010A will be
replaced by the 5010 transaction set as of January 1, 2012.
Minimum Necessary
Minimum necessary is the Privacy rule concept that a provider only uses the appropriate
level of information for the treatment, payment or healthcare operations or other purpose
at hand although treatment disclosures are exempted. For authorizations, a similar
concept applies although a provider may rely on the requesting party to determine what
information is needed. However, the provider is expected to exercise good judgment to
disclose only what is needed to fulfill the authorization or release request as written.
Minimum necessary must be embodied in written policies and procedures by the provider
for each major type of use or disclosure where required by the Privacy rule.
Need to Know
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 6
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Need to know is the Security rule concept that a individual staff member or clinician only
have access to that patient information that is necessary for the individual to carry out his
or her responsibilities as defined by written provider policy and procedure.
Accounting of Disclosures
Common Capabilities
The majority of Cerner’s current and new capabilities are available at a common level for
any given Cerner licensed software solution. This is especially true for authentication
security, access controls and auditing. Common capabilities include the following:
EDI
Support for currently required medical code sets for use throughout Millennium
clinical and financial solutions for the purpose of diagnosis and procedure coding
in support of billing activities
Support for use of aliases for implementation of standard identifiers for provider,
employer and health plan as the rules are finalized
Identifiers
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 7
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Two identifier rules have been finalized as of the date of this white paper – for the
Employer Identifier and for the National Provider Identifier (NPI). At a common level,
these identifiers are supported as discussed below.
Employer Identifier
The Employer Identifier is supported as the primary alias code already supported by
Millennium. The identifier is available for reference as may be required for HIPAA EDI
standard transactions, but as it is an optional item for those standard transactions (see
above) Millennium is typically involved with, Cerner has not seen much demand for its
support aside from Workman’s Compensation claims or identifying employers for
Medicare Secondary Payer (MSP) requirements.
The NPI is supported through a specified alias type for both personnel (for Type I NPIs)
and for organizations (for Type II NPIs). NPIs for individuals may be directly maintained
through the HNA User function used to build and maintain information about personnel
and users or through the Content Manager which supports uploading personnel and user
information in a batch mode. NPIs for organizations may be directly maintained through
the Organization Tool. If a client has organization subparts to be assigned Type II NPIs,
they must be defined as organizations on Millennium’s Organization Table. Like the
employer identifier, Cerner’s HIPAA EDI transaction processing will rely on the code set
value meaning of the alias type as the NPI unless the client has chosen to implement a
site defined alias type to support the NPI. Cerner has enabled the use of the NPI for all
standard claims formats including the ANSI X-12 v4010a 837 Institutional and
Professional electronic claims formats, the CMS 1500 claim format and the UB04 claim
format. Cerner has also enabled the use of the NPI for the ANSI X-12 v4010a 270
eligibility verification transaction formats. As of May 23, 2008, CMS no longer allowed
legacy identifiers to be submitted on any claims formats for Medicare, and other non-
Medicare payers are expected to similarly end their support for acceptance of legacy
identifiers under “dual use”. Cerner provided the ability to remove legacy identifiers for
all claims formats in a code package for ProFit by April, 2008. Guidance on this is
provided in Flash PR08-0031-0.
Taxonomy Codes
Also important as a result of the implementation of the NPI to replace legacy health plan
specific identifiers are the provider taxonomy codes. The taxonomy codes will likely
become much more significant for implementation in light of the need for health plans to
still obtain information about provider specialty and subspecialty that may have been
derived from the legacy identifiers prior to adoption of the NPI. Cerner supports the
taxonomy codes as a code set with content that is made available through Cerner’s
Knowledge and Content group. Clients interested in obtaining taxonomy content from
Cerner should open a service request to go to the Knowledge and Content group or may
download the taxonomy code set as a distribution package. The taxonomy package
currently available at any given point in time is documented in the quarterly HIPAA
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 8
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
medical code set and administrative code set content flash that is published to the Flashes
page at www.cerner.com. Cerner has enabled taxonomy codes to be sent on claims for
providers (including organization subparts) as required by the HIPAA EDI claims
formats. This is available on all current production versions of Millennium from 2005.02
forward.
Privacy
There is significant capability in Millennium to enable various aspects of support for the
provider organization’s response to patient rights towards their record and to manage
minimum necessary.
Minimum Necessary
This is not an exhaustive list per se, but is intended to be illustrative of the ways in which
Cerner’s common capabilities support minimum necessary concepts.
Patient Right s Towards Their Record
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 9
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Ancillary Care solutions may be involved in assisting the organization to fulfill certain of
these rights as discussed in that section of this document:
The patient has the right to receive and acknowledge the receipt of the provider
organization’s notice of privacy practices. The documentation of this
acknowledgement is ordinarily done through the provider’s registration system. If
Cerner is in the position of providing the registration solution to a client, Cerner
provides a code sets that can be used to capture this acknowledgement status. This
information can be made available as part of the common registration demographic
data set that can be shared through patient demographic inquiries as an informational
field. The function used for capture and storage of the acknowledgement status is
called the Privacy Status Manager. This is a common component that is available with
any implementation of Cerner’s common registration module and with Cerner’s
Revenue Cycle solution. This component also supports storing the acknowledgement
status historically should the patient change their acknowledgement status. The
function also includes a version control table for a client to maintain a registry of the
versions of their privacy policy in case they wish to maintain that information in the
system. The value of this table is that if an existing patient is seen on a date of service
subsequent to a change in the privacy policy, the registration conversations where the
acknowledgement status is captured will respond by requiring a update to the privacy
status for that patient. The acknowledgement status can be maintained at the visit
level, organization level or at the person level. The current value of the
acknowledgement status is always managed at the person level. The status is also
displayable in the Provide Care solutions for display in the patient demographics
panel within Powerchart and Powerchart Office or through Cerner’s common
registration module shared by all Provide Care solutions. See the uCern Reference
Page for Powerchart for more information on this capability.
NOTE: If the client also administers consent related to privacy, this same
functionality can support recording a consent status alongside the notice of privacy
practices acknowledgment.
The patient has the right as part of the acknowledgement process for the notice of
privacy practices to ask for a restriction of how their information may be used or
disclosed by the provider. This status can be a code set value for the code set
referenced above. As a part of the acknowledgement status, the code set will also
support documenting this restricted status if accepted by the provider, and comments
concerning the restriction may also be recorded. This code set value is displayed in
the Privacy Workbench within Cerner’s ProFile HIM solution so it is available for
reference for Release of Information (ROI) processing. The Privacy Workbench is
discussed more in the HIM section of this document below. A restricted status will
trigger a warning value in ROI processing so the HIM professional can be notified to
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 10
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
determine if there are any restrictions documented that may affect the particular ROI
request at hand.
For one specific case of restriction of consent, Cerner has completed work to enable a
patient to be able to deny access to their record for a named user. This is effective at
the level of a patient’s whole electronic medical record (e.g. at the person level). As of
Millennium 2007.18, this capability has been implemented to be effective for
accesses to Powerchart whereby the patient is selected from Person Search, accessed
directly using common person identifiers such as Medical Record or by name or
where accesses are attempted using a Patient Provider Relationship (PPR). Also as of
2007.18, Cerner expanded this capability to enable an override of the denial of access
to support emergency modes of access, and to enable audit of the use of the override.
Cerner is considering expanding the denial of access capability to affect other modes
of patient access (most notably from the Patient Access List) and to impact other
levels of access (most notably at the encounter level). The definition of the denial of
access is set up through the Relationship Management Tool. Information about this is
available on uCern in the Powerchart Reference Page.
ARRA HITECH provided for a specific flavor of the right to restrict consent to allow
patients to ask for a restriction of the disclosure of their record to a health plan if an
encounter or service was paid for out of pocket by the patient. Unlike the original
provision in the HIPAA Privacy rule for patient requested restrictions of consent, if
requested, providers must honor this type of restriction request. Cerner does not plan
to undertake specific development to address this requirement at present, but
recommends that clients consider implementing the ability mentioned above (and
discussed further below) to record a restriction of consent in order for the system to
support a procedural response to preventing a disclosure to the patient’s health plan in
the case of such a patient restriction of consent. We offer this approach for the
following reasons:
Under the original HIPAA Privacy Rule, the patient has the right to ask to inspect
their medical record held by the provider. If the provider wishes to fulfill this from the
electronic patient record, Medical Record Publishing (MRP) and Clinical Reporting
XR have been made available as common capability to support printing from the
electronic patient record. The functionality supports both printing for the purpose of
fulfilling release of information requests including patient requests for inspection as
well as for printing information for a provider’s own use. Both kinds of print events
are logged on a disclosure-tracking table, and a patient specific report can be printed
of disclosure events supported by MRP. This does not filter out non-reportable kinds
of disclosures for the accounting of disclosures noted below, but the report could be
customized to do so. See the Reference Page on uCern for Clinical Reporting on MRP
and on Clinical Reporting XR for more information.
Under ARRA HITECH, this patient right was expanded to include a right of access to
the patient medical record if held in electronic form. Under the meaningful use
requirements laid out by HHS, this may take the form of online access to the patient
record through a portal offered by the provider, through a Personal Health Record
(PHR) or through an electronic copy downloaded to media or made available through
secure messaging to the patient.
The patient has the right to ask that the provider amend the patient’s record based on an
error the patient believes in need of correction or based on a submission by the patient.
The provider has the right to accept or reject the patient request, but the provider must
document their response and the patient’s request in the medical record. Each solution
group has a manner of supporting error correction, amendment or submission. There is
not a single common function to do this apart from what exists in each solution.
Under the original HIPAA Privacy Rule, the patient has the right to receive an accounting
of disclosures for certain types of releases of information. These include disclosures made
for public health reporting, responding to a legal order, fulfilling a subpoena or making
other disclosures that are not related to the patient’s treatment or where the patient’s
authorization may have been required. Cerner presumes this is the province of a client’s
HIM solution or where ever release of information is supported. However, MRP and
Clinical Reporting XR as discussed above does allow for auditing of disclosures
supported through printing from the electronic patient record.
Under ARRA HITECH, the patient right to receive an accounting of disclosures was
expanded to include disclosures related to TPO if made from an electronic health record.
Cerner has examined Millennium’s structured means of output from the electronic health
record including printing, faxing, web based access, outbound system interfacing,
reporting using identifiable patient data and other means of output. Most of these
methods of output enable logging of information that can be useful for developing an
accounting of disclosures. Cerner has outlined recommendations for use of these logging
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 13
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
methods both in a whitepaper available under Solutions and Services/Enabling
Compliance/HIPAA on www.cerner.com, and through an Illuminations session presented
in March, 2010 which can be accessed for replay on the Illuminations page of
www.cerner.com. To summarize those recommendations, Cerner is pointing clients to
consider two main means of logging:
Cerner does not recommend that clients take the “raw data” of the various log functions
discussed in both the whitepaper mentioned above, and in the Illuminations session, and
give that directly to the patient as an accounting of disclosures, but use that log
information for “preprocessing” of log data in support of preparation of the accounting.
Certain information will only be implied at best from log information provided out of
Millennium for TPO related disclosure activity such as why the disclosure occurred when
for large scale transacting associated to clinical report distribution or to whom the
disclosure occurred (if not the user) for printing from Millennium for what may be taken
as for the provider’s own use. The system also will not be able to determine the
difference between internal use and external disclosure for many kinds of output events if
done by an end user. Careful consideration should be given for many of these types of
disclosure logs and data as to addressing questions of “why”, “to whom” and in some
cases, “of what”. The system will provide information as to the user, the date/time of the
event, a general indication of what which could supported by the name of a chart form, an
event name for an output event or other data, and in some cases, destination information
such as an output device, a fax number or a recipient IP address. More information on
Cerner’s recommendations is available in the whitepaper and Illuminations sessions
mentioned above.
The patient has the right to ask to be communicated with on a confidential basis by the
provider concerning matters of the patient’s care or condition. See Revenue Cycle section
for support of this right.
The patient has the right to ask that their presence in the provider’s facility not be
disclosed to the public, and that their name not be included in public directories such as
those used by the information desk or the switchboard. The support for this requirement
is administered through Cerner’s common registration module available for use with all
Millennium applications. In that module, capability is provided to allow for suppression
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 14
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
of patient information in the Patient Locater function within the common registration
module. This uses our visitor status code set to allow for patients who opt out of
informational directories to be suppressed from display in the functions we provide that
support those directories. This status can also be displayed in patient lists and organizers
within our PowerChart solution. This status code also may be used for other visitor or
delivery type restrictions that the patient may ask for.
Patient Right to Grant a Written Authorization for Releases of Information not related
to Treatment, Payment or Healthcare Operations or Where Permitted By Regulation
Without Patient Permission
As a general matter, a provider must get a specific written authorization from the patient
to disclose the patient’s information for purposes not related to care or not otherwise
permitted by law or regulation without the patient permission. The authorization itself is a
document that is signed by the patient and maintained with the medical record. See HIM
solutions for more information on how Cerner can respond to authorizations.
Security
Under the Security rule, the main application focuses for enabling compliance can be
summarized as the three “A’s” of authentication, authorization and auditing.
Authentication has to do with establishing the user identity, authorization has to do with
defining what a user can see and do with patient information and auditing has to do with
tracking and holding a user accountable for their accesses to a patient record.
Authentication
All Cerner applications share a common authentication security service that supports
unique user identification and the use of password or non-password based authentication
mechanisms. On the related matter of managing passwords and user accounts, Cerner’s
common security services shared by all solutions support many specific requirements that
are detailed in the uCern Reference Page for Security.
Cerner also supports a Millennium specific device level time out that can be used to
manage session suspension and termination. Time out policies can also be enabled for
use of Citrix.
Cerner also supports change user functionality to manage new user context when the first
user session is suspended or terminated in favor of the new user. Each Millennium
solution that implemented change user did so to suspend the former user session or to
terminate it, and to instantiate the new user’s authorization security context.
For use of non-password based authentication mechanisms, Cerner can support use third
party advanced authentication tools to support interoperability with client selected non-
password based methods. This is done through leveraging an appliance from a third party
called Imprivata that enables single sign-on and support for use of non-password based
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 15
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
authentication technologies. Imprivata has a specific set of such technologies that they
have certified for use with their appliance. More information on Imprivata is available
from Cerner’s DeviceWorks group.
Finally, Cerner supports context sharing for users and patients within our Powerchart
application in accordance with the Clinical Context Workgroup (CCOW) guidelines.
Cerner has a partnership with CareFX for support of this capability.
Cerner also has done initial implementations for moving user information out to an
LDAP compliant directory (using Microsoft’s Active Directory as a basis for the
directory), and Cerner has the capability to use that directory as an authentication
reference for Millennium rather than using current state domain specific authentication
services. Cerner also provides synchronization services for that directory to the personnel
table maintained within Millennium. This may become our point of interoperability with
external third party directories our clients may use for user provisioning. Cerner is
considering how to leverage this functionality also to inform Millennium’s Security
context of key user attributes that are used to apply access control policies within
Millennium such as for a user’s role or organization affiliation. This is under evaluation
as future enhancement activity.
Access Controls
The primary support for need to know at a common level for Cerner’s Millennium
solutions is the application of predominantly role based access controls within the
solutions appropriate to the anticipated use or disclosure of patient information for
treatment related purposes supported by the solutions. Each of Cerner’s solutions
includes the following foundation level access control attributes:
Beyond this, access controls particular to each solution group are discussed in each
solution section under Minimum Necessary and under Access Controls as applicable.
For a fuller description of access control capabilities, see the uCern Reference Page for
Security, and the Security topic of any solution specific uCern Reference Page.
Auditing
o Predefined retrospective views into the access audit log including but not
limited to by patient, by user, by visit, by VIP patient, by device ID, by
confidential visit and by access audit event type.
o Ad hoc browsing, searching and filtering both within the above retrospective
views and through site defined views using other data elements as selection
and filtering criteria
o Segregation of duty between the Security or Privacy auditor and the system
administrator for the audit log
o Audit logging of end user activities within the audit log itself
o Site defined retrospective views and case studies used for special
circumstances for compiling evidence based on a set of predefined criteria
such as accesses to a specific patient record by a specific user or of VIP
patients by a specific user
Information on both the auditing functionality in Millennium and the P2 Sentinel solution
is available in the in uCern Reference Pages for Security.
Technical Security Guidance from HHS – Safe Harbor for HHS and FTC Breach Notification Rules
As a part of ARRA HITECH, both HHS and the Federal Trade Commission (FTC)
adopted breach notification rules for breaches involving personal health information held
in identifiable form in both EHRs and PHRs. Also under ARRA HITECH, HHS was to
develop technical security guidance that if complied with in a literal, prescriptive manner,
a provider could fall under safe harbor protections relative to both breach notification
rules from having to notify affected individuals in the case of a breach. The technical
security guidance called for encryption of both data in transit when communicated across
a network and for data at rest when stored on storage devices ranging from removable
media to end user devices to backend storage systems. Cerner has developed a guidance
paper on encryption capabilities enabled across the various segments of the technical
computing infrastructure from end user computing to backend storage and offline storage.
This guidance paper is available at www.cerner.com under Solutions and
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 17
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Services/Enabling Compliance/HIPAA. It also is available through the Compliance uCern
group.
Ancillary solutions
Ancillary solutions have more of a supporting role for HIPAA compliance than do some
other solution types in that they play more of an indirect role in enabling EDI and Privacy
related compliance. They do bear direct responsibility for supporting such requirements
as need to know and auditing for end user operations carried out within them. Cerner has
taken this perspective in defining the requirements for Support Care solutions as defined
previously for HIPAA compliance.
EDI
For Ancillary solutions, the role to enable compliance with the EDI standard transaction
set mainly revolves around providing service charge related information through a
financial interface to the systems that are directly engaged in sending or receiving
standard transactions. As ancillary systems are not ordinarily directly engaged in sending
or receiving standard transactions, it is not a requirement that these solutions have to
directly support the use, storage or transmission of any information in a standard
transaction format. These solutions must be able to identify service related charges, and
make use of standard medical code sets such as CPT, HCPCS or ICD-9 if appropriate for
identifying services, procedure codes and diagnosis information.
Current Capability
All of Cerner’s Support Care solutions support the use of medical code sets for the
identification of services, procedures and diagnosis. Further, each of Cerner’s Support
Care solutions support the sharing of this information through a financial interface with
the client’s billing system if not a Cerner solution and with ProFit if a Cerner solution.
One additional consideration to this is for the PharmNet Retail application. PharmNet
Retail enables transacting in the NCPDP Telecomm v.5.1 transaction standard for claims
and eligibility transacting for retail pharmacy activity. Support for the NCPDP D.0
transaction standards will be enabled on 2010.01 and 2010.02. Packaging is under
consideration to make this available on 2007.19 as well.
Privacy
For compliance support for the Privacy rule, the main role for Ancillary solutions is to
enable minimum necessary policies as to the use of patient information for treatment
related purposes or for use or disclosure of patient information for payment or healthcare
operation related purposes. There also may be a secondary role in supporting certain of
the patient rights towards their information.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 18
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Current Capability
The primary support for need to know in Ancillary solutions is the application of
predominantly role based access controls within the solutions appropriate to the
anticipated use or disclosure of patient information for treatment related purposes
supported by the solutions. Each of Cerner’s Ancillary solutions includes the common
capabilities described previously.
Privileges to carry out specific tasks on patient clinical information have not been
implemented in Cerner’s Ancillary solutions for the simple reason that the application
tasks within each solution are usually very specific as to the operation supported (e.g.
accessioning in the PathNet, exam study interpretations in RadNet), and to the data type
accessible (microbiology activity types in Microbiology result entry). Particular
operations to be performed on a given procedure are routed to performing sites within
ancillary departments based on routing or business logic appropriate to the function of the
application solution at hand. So for example, based on the relationship between where the
patient has been registered and where a given activity type is to be performed for orders
placed on patients registered to a particular location, the perform task associated to that
procedure is routed to a particular work queue. As of 2003.01 (see below), capabilities
have been added to manage access to the work queue itself, but privileges to perform
particular operations on a procedure are not needed when access to task and work site are
managed.
Cerner’s ancillary applications for Radiology, Laboratory and also Cerner’s Surgery
solution all do make use of an access control to manage access to performing sites
(known as service resources within Cerner’s Support Care solutions). A user is associated
to the specific sections/sub departments or individual service resources to which the user
should have access. This limits affected users to be able to access clinical information for
performing, verifying or inquiry activity to those service resources they have rights to if
the access path is organized around or filtered by the service resource. This would include
access paths to data through accession numbers, case numbers, ordered procedures, visits
and the service resources themselves.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 19
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Patient Right to Receive and Acknowledge a Notification of Privacy Practices
The patient has the right to receive and acknowledge the receipt of the provider
organization’s notice of privacy practices. The documentation of this
acknowledgement is ordinarily done through the provider’s registration system. At
this time, the storage of this acknowledgement status as a code set is supported. See
the common section on Privacy for more information on this capability. This
information can be made available for sharing with the Ancillary solutions either by
interfacing (if the registration system is not Cerner’s Revenue Cycle solution) or
through Cerner’s Revenue Cycle solution. This acknowledgement status can be made
available for display in an inquiry task through Cerner’s common registration module
shared by all Support Care solutions.
The patient has the right as part of the acknowledgement process for the notice of
privacy practices to ask for a restriction of how their information may be used or
disclosed by the provider. As a part of the acknowledgement status enhancement
mentioned previously, a code set value will support documenting this restricted status
if accepted by the provider, and comments concerning the restriction may also be
recorded.
The Ancillary solution may be used to help fulfill a patient right to inspect their
record especially in cases where the ancillary provider is operating in a standalone
mode such as a reference lab or an imaging center. In these occasions, the functions
used to produce clinical reports may also be used to fulfill patient inspection requests.
A provider would need to consider what clinical report format may be appropriate to
this purpose.
The Ancillary solution may also be used to amend a patient record in response to an
accepted amendment request. Error correction tasks within each Ancillary solution
are available to help with this purpose. If the patient request to amend is a
submission, and not a error correction, this information may be documented through
use of appropriate result entry or document entry functions. The organization’s
response to the patient request may be documented through a document entry
function as a specialized result entry type if it must be captured in the Ancillary
solution record. Ordinarily, it will be more appropriate to scan in the patient request
and the organization’s response as a clinical document through Cerner’s ProVision
Document Imaging solution or to consider using clinical note entry available with the
Direct Patient Care solutions as available to manage response to this patient right.
Cerner’s Ancillary solutions are not ordinarily the source for a public directory. The
support for this requirement is administered through Cerner’s common registration
module available for use with all Millennium applications as described in the
common capabilities section of this document under Privacy – Opt Out.
Authentication
Auditing
Similar to Ancillary solutions, Direct Patient Care solutions also have more of a
supporting role for HIPAA compliance than do some other solution types in that they play
more of an indirect role in enabling EDI and Privacy related compliance. They do bear
direct responsibility for supporting such requirements as need to know and auditing for
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 21
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
end user operations carried out within them. Cerner has taken this perspective in defining
the requirements for patient care solutions as defined previously for HIPAA compliance.
EDI
For Direct Patient Care solutions, the role to enable compliance with the EDI standard
transaction set mainly revolves around providing service charge related information
through a financial interface to the systems that are directly engaged in sending or
receiving standard transactions. As patient care systems are not ordinarily directly
engaged in sending or receiving standard transactions, it is not a requirement that these
solutions have to directly support the use, storage or transmission of any information in a
standard transaction format. These solutions must be able to identify service related
charges, and make use of standard medical code sets such as CPT, HCPCS or ICD-9 if
appropriate for identifying services, procedure codes and diagnosis information.
Current Capability
All of Cerner’s Direct Patient Care solutions support the use of medical code sets for the
identification of services, procedures and diagnosis. Further, each of Cerner’s Direct
Patient Care solutions support the sharing of this information through a financial interface
with the client’s billing system if not a Cerner solution and with ProFit if a Cerner
solution.
Privacy
For compliance support for the Privacy rule, the main role for Direct Patient Care
solutions is to enable minimum necessary policies as to the use of patient information for
treatment related purposes or for use or disclosure of patient information for payment or
healthcare operation related purposes. There also may be a secondary role in supporting
certain of the patient rights towards their information.
Current Capability
The primary support for need to know in Direct Patient Care solutions is the application
of predominantly role based access controls within the solutions appropriate to the
anticipated use or disclosure of patient information for treatment related purposes
supported by the solutions. Each of Cerner’s Direct Patient Care solutions includes the
following access control attributes beyond the common access controls discussed earlier:
Access to the patient’s electronic medical record based on the user’s care
providing relationship to the patient, association to the location of the patient’s
care or based on other modes of relationship creation by proxy or self declaration
as defined by client use of the solutions
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 22
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
For purpose of self declaration of relationships if allowed by client policy, access
to patient visits based on a user’s association to the organization where the patient
is seen
Access to clinical results and documents for inquiry purposes based on result
viewing privileges associated to the user’s position or care providing relationship
to the patient
Access to orderable procedures and services for order entry, order inquiry or order
verification purposes based on order privileges associated to the user’s position or
care providing relationship to the patient
Access to person level clinical data including allergies, diagnosis, procedures,
problem list, immunizations and medications for modifying or inquiring into this
information based on privileges. Like other privileges, these privileges can be
associated to the user’s position or care providing relationship to the patient.
Printing through MRP limited to what a user is able to access online
An emergency mode of access is available to users if there is need to be able to
see an expansion on the electronic patient record available for viewing under
emergency care circumstances. Associating an emergency relationship type to the
user’s position facilitates the access, and the access can be implemented to
override organization based access controls to patient visits and confidentiality
levels operative against visit access as needed. Privileges appropriate for the
emergency mode of access can be defined just as for any other relationship type.
Requirements for emergency operation are supported through an adapted version
of Powerchart called Powerchart 7x24 Access. This enables access to the
electronic medical record during downtime for unplanned downtimes to facilitate
continued record access. This is intended for shorter term service disruptions. If
longer term disruptions occur, clients should consider those as part of the planning
to be addressed by contingency plans for business continuity and disaster
recovery.
An administrative tool called the Relationship Management Tool has been made
available to allow for creation of user/patient relationships on an ad hoc basis to
cover lower volume needs such as needs to support access to the chart by internal
or external auditors, quality management personnel, peer review personnel and
the like. This tool can also be used to manage (expire, renew or establish)
relationships from a patient or a provider personnel perspective. Finally, this tool
can be used to implement a denial of access for a given patient record effective
against a named end user.
A specialized mode of patient list has been implemented available to Powerchart
or Powerchart Office to allow for leveraging a provider’s active or historic
relationship to patient in granting access to support staff users such as physician
office billers. The patient list is granted to the user with a predefined set of
qualifying parameters that can limit what the end user can enter to generate the
list. The patient list can also cross organizations so as to override organization
based visit access controls. So if a biller is responsible for professional component
billing for a physician both for office based services, and for clinic based services,
the biller can be given a access path that overrides organization based security
only where the biller’s physician has had a relationship to the patient visit at the
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 23
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
office or the clinic. This mode of list can be used for other similar types of
accesses
Support for Denial of Access to a named user for a specific patient record with
support for override of the denial of access for emergency situations
Other privileges beyond the above to carry out specific perform type tasks on patient
clinical information have not been implemented in Cerner’s Direct Patient Care solutions.
This is because minimum necessary and need to know is managed based upon the
system’s understanding of a user’s relationship to a patient or a care location, and how
clinical activity is routed to the user or the care location based on routing logic within the
solution (e.g. tasks that represent documents to sign for a physician can be routed to the
physician based on the care providing relationship to the patient).
Direct Patient Care solutions have a supporting role in assisting a provider to respond to
patient rights towards their record under the Privacy rule. Cerner has made the
presumption that the responsibility to record, track and document fulfillment of the
patient request under any given right is the function of the HIM solution discussed below.
Direct Patient Care solutions may be involved in assisting the organization to fulfill
certain of these rights including the below:
The patient has the right to receive and acknowledge the receipt of the provider
organization’s notice of privacy practices. The documentation of this
acknowledgement is ordinarily done through the provider’s registration system. At
this time, the storage of this acknowledgement status as a code set is available for
display in Powerchart. See the common section on Privacy for more information on
this capability. This information can be made available for sharing with the Provide
Care solutions either by interfacing (if the registration system is not Cerner’s Revenue
Cycle solution) or through Cerner’s Revenue Cycle solution. This acknowledgement
status can be made available for display in the patient demographics panel within
Powerchart or through Cerner’s common registration module shared by all Direct
Patient Care solutions.
The patient has the right as part of the acknowledgement process for the notice of
privacy practices to ask for a restriction of how their information may be used or
disclosed by the provider. As a part of the acknowledgement status enhancement
being beta tested mentioned previously, a code set value will support documenting
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 24
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
this restricted status if accepted by the provider, and comments concerning the
restriction may also be recorded.
The Direct Patient Care solutions may be used to help fulfill a patient right to inspect
their record especially in cases where the patient care provider is the party receiving
the request. Procedurally, Cerner recommends such requests be documented for
tracking and fulfillment in the same manner as requests made of the provider’s HIM
department. In these occasions where it is necessary to fulfill the request from the
patient care team perspective, Cerner has integrated Medical Record Publishing
(MRP) into Powerchart as an accessible task that can be used to fulfill the request
from the electronic patient record. MRP uses the same report format capabilities as
clinical reporting, and can be defined to support a patient request for inspection for
the clinical result and document sections of the record. MRP can also be used to print
information for a clinician’s own use. Both types of print events are logged to an audit
table of disclosures maintained by MRP. On releases of 2007.19 and higher, this
capability is provided through Clinical Reporting XR. A provider would need to
consider what clinical report format may be appropriate to both purposes.
In order to produce an electronic copy of the record, this same capability may be used
to render a .pdf file or as of 2007.19.11, there is new capability to do a direct output
to media of an electronic copy of the patient record using the HL7 CDA Continuity of
Care Document (CCD) format as is discussed in the common Privacy section above.
The Direct Patient Care solutions may also be used to amend a patient record in
response to an accepted amendment request. Error correction tasks within each Direct
Patient Care solution are available to help with this purpose. If the patient request to
amend is a submission, and not a error correction, this information may be
documented through use of appropriate result entry or document entry functions. The
organization’s response to the patient request may be documented by scanning in the
patient request and the organization’s response as a clinical document or to consider
using clinical note entry available with the Direct Patient Care solutions to manage
response to this patient right.
Many Direct Patient Care solutions will be involved in releasing patient information
for the fulfillment of regulatory or statutory reporting requirements. They also may be
involved in support of release of information for other purposes. In those areas where
the patient has the right to receive an accounting of disclosures as defined by the
Privacy rule, Cerner’s Direct Patient Care solutions can have logging capability to
report the disclosures through MRP or Clinical Reporting XR as mentioned above.
Cerner also suggests using the functionality outlined in the HIM solution section for
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 25
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
the accounting of disclosures. Additionally, Cerner recommends that for meeting the
ARRA HITECH requirements for the accounting of disclosures to consider using the
Core Audit Services discussed in the common Privacy section above under the
inspection right to provide logging for output events from Millennium. These events
can be logged outbound to P2 Sentinel or to a third party audit data mart or
repository.
Direct patient care departments may be in the position to support sending patient
information directly to the patient under certain conditions such as to fulfill the
inspection request above or to release information directly to the patient to fulfill a
patient authorization request. Cerner’s Direct Patient Care solutions do not offer any
particular functionality to directly automate the mailing of such information to a
designated patient destination or for providing a patient an electronic copy of their
record at present although secure messaging is under consideration for enhancement.
The functionality discussed in the common Privacy section above for the inspection
right to an electronic copy of the patient’s record discusses some options using
Clinical Reporting to provide an electronic copy. At this time, manual intervention is
required to support such requests if not to the main patient or provider addresses
understood by Cerner’s Clinical Reporting solution.
Cerner’s Direct Patient Care solutions are not ordinarily the source for a public
directory, but the patient care team usually must understand any patient requested
restriction on the disclosure of the patient’s presence in a provider’s facility. The
support for this requirement is administered through Cerner’s common registration
module available for use with all Millennium applications as discussed in the
common section above for Privacy and Opt Out. Display of this opt out condition
within the patient lists is available for use.
Authentication
Access Controls
The access controls implemented within Cerner’s Providing Care solutions were
discussed in the Minimum Necessary topics under Privacy above.
Auditing
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 26
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Revenue Cycle solutions bear a direct role in support of the HIPAA standard transactions
under the Transactions and Code Set Rule. These solutions are usually directly engaged
in sending and receiving of standard transactions. At a minimum, these solutions have to
provide the content for standard transactions outbound, and use information from
standard transactions inbound to store important processing statuses or outcomes from
operations related to standard transactions. Revenue Cycle solutions, particularly for
Access Management, are closely involved in supporting aspects of Privacy compliance
including the capture of the privacy statuses and permissions associated to the patient
record. In the area of Security, they play a similar role to any other solution to provide
appropriate levels of access control and access audit logging for end user operations they
automate.
EDI
Current Capability
Support for capture of the required patient demographic data set appropriate for
capture through registration that are necessary to support standard content for
HIPAA EDI formats per the amended v. 4010a transaction standards.
Support for use of standard identifiers for provider, employer and health plan as
aliases to Cerner’s internal identifiers for these reference data objects
Through integration between Registration Management and Eligibility
Management, support for generation of the standard transaction outbound for
eligibility and receipt inbound of the results of the payer response to the eligibility
solicitation
Support for use of the Referral Certification and Authorization transaction as of
2007.19
Support for the filing of electronic institutional and professional claims using the
standard transaction formats per the amended v. 4010a transaction standards
Support for the receipt of inbound electronic remittances per the standard
electronic transaction format
The implementation experience to date with HIPAA standard transactions has been
limited to processing them inbound or outbound through a client selected clearinghouse
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 27
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
or engine type solution that actually takes the content of the transactions and puts them
into standard format for submission or out of standard format for inbound processing.
Cerner supports the claims status inquiry transaction within ProFit. Support for the
referral certification and authorization transaction is under review by the Access
Management team, but an availability target is not defined.
Cerner will enable support for the new version of HIPAA EDI (v.5010) that has a
compliance date of January 1, 2012 on 2007.19 (as of SP 10) and 2010.01 (as of SP5) for
all above referenced transactions.
Cerner is planning to support ICD 10 for the Revenue Cycle solutions in a generally
available manner by early 2012.
Privacy
For compliance support for the Privacy rule, the main role for Revenue Cycle solutions is
to enable the capture and display for inquiry purposes of the privacy statuses of the
patient record. Business office applications also must support minimum necessary
policies as to the use of patient information for treatment, payment or healthcare
operations or for disclosure of patient information for payment or healthcare operation
related purposes. There also may be a secondary role in supporting certain other patient
rights towards their information.
Current Capability
The primary support for need to know in Revenue Cycle solutions is the configurable
support for the design of registration conversations, inquiries and patient searches that
can be defined as application tasks appropriate to the roles of particular types of users.
Additionally, the application of predominantly role based access controls within the
solutions appropriate to the anticipated use or disclosure of patient information for
treatment related purposes are supported. Cerner’s Revenue Cycle solutions include the
following access control attributes beyond the common capabilities mentioned earlier:
Privileges for what types of charge activity a user may enter, modify or inquire
against based on the activity type of the charge
Privileges for what types of services and service locations a user may schedule
Access to patient account information based on the relationship between the user
and the business entity where the patient has been registered (or where the
patient’s account is being managed)
The patient has the right to receive and acknowledge the receipt of the provider
organization’s notice of privacy practices. The documentation of this acknowledgement
can be done through Registration Management as described in the common section
earlier. The document carrying the patient’s acknowledgement can be scanned in through
ProVision Document Imaging as a person or visit level document so that it can be made
accessible for reference through the document image viewer available with that solution.
This type of support also can be applied to any consent forms or other administrative
documents generated from the registration process and associated to the person or the
encounter level as may be appropriate.
The patient has the right as part of the acknowledgement process for the notice of privacy
practices to ask for a restriction of how their information may be used or disclosed by the
provider. As a part of the acknowledgement status capability discussed earlier, a code set
value will support documenting this restricted status if accepted by the provider, and
comments concerning the restriction may also be recorded.
Under ARRA HITECH, the patient has the specific right to ask that their information not
be disclosed to their health plan for a self pay encounter or service. This may be
particularly impactful for release of claims attachments to health plans. See the common
Privacy section above for suggestion as to how Millennium can enable compliance with
this requirement in combination with a client’s release of information management
policies and practices.
The Revenue Cycle solutions will not usually be the place used to help fulfill a patient
right to inspect their record although the request may be received through the front office
of the provider organization. Procedurally, Cerner recommends such requests be
documented for tracking and fulfillment in the same manner as requests made of the
provider’s HIM department. In these occasions where it is necessary to fulfill the request
from the business office perspective, Cerner has integrated Medical Record Publishing
(MRP) and Clinical Reporting XR (recommended with 2007.19) into Powerchart as an
accessible task that can be used to fulfill the request from the electronic patient record. As
of 2007.19.11, an electronic output using the HL7 CCD format is also supported. The
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 29
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
client could consider giving a responsible party in the front office or back office as
needed access to Powerchart to use MRP, Clinical Reporting XR or the CCD output
capability to fulfill such requests if not performed through HIM. MRP and Clinical
Reporting XR uses the same report format capabilities as normal clinical reporting, and
can be defined to support a patient request for inspection for the clinical result and
document sections of the record. MRP and Clinical Reporting XR can also be used to
print information for a provider’s own use. Both types of print events are logged to an
audit table of disclosures maintained by MRP and by XR. A provider would need to
consider what clinical report format may be appropriate to both purposes.
The Revenue Cycle solutions may also be used to amend a patient record in response to
an accepted amendment request for correction of patient demographics. Update
conversations within each Revenue Cycle solution are available to help with this purpose.
Beyond performance of the correction if accepted, the organization’s response to the
patient request may be documented by scanning in the patient request and the
organization’s response as a patient document.
Many Revenue Cycle solutions will be involved in releasing patient information for
the fulfillment of regulatory or statutory reporting requirements. They also may be
involved in support of release of information for other purposes. In those areas where
the patient has the right to receive an accounting of disclosures as defined by the
Privacy rule, Cerner’s Revenue Cycle solutions can leverage the logging capability to
report the disclosures through MRP or Clinical Reporting XR as mentioned above.
Cerner also suggests using the functionality outlined in the HIM solution section for
the accounting of disclosures. Additionally, Cerner recommends that for meeting the
ARRA HITECH requirements for the accounting of disclosures to consider using the
Core Audit Services discussed in the common Privacy section above under the
inspection right to provide logging for output events from Millennium. These events
can be logged outbound to P2 Sentinel or to a third party audit data mart or
repository.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 30
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
consent, release of information processing, making decisions about patient care and
other matters appropriate to such a legal appointment.
Security
Current Capability
Authentication
Access Controls
The access controls implemented within Cerner’s Revenue Cycle solutions were
discussed in the Minimum Necessary topics under Privacy above.
Auditing
HIM solutions
HIM solutions directly support automation of the provider’s response to patient rights
under the HIPAA Privacy rule. They also play a significant role in the auditing of how a
patient’s record may be used or disclosed by the organization for the purpose of
monitoring compliance by organizational staff with its privacy policy. HIM solutions play
a secondary role in EDI through the support of medical code sets for coding of diagnosis,
procedures and services for communication to the financial system responsible for billing
activity.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 31
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
EDI
Cerner’s ProFile HIM solution plays a support role in support of standard transactions
particular for coding of diagnosis, procedures and services for purpose of supplying
medical code set information (ICD9, CPT and HCPCS) to the responsible billing system
for use in generating electronic claims for submission to the payer. The HIM solution is
not directly involved in standard transaction transmission or receipt.
Support for capture medical code sets for diagnosis and procedure coding content
supportive to HIPAA EDI formats for institutional or professional claims per the
amended v. 4010a transaction standards.
Integration with DRG and APC groupers for coding editing
Integration with core Charge Services for review of coding information derived
from upstream sources
Integration with ProFit Patient Accounting for notification of final bill trigger
events so claims processing can occur
ProFile will enable support for coding in ICD 10 CM and ICD 10 PCS timely to the
compliance date as part of the effort to make ICD 10 enabled capabilities available by the
first generally available release target in 2012.
Privacy
For compliance support for the Privacy rule, HIM solutions bear the primary role to
enable the workflow surrounding the provider organization response to patient rights.
Cerner provides capabilities to help enable Privacy compliance through a combination of
common functionality available for use in any Millennium implementation and through
Cerner’s ProFile HIM solution.
Current Capability
Minimum Necessary
The primary support for need to know in HIM solutions are to manage access to the
patient record for HIM and other record management purposes based on the organization
where the patient record is maintained electronically. Cerner’s HIM solution and related
privacy automation supports this through:
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 32
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
Patient Rights Towards Their Record
HIM solutions have the primary role in assisting a provider to respond to patient rights
towards their record under the Privacy rule. HIM solutions often are the main point of
management of the organization’s response to the patient rights under the Privacy rule.
The HIM solution is not usually directly used to amend a patient record in response to an
accepted amendment request for correction or submission. Cerner recommends that the
clinical or Revenue Cycle solution that is the source of the information subject to
correction be used to actually perform the correction. The HIM department can use
Cerner’s ProVision Document Imaging solution to capture the document carrying the
patient request and the organization’s response or the provider could consider using
Cerner’s clinical document entry functionality to create document types for such
purposes.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 33
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
ProFile’s ROI module can also play a role in helping meet the obligation for the
organization to provide a patient with an accounting of disclosures. ROI can be used to
define the structure of a paper or electronic chart by organization. ROI can be used to log
release of information requests by release type, and it can also be used to track fulfillment
of the request. At the time of fulfillment, the part of the chart subject to release can be
marked. ROI provides for capture of the audit data set appropriate to a disclosure log for
Privacy rule related requirements. Use of specific release types can help provider track
reportable disclosures to the patient. ROI supports generation of a patient specific report
of disclosures. The disclosure report can be customized to only report those release types
a provider wishes to make reportable. A provider can consider deploying ROI for use at
those release points in the organization authorized to fulfill ROI requests thereby
centralizing the tracking tools without necessarily centralizing all release request
processing to one department.
If MRP or XR is used for reporting disclosures from the electronic patient record, it also
can generate an accounting of disclosures inclusive of the necessary content for the
accounting to the patient. This capability will likewise be enabled for releases done using
a CCD format through the Clinical Document Generator.
See Privacy section under the Revenue Cycle solutions part of this document.
Patient Right to Grant a Written Authorization for Releases of Information not related
to Treatment, Payment or Healthcare Operations or Where Permitted By Regulation
Without Patient Permission
Cerner’s ROI module within ProFile can be used to process patient authorization
requests. Authorizations can be designated for particular release types, and the requests
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 34
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
managed and tracked similar to other release requests. The authorization document itself
can be scanned in through Cerner’s ProVision Document Imaging and associated to the
patient or visit to which it is associated. The authorization can be viewed on line through
Document Imaging’s document viewer task. If the authorization is to be fulfilled from the
electronic patient record, MRP may be used to fulfill the request. As stated above, there is
integration between ROI and MRP to update the request status as logged into ROI from
the MRP print event. MRP also allows for sensitive sections of the clinical report format
used for processing release of information requests to be marked as such so that when the
HIM professional is identifying information to be printed to fulfill the request, the HIM
professional has to specifically select sensitive areas of the record to be included in the
output. Otherwise, sensitive information will not be included for printing.
Cerner also integrates into the Privacy Workbench a function within ProFile called
Patient Request Tracking to offer a recording, tracking and queue management function
to manage patient requests of all kinds under the Privacy rule including those relating to
rights to inspect, rights to amend, rights to receive an accounting of disclosures, rights to
request confidential communications and rights to request restrictions. This function
allows an organization to monitor service levels for responding to these requests where
required under regulation, and to generate correspondence to the patient concerning the
organization’s response under those rights that require a written response to the patient. .
Security
Authentication
Access Controls
The access controls implemented within Cerner’s HIM solutions were discussed in the
Minimum Necessary topics under Privacy above.
Auditing
Claims Attachments
As of the date of this white paper, there is a proposed rule for an EDI standard transaction
for claims attachments. There are six proposed types of attachments for reporting
Laboratory results, providing Emergency Department documentation, reporting
Rehabilitation Services, providing Ambulance documentation, providing Clinical Reports
and providing Pharmacy medication records. The attachments will require specific sets of
LOINC codes to both ask the question and provide for the response. Cerner is looking at
the solution requirements apparent with the different ways that claims attachments may
be implemented – both as “solicited” (payer generated questions) and “unsolicited”
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 35
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner
(generated by the provider with a health care claim in anticipation of need) attachments,
and in formats ranging from human readable scanned documents or text to computer
readable discrete values. Processing may range from generating attachments directly
from the EMR within Millennium to generating interface requests outbound to other
systems to responding to such requests from other systems. For more information on
Claims Attachments, see the white paper on Claims Attachments available under the
HIPAA link on the Solutions and Services page of cerner.com. As the proposed rule
moves towards finalization, Cerner will make appropriate plans to enable compliance
with its requirements. A final rule compliance date is unknown.
Cerner Reference Pages are available on uCern for Security, Access Management Core
Patient Registration/Management, Powerchart, Clinical Reporting and ProFile.
Information is available in the Reference Page for Win32 Microsoft Word based Clinical
Reporting on Medical Record Publishing
Information on the Core Audit Services is available in the Security Reference Page
Previous analysis white papers on HIPAA Privacy and Security rules, the National
Provider Identifier, the Employer Identifier, the proposed Claims Attachment Rule, the
Breach Notification Rules for EHRs and PHRs, the Accounting of Disclosure
Requirements of ARRA HITECH and the Technical Security Guidance from HHS are
available at Solutions and Services/Enabling Compliance/HIPAA at www.cerner.com.
Cerner Corporation. All rights reserved. This document contains Cerner confidential and/or 36
proprietary information which may not be reproduced or transmitted without the express written
consent of Cerner