Implementing Electronic Signatures







Full text


Implementing Electronic Signatures

Ann Geyer

Tunitas Group

Mike Davis



Topics Covered


– Signature purposes – Enabling legislation

Risk Definition

– E-sig Error Types – Risk Measures

Risk Management

– Threats

– Compensating Controls

Assurance Levels and RequirementsFramework in Action


E-sig Background



Relevant Law


The Role of Signature

Signature is a mechanism for memorializing an act

Acknowledgement, agreement, consent, production, etcBinds an actor to a record or transaction

Actor may be practitioner, consumer, …or automated process

Signature is an important workflow component

Approval to initiate workflow

Purchase order, Clinical Order, Prescription

Approval / authorization to proceed / dispensePatient consent, Quality check

Signature is of primary value for dispute resolution

Questions over responsibility, acceptance, knowledge, etc


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?


“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




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)


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 technologyExcept 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


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

E-signatures are legally valid

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

Weak statutory requirements

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 litigationMedical 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 lossSarbanes-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 signatureMay 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


Reduce opportunities for impersonation

Some competitive technologies commonly consideredCryptographic 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)


“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 modificationSome 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 technologiesDigital 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

Separate transaction / record types & signature purposes

Different error impact for different types

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

Expected loss calculation for single signature compromise

– L = min[c(R),c(T)] * [p(I) + p(M) - p(I)*p(M)]

Impact Cost

c(R)= cost of recovery

Rescinding transaction / correcting recordsc(T) = value of transaction

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



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 recordsSuccessful repudiation calls into question adequacy of implemented


New liability exposure

Patient Authorization

Patient successfully denies authorizing PHI disclosurePrivacy complaint and OCR sanction

Agreement Repudiation

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

Reduced ability to apply sanctions / enforce policyStaff 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


Extend beyond the disputed transaction

Provides precedent for repudiation of other transactionsSignificant 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

Requires showing that an error did not occur

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



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


Determine the consequences of false repudiationWhere consequences are large,

Involve attorney in requirements specification / system design

Consider if and how workflow can support witnessed signaturesImportant


False Repudiation Risk Calculation

Expected loss calculation for single signature


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

Impact costs related to dispute resolutionc(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:

Damage to reputation with customers / trading partners

Incentive for added litigation … any successful repudiation undermines ability to assert integrity of system of recordsRegulatory 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


Ensure that the accurate communication of the signatureImportant 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


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-narcoticState Medical Record laws

Business partner’s requirements

Plan Conditions of Participation (COP)Electronic Trading Partner agreement


Assurance Levels


--“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 100kLoss of licensing

Serious adverse medical eventFinancial loss due to fraud


-- “rudimentary signatures”

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


– 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 repudiationPatient consent to treatment

Significant consequence of repudiation

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

Provider organization concerned with false repudiationCertifications 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 actionAttestation of signer intent, e.g.

PKI “subscriber agreement’

Invocation of unique (private) signature keyUnambiguous record definition

Routine transactions / standard forms

Verbal explanation (patients) Strong authentication

In person identity proofing

Multi-factor authenticationTransaction 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 actionAttestation 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 processTransaction 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 repudiationPatient 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 identificationTransaction Integrity

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


Implementation Studies


Patient Consent

Online Health Plan Enrollment

EMR Signature


VHA Electronic Prescriptions

VHA Pilot project


Displace current paper prescription processes

Permit e-prescription of any drugDEA 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

Digital Signature Approach

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


Positive practitioner acceptanceMore 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

Security requirements set by DEA


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


Medium assurance level appropriate to community


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 bindingHash 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

User Input


Authentication Service Demographic Service Electronic Forms Repository


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 benefitWarning

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

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



Standards Activity

The HIPAA E-sig Rule

E-signature Formats



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

Digital Signature Standard (NIST)

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



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



“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


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


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 / approvalAssertion sufficient in high trust environments

Does this apply to healthcare reimbursement transactions?

Digital signatures are transportable and independently


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

For extended analysis, see

NCVHS testimony on electronic signature in 2005 did not

address electronic signature use with HIPAA


HHS unlikely to respond to Congressional mandate in foreseeable future



A data structure for encoding a digital signature

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

A PKCS#7 structure includes:

Version and algorithm information

Digital signature and manifest (optional)

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

signature purpose

ASTM E2084 standardizes healthcare specific signature attributes

Most commonly used digital signature representation



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


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


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’



Defines internal X12 ‘control structures’ for source

authentication and message integrity

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


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



Useful References

Healthcare Electronic Signature “Best Practice”

ASTM e1762-95 (fee). Free draft of e1762 update by request to

AHIMA Practice Brief “Implementing Electronic Signatures” and then use search engine

FDA CFR 21 Part 11 / Regulatory

American Health Lawyers ()

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

State Codes

Links page: / Standards Related





Related subjects :