Implementing Electronic Signatures

Implementing Electronic Signatures

Ann Geyer

Tunitas Group

ageyer@tunitas.com

Mike Davis

VHA / SAIC

mike.davis@med.va.gov

Topics Covered

– Signature purposes – Enabling legislation

 Risk Definition

– E-sig Error Types – Risk Measures

 Risk Management

– Threats

– Compensating Controls

 Assurance Levels and Requirements  Framework in Action

E-sig Background

Purposes



Definitions

Relevant Law

The Role of Signature



Signature is a mechanism for memorializing an act

– Actor may be practitioner, consumer, …or automated process



Signature is an important workflow component

• Purchase order, Clinical Order, Prescription

– Approval / authorization to proceed / dispense • Patient consent, Quality check



Signature is of primary value for dispute resolution

Electronic Signature



Is a mechanism for recording, in electronic form,

US ESIGN Act of 2000



Establishes the validity of e-signatures



Gives e-signatures equivalent legal status to

handwritten or other forms of signature

– Signature validity cannot be denied simply because it is in an electronic format

– Same legal test of validity for both handwritten and electronic signatures



Requires agencies to rewrite their statutes

– Expressly permit e-signatures wherever signatures are required

What is an electronic signature?

From ESIGN

– “An e-signature is any electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record”.

Electronic Signatures in Global and National Commerce Act (ESIGN) -- US Public Law 106-229



Technology neutral definition

– Intended to permit many different implementations, for example

• Digital signatures (using asymmetric cryptography)

• Unique ‘signature code’ / PIN

(JCAHO, Medicare COP, State laws)

• “Click through” agreements ( with or without user authentication)

• Sound recording (wav file) of speaker’s approval agreement / affirmation, etc

Intent



Attribution

– E-signature can be attributed to a person if signature results from an act of that person.

– Demonstrated by any means,

“including a showing of the efficacy of any security procedure applied to determine the person to which the electronic record or e-signature was attributable.”

Uniform Electronic Transactions Act (UETA) 

Assertion

– Ability to assert the e-signature depends on the quality of the implemented security controls

Technology Neutrality



Compelling Government Interest Exception

– ESIGN prohibits state, federal agencies, or courts from mandating the use of any specific e-signature technology – Except where there is unique feature of technology that

serves a compelling government interest 

Party to the Transaction

– Different rules apply where the gov’t agency is a participant in the transaction

• Examples

– Medicare reimbursement related transactions & documents such as Certificates of Medical Necessity (for DME or dialysis)

– Documents related to state medical licensing

– High Volume Federal Forms

• Federal agencies must adopt e-signature for any form with > 50K fillings / year …. Government paperwork Elimination Act (GPEA)

– Must support multiple technology alternatives,

– Cannot mandate the use of specific vendor solutions. – Slow rate of compliance by most agencies

Net Guidance from ESIGN

– With a few consumer protection exceptions, e-signatures can be used in place of handwritten ones

 No Government Mandate to Use

– Organization not required to use e-signatures

– Free to chose their own e-signature approach

 No safe harbor

– No gov’t endorsement for any particular electronic signature or electronic signature technology

• Caveat: In a few states, in very restrictive circumstances, some presumption of validity given to digital signatures (Illinois, Utah, Washington)

 Organization Bears Risk for Repudiation

– Org is responsible for defining a process that withstands responds to its repudiation risk

E-sig Risk Management

Types of Risk



False Assertion

False Repudiation

Threats & Controls

Why E-sig Risk Assessment is Important

Signatures are critical business/legal control measures

– Bases for treatment, payment, operations, compliance, performance and defenses



Limited legal or industry guidance

– Considerable implementation flexibility

– Standard practice may provide little assurance (JCAHO IM) – Some standards are rarely implemented (digital signatures)



Loss potential is high

– Fraud and abuse, malpractice litigation – Medical licensing issues

Unique E-sig Risks

Signature Intent No signature Intent

Successful assertion OK RISK (false assertion) Successful repudiation RISK (false repudiation) OK

(quality control issue)

 False Assertion

– Attributes an e-signature where there was no signer intent

 False Repudiation

False Assertion (Examples)



Hospital improperly attributes an electronic medication

order to a named practitioner

– Patient safety issues

– Practitioner dissatisfaction



Health plan accepts forged signature on certificate of

medical necessity for durable medical equipment

– Fraud related financial loss – Sarbanes-Oxley concern



Hospital records unsigned clinical notes … as if they

were signed

– Potential prejudicial impact to patient….

especially when notes not intended to be disclosed as part of ‘legal’ record

False Assertion Risk



Failure of operational controls

– Impersonation of the purported signer, or – Record modification after signing



Consequences of false assertion

– Not immediately apparent to party relying on signature – May be limited to the impacted transaction

• Can the transaction be revoked? at what cost?

Common Threats

Leading to False Assertion

Subject / signer Impersonation

– Someone other than named signer uses that person’s signature capability, for example, by

• Permissive sharing of signature code with staff

• Insecure user provisioning (creation, distributions, renewal)

• Compromise of signer database

• Insecure transmission of signature code

• Compromise of (private) signature key in digital signature system 

Modification of a signed record

– Insecure storage or transmission of the record subsequent to signature, e.g.

• Database corruption

• Administrative error

False Assertion Controls

Authentication

– Reduce opportunities for impersonation

– Some competitive technologies commonly considered • Cryptographic signature keys

– Unique ‘private’ key that cannot be removed from cryptographic module

• Multi-factor authentication requiring possession of the crypto module and knowledge of PIN / passphrase required for key invocation (i.e, PKCS#11 model)

• Biometrics

– “Signature dynamics’”

• Handwriting invariants recorded using an ‘electronic stylus’

• Signature ‘code’

– PIN presented at time of signature (approval, acceptance, etc)

• Method commonly endorsed in state medical record laws, JCAHO IM Standards

False Assertion Controls



Signature ‘binding’ / ‘record locking’

– Control intended to reduce opportunities for record modification • Some modification may be acceptable if does not alter the meaning

of the record / signer intent

– E.g., image compression (as with PACS)

– E.g., distinct renderings of ‘Continuity of Care Record’ (CCR)

• Conservative approach is to invalidate the e-signature with any change in the record

– Some competing technologies • Digital signatures

– Cryptographically bind record and signer

• Securely stored hash of signed record + signer attributes

• Native (proprietary) RDMS record locking mechanisms

• Access controls (over record)

False Assertion Risk Calculation



Risk assessment conducted on per signature basis

• Different error impact for different types

– Derive annualized rates, if needed, with multiplication by transaction rate



Expected loss calculation for single signature compromise

• Impact Cost

– c(R)= cost of recovery

• Rescinding transaction / correcting records – c(T) = value of transaction

• Not all transactions can be rescinded or corrected (e.g. a clinical order once executed)

• Likelihood

False Repudiation (Examples)

Clinical Order or E-Prescription

– Clinician successfully denies responsibility for an order / medication dispensed under the clinician’s authority

– Creates inappropriate distrust in EOE, MARS, and other records • Successful repudiation calls into question adequacy of implemented

controls

• New liability exposure 

Patient Authorization

– Patient successfully denies authorizing PHI disclosure – Privacy complaint and OCR sanction



Agreement Repudiation

– Employee / affiliated practitioner denies formal acceptance of ‘user agreement’ / COP

– Reduced ability to apply sanctions / enforce policy • Staff acknowledge of responsibilities uncertain

False Repudiation Risk

Design Failure

– Usually due to a design failure

– The e-signature mechanism does not collect sufficient evidence to successfully dispute the repudiation



Consequences

– Extend beyond the disputed transaction

• Provides precedent for repudiation of other transactions – Significant organizational impact if the healthcare

organization (rightly or wrongly) challenges repudiation by a practitioner

• Very likely that medical staff will refuse to provide further electronic signatures

False Repudiation Controls



False repudiation creates a unique security challenge

when someone has asserted that it did

• ‘Security’ is typically focused on preventing or mitigating error

• Disputing repudiation emphasizes audit and forensic controls

• Responding to false repudiation is tantamount to ‘proving a negative’



Legal review of signature system design

– Questions regarding repudiation is determined by dispute resolution process

• Law courts, arbitrator, medical review board, med staff peer review, etc

– Sufficiency of the signature system to assert signature against repudiation is a matter of evidence

• Data

False Repudiation Controls

‘Non-repudiation’ mechanisms

– Intended to create presumption that signature could only have been created by the purported signer

• Attempt to shift the proof burden to the party repudiating the signature

– A few states have coded the presumptive validity of digital signature into law ( Utah, Washington , Illinois )

• Typically, presumption only applies when using certificates issued by state licensed CA

• Anticipates 2 distinct counter arguments

– Error in certificate provisioning (I&A, distribution, renewal, etc) – Inadequate signature key protection

False Repudiation Controls

‘Non-repudiation’ mechanisms (con’t)

– Don’t treat “Non repudiation’ as an either /or characteristic

• How much presumption of validity will the fact finder (jury) attribute to the signature system

• What is the degree of difficulty in countering that presumption – ‘Non repudiation’ mechanisms do not have to be technical.

• Witnessed signatures have greater presumption of validity that non witnessed ones

• Fact finder likely to give some presumption to well conceived and maintained computerized record systems

– Adequacy of design / SDLC

– Controls over potential administrative error (malicious or not) – Regular audits of signature mechanism

False Repudiation Controls

Recommendations:

– Determine the consequences of false repudiation – Where consequences are large,

• Involve attorney in requirements specification / system design

• Consider if and how workflow can support witnessed signatures – Important

False Repudiation Risk Calculation

Expected loss calculation for single signature

compromise

– L = (min((c(Lit) + c(J)),c(S))*(.2 * P(D))

– Impact costs related to dispute resolution • c(Lit) = litigation cost,

• c(J) = judgment requested;

• c(S) = anticipated settlement;

– Likelihood costs related to probability of dispute (false repudiation)

• .2 is an estimate of the unreliability of dispute resolution mechanism

– % unfavorable judgments even when defendants position is true and accurate



Additional repudiation impact costs to consider:

– Incentive for added litigation … any successful repudiation undermines ability to assert integrity of system of records – Regulatory scrutiny

E-Sig Types



Security Objectives

Assurance Levels

Basic E-sig Security Objectives

Unambiguous signature action

– Ensure that signature is recorded / ‘committed’ only subsequent to well defined user action



Unambiguous record definition

– Ensure that the signature is associated with a specific purpose relative to a specific transaction / record

• e.g. authorship, approval, receipt and review, etc 

Signer authentication

– Ensure appropriate identification of signer



Transaction Integrity

Advanced E-sig Security Objectives

Transportability

– Ensure that the accurate communication of the signature – Important for e-commerce and EDI applications



Long Term Persistence

– Ensure that accurate record of signature may be recovered after substantial time periods



Independent verifiability

– Ensure verification of the signature without reference to the system that created the signature

– Important for medical evidence or certifications

E-sig Assurance Levels

 Security objectives can be accomplished at different levels of

assurance

 Security Requirements

– Some effort to classify electronic signatures in terms of their security requirements

– ASTM e31 e1762-2004 ~ Standard Guide for the Electronic Authentication of Health Care Information

– Some discrimination exists in State law to give greater weight / presumption to digital signatures

• Electronic signatures vs ‘secure electronic signature’ (Illinois)  Sources of security requirements

– Organization’s assessment of risk

– Regulatory requirements

• DEA rules for e-signature on prescriptions

• CMS rules for electronic prescription of non-narcotic • State Medical Record laws

– Business partner’s requirements

• Plan Conditions of Participation (COP) • Electronic Trading Partner agreement

Assurance Levels



HIGH

--“secure signatures”

– Needed where organization encounters potentially significant or catastrophic loss as a result of either false acceptance or false repudiation

• Fines / penalties / judgments greater than 100k • Loss of licensing

• Serious adverse medical event • Financial loss due to fraud



Low

-- “rudimentary signatures”

– Needed where organization will encounter minimal loss as a result of ether false acceptance or false repudiation



Medium

– everything in between

– Needed where organization encounters potentially moderate loss as a result of ether false acceptance or false repudiation

High Assurance -- Secure E-signatures

Use Cases

– Narcotic Prescription

• DEA proposed requirements per EPCS

– Minimum conditions for electronic prescription set by regulator

• DEA concerned with false assertion and false repudiation – Patient consent to treatment

• Significant consequence of repudiation

– w/o consent, treatment may be regarded as criminal battery

• Provider organization concerned with false repudiation – Certifications of medical necessity

• For example, as required for durable medical equipment or dialysis

• Basis for significant expenditures;

– fraudulent certifications source of significant Medicare loss

– Fraud concerns prelude treating certificates of necessity as a health claim attachment

• Medicare blue ink rules

High Assurance -- Secure E-signatures

Standard Protection Requirements

– Unambiguous signature action • Attestation of signer intent, e.g.

– PKI “subscriber agreement’

• Invocation of unique (private) signature key – Unambiguous record definition

• Routine transactions / standard forms

• Verbal explanation (patients) – Strong authentication

• In person identity proofing

• Multi-factor authentication – Transaction Integrity

Medium Assurance E-signatures

Use Cases

– Medical Records

• States set minimum requirements for practitioner authentication of record entries

– Signer’s attestation that he will maintain confidentiality of signature code

– Codes are unique to individuals

• States are concerned about false assertion and false repudiation (practitioner accountability)

– Electronic Prescription (other than narcotic)

• Responsibility to validate the legitimacy (authenticity +

appropriateness) of prescription lies with dispensing pharmacist

– Significant diligence on part of pharmacist to verify practitioner intent thru callback / manual procedures

• ePrescription vendors concerned primarily with false assertion.

– Healthcare EDI Transactions (other than X12.835 – attachments) • Source authentication for X12 transactions

– Transactions are not signed by individuals

• Payers are concerned with false assertion (ie fraudulent claims)

• Providers are concerned with false repudiation (ie, rescinded eligibility verification or authorization to treat)

Medium Assurance E-signatures

Protection Requirements

– Unambiguous signature action • Attestation of signer intent, e.g.

– Access / use agreement

– Electronic trading partner agreement

– Unambiguous record definition

• Routine transactions / standard forms

• Verbal explanation (patients) – Signer authentication

• Unique user credentials

• Defined diligence process – Transaction Integrity

Low Assurance --Rudimentary E-signatures

Use Cases

– Online Health plan enrollment

• Plan implements e-signature as a matter of expediency

– Signature required for authorization (to request medical records) and member attestation of present medical condition

• Plan concerned mostly with false repudiation – Patient consent

• Specific consent to release some medical information

– Signature required to validate / memorialize the authenticity of patient’s information request

• General consent to bill / acquire records for other providers

Low Assurance --Rudimentary E-signatures

Protection Requirements

– Unambiguous signature action

• Concurrent signer attestation (‘signature block’) – Unambiguous record definition

• Reliance on ‘ordinary meaning’ of text – Signer authentication

• Unique signer identification – Transaction Integrity

• Protection against the most likely threats to the integrity of the record system

Implementation Studies

E-prescription



Patient Consent



Online Health Plan Enrollment

EMR Signature

VHA Electronic Prescriptions

VHA Pilot project

– Goals

• Displace current paper prescription processes

• Permit e-prescription of any drug – DEA Waiver

• Pilot e-signatures with schedule II narcotics, provided compliance with DEA EPCS guidelines

• DEA regulator setting security requirements for the electronic signature

VHA Electronic Prescriptions

– E-prescription authenticated with practitioner’s digital signature

– Private signature key stored on smart card issued to practitioner

– Certificates issued directly by DEA

• DEA requirement; DEA choose not to accept use of certificates created by the VHA PKI. VHA acts a a registration agent (RA) for the VHA CA

• Other DEA proposals have the DEA CA only issuing certificates to

subordinate cert authorities. DEA will not provide practitioner certificates

– PKCS#11 formatted digital signature transmitted to pharmacy system with script

• 60 year retention policy

– Digital signature verified before acceptance of script by VHA pharmacy

• Certificate status checking against DEA revocation lists

– Digital signature capability integrated into VHA’s VistA system

VHA Electronic Prescriptions

Results-Feedback

– Positive practitioner acceptance – More timely prescription fulfillment

– Practitioner task completed once they have signed prescription

– Eliminates practitioner’s duty to deliver the (paper) prescription



Example of ‘secure’ electronic signature

Medicare Modernization Act

 Requires HHS to publish e-prescription standards

– E-prescriptions mandatory for Medicare Part D patients

– Likely to become standard for all electronic scripts once harmonized with DEA rules for schedule II narcotics

 NCPDP Script

– Medicare standard will call for use of NCPDP SCRIPT EDI standard

– SCRIPT standard does not include segments & fields for transmission of signature

– NCPDP telecom standard does not include rules for acquisition of signature by POC prescription applications

 Market De Facto Requirements

– Typical state pharmacy code requires that dispensing pharmacist verify the legitimacy of the prescription

• Little if any explicit requirements per electronic signature

– Pharmacist will not use product solutions that do not provide them with an appropriate level of assurance

• Questions of authenticity require callback to prescribing physician which diminish the business value of the vendors solution.

MMA E-Prescription (cont)

Vendor Role

– E-Prescription network vendors perform role similar to health reimbursement clearinghouses

– Collect prescriptions and deliver to pharmacy.

– Mostly dial-up with single factor user authentication (UID + password)



Network Role

– E-prescription networks implement business rules for ‘acceptable’ electronic prescription

– Diligence in the registration of physician offices (verification of credentials, DEA numbers, etc)

– User authenticates to E-prescription network prior to transmission

MMA E-Prescription (cont)

NCVHS Recommendations

– That the required standards recognize current E-prescription network practices as basis of future E-prescription security standards

– Conflicts with other recommendation to harmonize with DEA EPCS rules which will (almost assuredly) require digital

signatures



Medium assurance level appropriate to community

pharmacy

– Potential for harm mitigated by pharmacist role in verifying the legitimacy of each prescription

• Pharmacist applies additional controls for suspicious or unusual prescriptions

– Appx 1/3 of prescriptions involve a call to practitioner



New models (ie Internet pharmacy) will require a greater

OnLine Health Plan Enrollment

Blue Cross of California

– “By checking boxes and entering my name below I am

indicating my intent to electronically sign this application and warrant that all the information I have provided is true,

complete and accurate.”

• Includes checkbox to authorize medical records release

• Acknowledgement that application will be terminated if information is untrue or incomplete

– No user authentication



Approach Appropriate to BC Risk Calculation

– Economic benefit of simplified transaction completion

• Need to meet HIPAA and CA authorization and receipt of notice requirements

VHA Patient Consent

Pilot Project at VHA Hines

– Demonstrates provisioning of e-signature thru a service oriented architecture (SOA)



Integrates multiple signature technologies

– Patient's ‘digitized signature’ collected via e-signature pad and stylus

• Records specific signature act

• Evidence of signer identity

– Digital signatures create secure binding • Hash computed over compound document

– Digitized signature gif + completed consent form

• Digital signatures computed in the appliance

– Appliance is FIPS 140-2 level 3 compliant



SOA Benefits

– easy substitution of different forms, user authentication and input types, signature binding

Signing Function

Approval

EMR Signature

 State codes, Medicare COP require that some medical record

entries be signed by appropriate practitioner

 EMR / EOE signature technology choices are largely limited to

a vendor’s configuration options

 Vendor typically implements practitioner signature thru

‘signature by computer code mechanism’

 Vendor specific schemes to ensure integrity of ‘signature’

– Some very weak schemes leverage platform capability but may not satisfy security requirements

• E.g. signed records stored as MSFT Office documents,

programmatically (VBA) invoking “Tools | Options | Security | Password to modify” functionality of Office

– Anyone with password can modify, so record not locked at time of signature

– MSFT does not intended only to prevent ‘inadvertent’ modification

• E.g. setting files as Read Only

EMR Signature

 Typical scheme provides medium level assurance

– Practitioner attestation of ownership and exclusive use of signature code

– Faithful execution of the EMR application’s business rules provide for transactional integrity

 Medium assurance may be sufficient

– Credentialed user community / controlled access environment

– False repudiation unlikely

• Shared practitioner - hospital liability eliminates much of the perceived benefit  Warning

– “Expedient” solutions for physician EMR signatures may involve significant risk

– Batch Signing--allowing physician to sign document that has not been opened “batch signing”

Addendum



Standards Activity

The HIPAA E-sig Rule

E-signature Formats

References

Standard Development Efforts

Digital Signature Standards

– Most common development effort

– Focus on signature transportability and independent verifiability as pre-requisites for interoperability

– Support for creation of signature within one organization and reliance in another



Foundational technology standards

– PKCS, in particular PkCS#7, (RSA) • S/MIME implementation

– XML DSIG (W3C)

ASTM E31.20 Committee on Data Security

E1762 ~ Standard Guide for the Electronic Authentication

of Health Care Information

– First published in 1995, currently undergoing significant revision

– Identifies technologies appropriate for distinct healthcare signature purposes

– Identifies baseline performance standards for healthcare esig implementations



E2084 ~ Specification for Authentication of Healthcare

Information using Digital Signatures

– Defines healthcare appropriate document types, signer and signature attributes for use with PKCS#7

– Provides ASN.1 modules to support implementation of e1762 concepts using digital signatures

IHE

 “Document Digital Signature Integration Profile”

– Basis for interoperability demonstration / testing (HIMSS & RSNA Connectathon)

 Functional requirements for signature applications supporting

targeted use cases

– Electronic referral

– Electronic prescription

 Format for XDSSignature

– XDS (cross enterprise document sharing) XML template

 Digital signature will be part of the 2006 IT Infrastructure Profile

– Participation of major healthcare system vendor participation (Siemens, GE, etc)

– Preliminary to wide adoption by system vendors … IHE profiles often used to express market interoperability requirements

HIPAA Electronic Signature Standard



1996 HIPAA Law called for HHS to promulgate standards

for transmission and verification of electronic signature

related to HIPAA reimbursement transactions

– 1998 NPRM proposed that standard should involve digital signatures



Limited use case for esig in reimbursement transaction

context

– Claims are not signed

– Attached information typically is signed

• Industry may be satisfied with ‘signature on file’ approach

• Signature critical to “Certifications of Medical Necessity”

– e.g. Medicare DME and dialysis certifications

– Signature transmission is not included in current HL7/ X12 approach to claim attachments

• If the use case for the attachment potentially involves verification of a signature, the work group has defined ‘not an attachment’

• HL7 does not directly support transmission of actual signature, instead only the assertion that a particular person signed

HIPAA Electronic Signature Standard

HHS current view is to promulgate only standards that

have already been widely adopted by the industry

– Implies that there will be NO HIPAA Esig standard

• Mandate to use an ‘attachment standard’ which apparently will define away any requirement for signature transmission

• ‘Must accept’ provisions will prevent plan request / requirement for other info /paper to authenticate electronic signature

• Therefore no opportunity for industry to ‘widely adopt’ standard procedure



Are Medicare ‘Certifications of Medical Necessity’ health

claim ‘attachments?

– Include patient info transmitted from provider to payer in support of a claim

Medicare Certifications of Medical

Necessity



DMERC 484.2 Certification

– submitted by supplier of medical equipment (e.g. portable oxygen) but signed by practitioner

HIPAA Electronic Signature Standard



Transportability and independent verifiability properties

are critical

– Signature versus mere Assertion about authorship / approval – Assertion sufficient in high trust environments

• Does this apply to healthcare reimbursement transactions?



Digital signatures are transportable and independently

verifiable

– Potential to authenticate attached medical records without having to rely upon ‘trust’ in EDI submitter



For extended analysis, see

– http://www.tunitas.com/presentations/HIPAAEsigRule.zip



NCVHS testimony on electronic signature in 2005 did not

address electronic signature use with HIPAA

transactions

– HHS unlikely to respond to Congressional mandate in foreseeable future

PKCS#7



A data structure for encoding a digital signature

– DER (‘distinguished encoding rules”)- 1st published 1993 – Assumes only that the system can process an octet string



A PKCS#7 structure includes:

– Digital signature and manifest (optional)

– Signer’s X.509 certificate chain and contemporaneous CRL – Signer information (optional) including: signing date,

signature purpose

• ASTM E2084 standardizes healthcare specific signature attributes 

Most commonly used digital signature representation

XML-Dsig



W3C recommendation for XML representation of digital

signature - adopted Feb, 2002

– Important component of web services security



Generalizes PKCS#7 concepts

– Defines a canonical form for document over which digital signature is computed

– Optional representations of public key ownership

• X509, PGP, SPKI, or directly exchanged key 

Extensible

– Supports a number of “SignerProperties” and other structure using standard XML namespace mechanisms



Readily available programming Tools available

Good fit with ASTM CCR and HL7 CDA standards

DICOM Digital Signature Profile

 Intended to standardize definition of digital signature over

radiological images

 Defines

– Different signer roles and signature purposes

– Attributes included in the digital signature

– Algorithms used in generating digital signature

 Creates two distinct ‘secure use’ profiles

– ‘bit preserving’ digital signature use

• Conventional understanding and use of digital signature

– ‘basic’ digital signature use

• Validation of ‘incoming’ digital signature

• Allows transformation / compression of validated incoming data object so long as it is stored in such a way that the object is guarded against ‘any unauthorized tampering’

X12.58



Defines internal X12 ‘control structures’ for source

authentication and message integrity

– Supports digital signature of transaction set or function grouping of transaction sets



Implementation

– Requires that EDI application be ‘crypto aware’

– More difficult to implement than options, such as s/MIME, that are external to X12 message security

– Rarely implemented, but status may change – Federal Implementation Guidelines for EDI

--NIST, July 2001

”The federal government is committed to providing security services for ASC X12 compliant EDI via the constructs provided by ASC

X12.58.”

Useful References

 Healthcare Electronic Signature “Best Practice”

– ASTM e1762-95 (fee). Free draft of e1762 update by request to bpankey@tunitas.com

– AHIMA Practice Brief “Implementing Electronic Signatures”

• http://www.ahima.org and then use search engine

– FDA CFR 21 Part 11

• http://www.fda.gov/ora/compliance_ref/part11/  Legal / Regulatory

– American Health Lawyers ()

• Health Information and Technology Practice Guide (fee) • HIT mailing list

– State Codes

• Links page: http://www.edfoundation.org/ElectronicSignaturePolicy.htm  Developer / Standards Related