Document Digital Signature Integration Profile

Transcription

1 ACC, HIMSS and RSNA Integrating the Healthcare Enterprise 5 IHE IT Infrastructure Technical Framework Supplement Document Digital Signature Integration Profile June 15th, Draft of Public Comment Comments due July 15, 2005 Copyright 2005: ACC/HIMSS/RSNA

2 FOREWORD...2 INTRODUCTION OPEN ISSUES AND QUESTIONS...4 VOLUME I INTEGRATION PROFILES...6 VOLUME II TRANSACTIONS DIGITAL SIGNATURE...51 VOLUME III DOCUMENT CONTENT PROFILES PROFILE ABSTRACT RELATED DOCUMENT CONTENT PROFILES CONTEXT FOR DOCUMENT CONTENT PROFILE REFERENCES PURPOSE FOR DIGITAL SIGNATURE DOCUMENT CONTENT PROFILE (USE CASES) Attesting a document as true copy XDS SIGNATURE DOCUMENT CONTENT SOURCE MAPPINGS XDSSignature Metadata XDSSubmissionSet Metadata XDSFolder Metadata Use of XDS Submission Set Use of XDS Folders List Content Standards Discuss Constraints on Content Standards List Use Cases that Utilize this Mapping CONSUMER PROCESSING CONFIGURATION PKI Configuration Affinity Domain Configuration

3 Foreword Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration of the information systems that support modern healthcare institutions. Its fundamental objective is to ensure that in the care of patients all required information for medical decisions is both correct and available to healthcare professionals. The IHE initiative is both a process and a forum for encouraging integration efforts. It defines a technical framework for the implementation of established messaging standards to achieve specific clinical goals. It includes a rigorous testing process for the implementation of this framework. And it organizes educational sessions and exhibits at major meetings of medical professionals to demonstrate the benefits of this framework and encourage its adoption by industry and users. The approach employed in the IHE initiative is not to define new integration standards, but rather to support the use of existing standards, HL7, DICOM, IETF, and others, as appropriate in their respective domains in an integrated manner, defining configuration choices when necessary. IHE maintain formal relationships with several standards bodies including HL7, DICOM and refers recommendations to them when clarifications or extensions to existing standards are necessary. This initiative has numerous sponsors and supporting organizations in different medical specialty domains and geographical regions. In North America the primary sponsors are the American College of Cardiology (ACC), the Healthcare Information and Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA). IHE Canada has also been formed. IHE Europe (IHE-EUR) is supported by a large coalition of organizations including the European Association of Radiology (EAR) and European Congress of Radiologists (ECR), the Coordination Committee of the Radiological and Electromedical Industries (COCIR), Deutsche Röntgengesellschaft (DRG), the EuroPACS Association, Groupement pour la Modernisation du Système d'information Hospitalier (GMSIH), Société Francaise de Radiologie (SFR), Società Italiana di Radiologia Medica (SIRM), the European Institute for health Records (EuroRec), and the European Society of Cardiology (ESC). In Japan IHE-J is sponsored by the Ministry of Economy, Trade, and Industry (METI); the Ministry of Health, Labor, and Welfare; and MEDIS- DC; cooperating organizations include the Japan Industries Association of Radiological Systems (JIRA), the Japan Association of Healthcare Information Systems Industry (JAHIS), Japan Radiological Society (JRS), Japan Society of Radiological Technology (JSRT), and the Japan Association of Medical Informatics (JAMI). Other organizations representing healthcare professionals are invited to join in the expansion of the IHE process across disciplinary and geographic boundaries. The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology, Laboratory, Radiology, etc.) defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of medical information to support optimal patient care. It is expanded annually, after a period of public review, and maintained regularly 2

4 90 95 through the identification and correction of errata. The current version for these Technical Frameworks may be found at The IHE Technical Framework identifies a subset of the functional components of the healthcare enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated, standards-based transactions. It describes this body of transactions in progressively greater depth. The volume I provides a high-level view of IHE functionality, showing the transactions organized into functional units called Integration Profiles that highlight their capacity to address specific clinical needs. The subsequent volumes provide detailed technical descriptions of each IHE transaction. This supplement to the IHE Technical Framework is submitted for Public Comment between June 15, 2005 and July 15, 2005, per the schedule announced in February Comments shall be submitted before July 15, 2005 to: under the IHE forum Select the <IT Infrastructure Supplements for Public Review> sub-forum. 105 The IHE IT Infrastructure Technical Committee will address these comments and publish the Trial Implementation version in August

5 Introduction This supplement specifies the use of digital signatures for documents that are shared between organizations. The informative section of this supplement is a how-to guide that expands on the issues of using digital signatures within the healthcare domain. It provides examples of how the XDS added document content profile can be applied. The normative sections of this supplement are: A new XDS (Cross-Enterprise Document Sharing) document content profile Changes to four Actors of the IHE Cross-Enterprise Document Sharing (XDS) Integrtaion profile A new XDS transaction option (digital signature) A document content profile is constrained to XDS, however the rest of this supplement is not. The document document content profile can be used as a reference, however, and the descriptions used in other contexts. Other IHE clinical domains are encouraged to utilize the digital signature document described in the following document content profile to sign their consent document and use their defined message transfer or use XDS. For example, patient care could create a patient care workflow and patient consent documents. Systems that do not use XDS can still work with their own methodologies, but those methods will not be covered in the document content profile portion of this supplement. Environments that are non-xds based may make use of this document by referring to the guide provided in the ITI Volume 1 Appendix N. 1.1 Open Issues and Questions This document content profile is restricting to by-reference signatures using XDS. Is either of those assumptions a problem? 2. This document content profile is also restricted to the digital signature of a whole document. 3. In the metadata we will record the time and purpose of the signature. The question is then, where do I find these in the signature. Our intent is to follow the standards of ASTM 2084 when it becomes available. 4. We are mandating that all XDS registries support digital signatures. 5. XDS signature mod issue: Do we need a use case covering deprecation of a signature? If we do, then the only use of deprecation is in association with the document replace operation where the ebrs DeprecateObjectRequest was automatically generated by the 4

6 Registry Adaptor. Deprecation of an object (without replacement) will require a new a new transaction that issues a DeprecateObjectRequest. 6. We have not explicitly addressed Replace, Transform or Amend functionality for digital signature documents. A parent document ID is not needed to be in the metadata for a signature document. Was that a good idea? 7. We need a reading list, to be published independent of this document. 8. How do we link the document content profile (volume 3) with volume 1? 9. Shall we permit extensions of the purposeofsignature vocabulary by an affinity domain? One possibly solution is to use a sub-purpose for domain-specific use. 10. Shall we make the digital signature document the NAV attachment? 5

7 Volume I Integration Profiles The following items shall be added to the glossary. 155 Digital Signature - A legally useful electronic equivalent to facsimile signature, including signatures generated for a variety of entities including human and machine sources. Based on digital certificates attributable to well-known healthcare oriented certificate authorities; incorporating cryptographically secure techniques for signature generation and validation. 160 Hash - A value uniquely calculated by using a well-known algorithm to create a digest all of the data constituting an electronic record. An actor uses a private key to generate a digital signature by transforming this value. By recalculating the hash digest value, and using the actor s certificate s public key to transform the electronic signature, it is possible to attest to the actor s signing ceremony and to the integrity of the signed record. The appendix shall be added to the appendix of Volume I <Appendix N> Examples of using digital signatures N.1 Approaches to Integrating Signed Healthcare Information This section is offered to provide guidance using examples that are useful when incorporating digital signature techniques in healthcare. The inclusion of digital signatures in the design of healthcare information systems should be approached in an ordered way. Designers should first define clinical document content; address the workflow associated with process implementation; determine the way information is to be managed and then address the application and use of digital signatures. In this section the following are reviewed: Overview of Digital Signature technology, policies, management approaches and related certificate / key technology Background on applying digital signature technology to healthcare Selected examples of using digital signature in healthcare systems o Referral o Prescription Fulfillment o Value Added Networks in Prescription Fulfillment 6

8 N.1.1 Purpose o Mitigating of Threats to Prescription Processes Examples in this guide lead designers to consider the following issues: N.1.2 The process involving application of a digital signature to represent an act of attestation. The process involving application of a digital signature to represent an act of authorization. Necessary and optional supporting services invoked as part of the signing process. Necessary and optional supporting services invoked as part of processes verifying and validating signatures. Specific digital signature attributes in healthcare contexts used with established digital signature mechanisms. Establishment and attachment of an entity s role in context within the invoked process. Establishment and attachment of an entity s authorizing credentials. Establishment of minimum requirements for user identification, access control, and other security attributes that must be in place to assure the integrity of the signature. Definition of requirements and approaches for managing records that require multiple signatures. Definition of requirements and approaches for managing nested and embedded signatures. Definition of requirements for preserving signature integrity in intermediary processing and information forwarding. Implementation of document countersignature used for attestation. Managing structured documents wherein one or more sections are unsigned or signed by one or more entities. Establishing the order and priority of attestation within whole documents. e-referral Authorization Signature Format and Semantics The XML Digital Signature ( defined by the W3C organization) form the basis of the technology used for integrating signed healthcare information. Healthcare applications require that additional information be maintained as part of signature structures. Extensions to the XML Digital Signature (defining an XML Advanced Electronic Signature ( with timestamp and extended signature validation 7

9 data) include areas to record details of the time that a signature ceremony was executed, contextually significant role(s) of the signer, and signature policy schema and commitment type selection that is useful for reflecting the process oriented purpose(s) of signing a document. These have been profiled by the European Telecomunications Standards Institiute (including XAdES ( technical specifications and a useful discussion of utilizing signature policy formats in appendix C of Electronic Signature Formats ( technical specification). These techniques can provide basic authentication and integrity protection and satisfies the legal requirements for advanced electronic signatures as defined in the European Directive EU-DIR-ESIG ( XML DTD and Schema are available for XML Digital Signature and the Advanced Electronic Signature extensions N.2 Digital Signature Background Digital signatures are comprised of a provable association between a document and signing identity that is protected from alteration by cryptographically strong technology. This is a two step process in which a one way algorithm is applied to digest the source document. The signer s private key is then used to cryptographically transform the digest into a signature that can only be associated with the document and the signer. Validating the signature of a document is also a two step process. In order to prove that a document has not been tampered with, you must have access to the original source document. First the signer s public key is applied to the digital signature to recover the source document digest. Then the same one way algorithm is applied to the document under evaluation to reconstruct the digest. If these compare successfully, the document and the signer are validated. The digital signature ensures that any attempt to modify the protected information will be detected. Digital signatures are useful for ensuring that validated information can not be repudiated. There are several systems available for calculating digital signatures. It s important for system wide integration for all of the systems selected for application in the healthcare industry to be available for all entities in all geographies. Details of implementation issues related to XMLbased digital signatures are documented at: A unit of provable information may include one or more digital signatures. When multiple signatures are present, they associate multiple collaborators required for performing a single action. Multiple signatures of a document s creation or a single process action can be implemented by attaching the results of applying each signer s private key to the same source document s digest. In all other cases, when an additional action is associated with a document (such as a review or countersignature), a new digest is calculated over the original document and signature, and the new action, and the additional digital signature is calculated. 250 Should original information be modified in subsequent process steps (such as translation or other transformation done by a value added network) the original form must be maintained with the 8

10 creator s signature without change. This is necessary so that the original document s digest can be calculated for signature verification. When information is reformatted or transformed, the original information needs to be maintained and passed along with the new information through subsequent process steps. This is accomplished by wrapping original information and incorporating it with subsequent additions in the record. The American Bar Association ( has published a useful guide that provides an introduction to the characteristics and semantics associated with digital signatures. It also includes an overview on the technology mechanisms used to implement digital signatures. This guide is available as a free download ( from their website. N.2.1 N.2.2 N.2.3 The Attestation Problem Reliance upon electronic health records and other forms of electronic health information requires an electronic signature process that provides satisfactory evidence of information s authorship, approval, review or other ownership. In particular, acts of attestation and authorization require a high degree of assurance for accountability and data integrity. As electronic health records are shared across healthcare enterprises, digital signatures can be used to provide for such accountability and non-repudiation. The signatures are used for both attestation and authorization. Attestation and authorization require security services that digital signatures offer to allow verification of origination from a particular health professional with appropriate credentials. Ensuring there are no errors in transmission requires the integrity service and accountability requires the service of non-repudiation. Digital Signature Requirements Background The act of digitally signing a document satisfies requirements established by many legal contexts including those that support in healthcare processes. It can help deliver more effective authentication of the signer, authentication of the message s integrity and demonstration of the affirmative ceremonial act of signing while delivering better efficiency. There are 4 major purposes for attaching a signature: Evidence, Ceremony, Approval, Efficiency and Logistics. Signature Characteristics and Requirements All electronic documents are digital copies of information, which may originally exist on paper or in the memory of a user interface device. Healthcare processes require that entities work with either an original document or a "true copy of an original document". A true copy must be verifiable as not altered in any way since a signature was applied during a signing ceremony. This requirement follows the medical records tradition of keeping track of original documents versus requirements for reconstructed and modified documents. Some scenarios may deal with use cases based upon reconstruction and modification of original data. Usually these are managed by creating a new "original" signed document that reflects the reconstruction performed at an identifiable time. As part of a separate signing ceremony, it is 9

11 internally labelled as such so as to distinguish it from a reconstruction performed at subsequent times when other data is available. Thus, true copies of reconstructions may also be subsequently and uniquely verified. Most document modifications are managed by creating an addendum rather than by modifying the original document. Whether the original signed document is embedded in the subsequent document, or referenced from it and stored separately, this creates two signed original documents with a relationship. N.2.4 N.2.5 Uniqueness N.2.6 Simplifying Transport of Health Records These examples address the need to work with provable true copies of documents across the activities of integrated dissimilar healthcare systems. It does not address possible requirements to transfer documents and transactions through secured or authenticated communications channels. In the real world of healthcare, many signed documents are delivered through unsecured channels. For example, a patient or any number of proxies may carry a signed paper prescription from the doctor s office to the pharmacy. It may eventually be possible to eliminate some requirements for secured transmission channels by relying on digital signatures and separately designated content encryption technology. Documents must be uniquely identifiable even when multiple documents have the same content. Most documents contain some form of artificial uniqueness like the patient ID associated with an identical diagnostic portion. Examples include the content of normal chest radiology reports or the coincidentally identical results of a normal blood test. The normal ranges, reported accuracy, and number of measurements are such that there are many identical blood test results. The act of digitally signing such a document can create artificial uniqueness based on the time of the signature ceremony and the signer s identity. Method for Signing Documents A typical digital signature includes several information elements. The content of a signed document is first evaluated using a well-known hash algorithm that calculates a unique digest of the content. This is calculated in such a way that if any of the data within the document content changes in any way, the hash digest will change. The signer of a document signs it by using a cryptographically secure process that is based on principals of asymmetric one-way keys. These examples specify the use of X.509 ( version 3 digital certificates IETF RFC3280 ( for implementing the public key infrastructure (PKI). Asymmetric public and private keys are created when an entity obtains certificates from a wellknown and recognized certificate authority. The keys are issued with a related timeframe that reflects the validity period(s) for the keys. The entity must store key certificates in a secure place that implements access controls that prevent misuse or misapplication of the keys. A privately 10

12 held key is used for encrypting the document s hash digest value. The result is stored with the signer s public key and other identifying information, forming the digital signature. Certificates used for signature are separate from those used for content encryption or transmission. Note that content encryption and or transaction signing are not involved in these examples. N.2.7 Additional Healthcare Signature Requirements The identifying information in the signature must be expanded to include additional data relevant to the healthcare industry. This can be stored within the structure of the certificate itself, and includes the date and time the signature was calculated and applied, the identity of the signer and the contextually appropriate role of the signer. The role of a signer (purpose of the signature) includes entities that may carry the responsibilities of: Signer: the entity that creates the electronic signature. When the signer digitally signs over data object(s) using the prescribed format, this represents a commitment on behalf of the signing entity to the data object(s) being signed. Verifier: the entity that verifies the electronic signature. It may be a single entity or multiple entities 345 Trusted Service Providers: one or more entities that help to build trust relationships between the signer and verifier. Trusted Service Providers include PKI Certification Authorities, Registration Authorities, Repository Authorities (e.g. a directory), Time-Stamping Authorities, Signature Policy Issuers and Attribute Authorities. Arbitrator: An entity that arbitrates in disputes between a signer and a verifier Implementations should follow the standard for Electronic Authentication of Healthcare Information (ASTM E1762). This standard specifies additional characteristics that describe details of the signing ceremony, including healthcare process oriented purposes. Some of this information is descriptive of the signing entity, and can be derived from (and stored within) the entity s certificate. The attributes of the signing ceremony are stored within the signature structure itself. There may be additional signature purposes or further refinement. The IHE recognized structure must be extendible. IHE will rely on extensions defined by ASTM. This is particularly important as implementers identify individual terms used for different meanings. Additional extensions may be defined by other organizations. N.2.8 Recording Healthcare Signature Characteristics Attributes like the signer s identity and organization reflect characteristics of the signer that are associated with the certificate used by the signer to execute the signature. They are best stored 11

13 within the certificate used for the signing ceremony. These characteristics are available through the Common Name (CN), Organization (O) and Organizational Unit (OU) fields of standard X.509 certificates. The X.509 certificate used for signing is stored in its entirety within the signature structure. Other attributes, including the signer s Role (which is one potential instance of a signer s multiple authorities) are best stored as attributes within the signature structure itself. This is because the role(s) of a signer may vary from signing ceremony to signing ceremony. These examples intend that a signer can be a human entity or a machine. A machine may sign documents for several of the purposes listed by the ASTM standard. Within the standard, some purposes specifically reflect the creation of a document by a machine. While a clinician may digitally sign an audio file, a machine could also act as a translator by using voice recognition to transcribe voice recordings to text. Similarly the signature attesting to an interpreter s action could refer to machine translation between languages. A machine may perform other administrative actions enumerated by the standard. These examples intend that an entity that transforms data will use the ASTM signature purpose transcription. This includes intermediaries in processes that store and forward signed or unsigned documents. Signature Time is system time, and IHE Profile Consistent Time, optionally synchronized through a trusted source. To support machines that create documents, these examples intend to further restrict consistent time to include accuracy that is better than one second. We rely on the XML Digital Signature standard for data semantics specification. N.2.9 N.2.10 Attested Content Format These examples intend that signed document payloads be formatted within XML data structures, including MIME encapsulated within XML. Repositories contain XML structured data. These examples do not involve themselves with digital signatures that are embedded within documents themselves. Signatures within mail objects and PDF documents can still be optionally done, but processing them is beyond the scope of these examples. Storage of Signed documents The data structure that contains the signature (including hash, extended certificate, URIs to the signed document(s) and identifying information) is stored in a document within the repository. The signature document and signed document are stored. Entries for these documents are maintained within the registry. The implementation choice for these examples recommends placing the signature and signed document(s) in the same repository. These examples do not specify details of how document registry or repository systems will internally store documents data and their associated hash digest and signature. It is possible to store the complete document and associated hash digest and 12

14 signature as one or more XML formatted data structures. It is also possible to store the signature and related documents in separate repositories. It is possible to associate more than one signature and / or more than one content document within a submission set. When many documents are attested by a signature, the signature s hash is calculated by processing all referenced documents. Thus it is possible to have the following signature relationships within a submission set: Signed Document(s) One One Many Many Signature Document(s) One Many One Many It is also possible for a signature to be applied to a signed document. This is typical for review actions N.2.11Records Integrity Risks to record integrity are diverse. The use of digital signatures doesn t improve protection of records integrity, but it does help detect damaged information. N.2.12 Method for Attesting to a Document To determine if a copy of a digitally signed document is a true and provable copy of the original, entities re-calculate the document digest using the same well-known algorithm used by the signing entity. The entity then applies the signing entity s public key to decrypt the digest previously calculated in the signing process. If the digest calculated locally and the digest derived from the decrypted signature value match, the document is the original or a provable, unmodified true digital copy of the original. N.2.13 Transmission of Signed Documents The use of digital signatures on document content does not require specification of message transmission. Systems may need to cope with incoming messages transmitted through formatted HTTP, SOAP and mechanisms that contain XML or S/MIME encapsulated XML payloads. Note that selecting a transport or transaction protocol does not imply that these examples intend the transmission itself be digitally signed. Only the documents contained within the transmission or transaction messages are signed. 13

15 The implementation of document transmission must avoid interfering with normal function of devices that cannot process signatures. A device that is insensitive to digital signatures must still be able to process signed and unsigned data. This includes browser-based workstations that need to be able to interact with signed documents, but might have no program extensions that recognize and process associated signatures. The IHE Digital Signature Document Content Profile specifies the use of XDS for transport and management of both documents and their associated signatures. Those signatures are dealt with as standalone documents in XDS, which utilizes the repository to enforce the association. It is expected that IHE or other organizations that collaborate will use these guidelines to create further document content and integration profiles. N.3 Use Case Examples These use cases were considered when the IHE Digital Signature Document Profile was created N.3.1 Electronic Referral Applications Upon discharge of a patient from a clinical encounter, the clinician assembles supporting clinical documents regarding the patient condition, continuing care orders, and summary information of the patient visit. The physician performs a review action and digitally signs a document that attests to the review, orders the referral and references the other records. Further actions may also be signed by the discharge planner, and by the nurse educator. This information is sent to the referred clinician s organization. The information is stored within their repository. The referral action includes attestation to the aggregation of records transferred with the referral. This can be implemented with a manifest that is part of the referral action payload. The manifest is structured to contain hash digest values of individual documents that are included with the aggregation. Implementations that permit a patient to copy and inspect the referral orders may allow the patient to remove or obscure information that they consider private (invalidating the referral clinician s signature). Thus is may be necessary to support full and partial healthcare records transfer requests under control of the patient. Relying parties receive the attested digitally signed referral message and retrieve the referral from a repository. The information integrity and signature ceremony of the referral action are verified and the identity of the signer are validated through verification of trust and revocation checking. Associated signature attributes are checked against further role constraints and authorization requirements. 460 N Entities Referral associates actions of a referring clinician with a receiving physician on behalf of a patient. The records repositories shown below could be separate or the same depending on the 14

16 465 implementation of deployment databases each physician is associated with. The direct or indirect channel for passing referral messages allows for implementation through telecommunications or hand carried token means. Figure N Entities in Referral Action 470 Table N.3.1-1: DIGSIG How To Examples Primary Referral Case Entities and Interactions Entities Referring clinician Referred Clinician Interactions Assemble Health Records and Orders Sign Referral (aggregate) Forward Signed Referral Directly Receive Referral 15

17 Verify Signature (validity, role, credentials) Acknowledge Referral Complete Action 475 N Primary Case Processing Sequence The Referring clinician: o Gathers Health Records that support the referral action o Authors orders o Selects a direct referral target o Signs the aggregate assembled patient Health Records and orders (by reference) o Forwards the orders to the referral target o Receives acknowledgement of forwarding the records. The Referred Clinician o Gets the referral object o Verifies the physician s signature over the aggregate assembled patient Health Records and referring clinician s orders o Inspects the referring clinician s orders o Inspects the referring clinician s aggregate patient Health Records o Creates a referral receipt o Signs the referral receipt o Transmits the referral receipt to the referring clinician The Referring clinician o Receives the referral receipt o Verifies the referred physician signature o Processes and files the receipt The Referred clinician o Acts on the referral orders 16

18 o Completes the referral action

19 18

20 505 N.3.2 Alternate Referral Case Table N.3.2-1: DIGSIG How To Examples Alternate Referral Case Entities and Interactions Entities Referring clinician Patient Referred Clinician Interactions Assemble Health Records and Orders Sign aggregate Health Records and Orders Sign Referral Orders (only) Forward Referral via Patient Receive Referral Verify Physician Signature (validity, role, credentials) Filter Referral Sign Patient Channel Referral Assemble and Forward Referral Receive Referral Verify Patient Signature Verify Physician Signature (validity, role, credentials) Review Health Records and Orders Acknowledge Referral Complete Action Process Referral Receipt 510 N Alternate Case Processing Sequence The Referring clinician: o Gathers Health Records that support the referral action 19

21 o Authors and signs orders o Forwards the orders to the patient The Patient o Receives the unsigned Health Records and physician signed orders o Verifies the physician s signature o Inspects the physician s orders o Inspects and filters the unsigned Health Records o Copies the unmodified signed physician s orders and patient filtered Health Records to a Patient Channel Referral action o Selects Referral target o Forwards the referral to the physician The Referred clinician o Gets the referral object o Verifies the patient s signature over the aggregate assembled patient Health Records and signed referring clinician s orders o Verifies the physician s signature on the referral orders o Inspects the referring clinician s orders and unsigned Health Records o Creates a referral receipt o Signs the referral receipt o Transmits the referral receipt to the referring clinician The Referring clinician o Receives the referral receipt o Verifies the reffered physician signature o Processes and files the receipt The Referred clinician o Acts on the referral orders o Completes the referral action 20

22 21

23 22

24 23

25 545 N Summary Definitions Referring Clinician The licensed medical professional that initiates a patient referral action 550 Referred Patient The patient that acts as a communication channel to carry the referring clinician s referral to the Referred clinician. The Referred Patient may filter Health Records that accompany the signed referral orders. Referred Clinician The licensed medical professional that receives a patient referral action, issues a receipt and acts upon it. N Summary Interactions Assemble Health Records and Orders Sign aggregate Health Records and Orders Sign Referral Orders (only) Forward Referral via Patient Receive Referral Verify Physician Signature Filter Referral Sign Patient Channel Referral Assemble and Forward Referral Verify Patient Signature Create the content for the order, an assembly of Health Records and Physician s orders that will be transmitted and stored by systems in the referral process Over the entire content of assembled Health Records and physician s orders, calculate hash digest, apply certificate and insert signature into referral order. Over only the content of the physician s orders, calculate the hash digest, apply certificate and insert signature into referral order. Transmit the complete aggregate referral order with signed physician orders and unsigned aggregate of Health Records via patient accessible media. Recognize the availability of an incoming referral, and process it. Verify that the signature attests to the unmodified validity of physician signed orders or aggregate orders and Health Records. Include validity, role, credentials checks. Review Health Records associated with the physician s orders and selectively delete them from the referral. Over the content of the signed physician s orders and unsigned filtered aggregate Health Records, calculate the hash digest, apply certificate and insert signature into the Patient Channel Referral. Transmit the referral via selected media. Over the patient signed aggregate of Health Records and signed physician s orders, calculate the hash, apply the 24

26 Verify Physician Signature Review Health Records and Orders Acknowledge Referral Complete Action Process Referral Receipt signature keys and verify attestable validity of the patient s signature. Over the physician signed aggregate of Health Records orders, or the signed physician s orders, calculate the hash, apply the signature keys and verify attestable validity of the physician s signature (including, context based role and credentials). Browse the contents of the referral Create a referral receipt, sign it and forward it to the referring clinician Close processing of the referral Close processing of the referral receipt N.3.3 Electronic Prescription Applications: Prescription Written and Directly Delivered To Format-Compatible Pharmacy Intake System After conclusion of an appointment, a physician writes an electronic prescription for the patient. From signed documents provided by the payer, the electronic prescription system verifies that the drugs prescribed are in the formulary. The physician digitally signs the prescription, and makes the prescription available to the pharmacy of the patient s choice. The electronic prescription preparation system and the pharmacy prescription intake system share the same formatting. The pharmacy intake system verifies that the prescription is a true copy of the document the physician signed. It further determines that the patient has no known allergies to the medications, checks for interactions with other medications the patient may be receiving and verifies that the amounts prescribed are within best practices guidelines. The pharmacy system recommends that the pharmacy proceed based on prescription document signature validity, prescription document integrity and the fill / not-fill recommendation from patient records analysis. It is not necessary to include co-signature/counter-signature scenarios for these use cases, but digital signatures can also used for this purpose. The e-prescribing use cases specified in these examples are derived form the CEN European Pre- Standard ENV13607 Health informatics - Messages for the exchange of information on medicine prescriptions. The following seven messages are defined in the European prescription writing pre-standard (preceded by their functional group): Prescription message: New prescription message; 25

27 Prescription cancellation message; Dispensing report message: Prescription dispensing report message; Prescription dispensing report cancellation message; Query service message: Prescription query message; Prescription set list message; Prescription set selection message; For each of the messages defined in this European pre-standard there are two or three communication roles: the message sender role and the designated message receiver role and the alternate message receiver role (not in query service messages). Four types of healthcare parties assume the roles: Prescriber, Dispensing agent, Relaying agents - and Alternate destination. N Summary Definitions The prescriber is the healthcare person issuing prescriptions (new prescription messages). The dispensing agent is the healthcare organization receiving and processing prescriptions (new prescription messages) to dispense medicinal products. The relaying agents is a party agreed to be acting as an intermediary, communicating messages between the prescriber and the dispensing agent in both directions when direct communication is not possible as the dispensing agent s identity is not known, being dependent on individual patient s choice, or alternative arrangements are agreed by local communicating parties. The relaying agents are not only acting as Message Handling Agents but are also entrusted with the role of receiving new prescription messages from the prescriber without a predefined dispensing agent. The relaying agents also handle requests from the dispensing agent to send a specified new prescription message, and in doing so modify the original message (adding the dispensing agent to the message). The relaying agents may also play a role in authenticating the eligibility of the dispensing agent to retrieve a new prescription message. The alternate destination is a party who is neither a prescriber, a dispensing agent or a relaying agents but who, for clinical or administrative reasons, is nominated and allowed by national regulations to receive a copy of a message from a message originator. 26

28 A single healthcare party may have different communication roles in relation to different types of messages. For example, a prescriber may have a new prescription message sending role and a prescription dispensing report message-receiving role. A single healthcare party may have both a communicating role and a professional role in the same message. For example a dispensing agent is the originator of a prescription dispensing report and may be the sender of the same message. N Entities/ Interactions Figure N Direct Prescription Digital Signature Entity Relationship Diagram 630 Table N lists the Interactions for each entity directly involved in this Use Case. Table N How To Examples - Entities and Interactions Entities Interactions Physician (Prescribing Physician) Issues Prescription Orders Issues Cancellation Orders Pharmacy (Dispensing Agent) Requests Physician Orders Fills Prescription Orders 27

29 Patient Notifies Patient of Availability Orders Refill Cancels Orders N Primary Case Processing Sequence At the completion of a clinical encounter, the physician creates a new prescription order. The patient requests fulfilment at the clinic s own pharmacy The prescribing physician: o Reviews patient orders o Creates new prescription orders in the clinic s order entry system o Selects the clinic s own pharmacy for fulfilment o Signs the orders o Forwards the orders to the pharmacy via electronic message for fulfilment The pharmacy: o Receives the incoming orders o Verifies the signature of the physician o Verifies the context of the signing ceremony (including role and authority of the signing entity) o Retrieves patient prescription records o Retrieve patient financial / payer records o Fills the prescription order o Notifies the patient of fulfillment The Patient: o Receives the pharmacy notification of fulfilled prescription availability. o Identifies self to the pharmacy. o Authorizes payment. o Requests filled prescription. 28

30 29

31 30

32 660 N Alternate Case Processing Sequence When a patient returns to the clinic and places an order for a expired prescription refill, the pharmacy must contact the prescribing physician for a prescription renewal. The physician cancels the prescription orders, preventing further refills. The patient is notified. The Patient: o Identifies self to the pharmacy. o Defines refill order o Authorizes payment o Signs order o Submits order for prescription refill The Pharmacy: o Receives patient request o Verifies signature of patient o Retrieves patient prescription records o Retrieves patient financial records. o Analyzes prescription refill state o Defines renewal from original prescribing physician o Incorporates patient request, signature and renewal details in physician request o Signs renewal request o Submits renewal request to original prescribing physician The Physician: o Receives the pharmacy request o Verifies signature of pharmacy o Verifies signature of patient o Retrieves patient records o Determines the need for further patient contact o Prepares cancellation request o Signs cancellation request o Submits cancellation request to requesting pharmacy The Pharmacy: 31

33 o Receives cancellation request o Verifies physician signature o Retrieves patient records o Updates patient records o Notifies patient The Patient: o Receives notification of cancellation o Contacts Physician for subsequent clinicial encounter. 32

34 33

35 700 34

36 N Summary Interactions Order Prescription Fill or Refill Patient identifies pending orders and / or existing prescriptions on file at selected pharmacy. Patient selects existing prescription that has no further refills available, and places order. Order incorporates patient signature and payment reference information. 35

37 705 Receive Prescription Order Request Renewal Receive Renewal Request Issue Prescription Orders Notify Patient Physician reviews existing prescription orders for patient and authors new prescription order for patient. Signature identifies physician role and contextual information relating to the action. Pharmacy receives patient refill order. Determines that renewal is required. Identifies prescribing physician. Reviews refill status and age of prescription. Pharmacy receives physician prescription order. Verifies signature and fulfills order. Pharmacy requests prescription orders from appropriate physician. Signed request includes signed patient orders. Physician receives renewal request from pharmacy. Physician verifies signature of pharmacy and patient. Physician retrieves patient records to verify appropriate response. Physician authors new or renewal prescription orders. Signs the orders and forwards to fulfillment entity. Pharmacy notifies patient of action status of order. 710 N.3.4 Electronic Prescription Applications: Prescription Forwarded Through Value Added Network(s) To Pharmacy Using Format Compatible Systems The prescription writing system and the pharmacy intake system communicate through an intermediate value added network service provider. They share the same format for information processing. The data payload does not change, and the VAN can pass through the original signed document. Indicate this forwarding through VAN appending an additional signature reflecting the ASTM defined purpose of Source Signature. 36

38 N Entities / Interactions 715 Figure N Entities In Electronic Prescription Applications: Prescription Forwarded Through VAN To Pharmacy Using Format Compatible Systems Table N How To Examples - Entities and Interactions Entities Physician (Prescribing Physician) Pharmacy (Dispensing Agent) Interactions Issues Prescription Orders Issues Cancellation Orders Requests Physician Orders Fills Prescription Orders Notify Relaying Agent(s) of Fulfilment 37

39 Patient VAN (Relaying Agent(s)) Notify Patient of Prescription Dispensing Notify Alternate Destination of Fulfilment Orders Refill Cancels Orders Receive New Prescription Orders Assign Fulfillment Agent and Forward Prescription Orders Notify Alternate Destination of Assignment 720 N Primary Case Processing Sequence 725 Upon discharge from a clinical encounter, the hospital physician issues prescription orders. These orders are routed to the pharmacy selected by the patient for fulfillment through relaying agent(s). An alternate destination is notified of fulfillment The prescribing physician: o Reviews patient records o Creates new prescription orders in the clinic s order entry system o Signs the orders o Submits the orders The Patient: o Selects Pharmacy o Identifies Self to Pharmacy o Requests Fulfillment of Prescription Orders o Signs request o Submits fulfillment request The pharmacy: o Receives incoming patient fulfillment request 38

40 o Retrieves patient prescription records o Retrieve patient financial / payer records o Verifies the signature of the patient o Identifies relaying agent(s) for physician s prescription orders o Creates request for new prescription from relaying agent(s) o Signs Request o Submits Request to Relaying Agent(s) The Relaying Agent(s): o Receives prescription request from Pharmacy or Relaying Agent o Verifies pharmacy signature o Creates request for new prescription from physician s clinical system o Signs request o Submits request The Physician: o Clinical prescription order system receives Relaying Agent(s) s request o Verifies relaying agent s signature(s) o Documents prescription order transfer including relaying agent(s) and pharmacy identity o Prepares transmission of prescription orders and original physician signature o Submits prescription orders and physician signature to relaying agent(s) The Relaying Agent(s): o Retrieves prescription orders from clinical system or other relaying agent o Verifies physician signature o Signs orders, including original prescription and physician signature o Forwards them unmodified to the requesting pharmacy o Notifies alternate destination of prescription assignment The Pharmacy: o Receives prescription orders from relaying agent(s) o Verifies the signature of the physician o Verifies the signature of the relaying agent(s) 39