Presentation on theme: "Electronic Submission of Medical Documentation (esMD) AoR L2 Harmonization April 24, 2013."— Presentation transcript:
Electronic Submission of Medical Documentation (esMD) AoR L2 Harmonization April 24, 2013
Meeting Etiquette Please announce your name each time prior to making comments or suggestions during the call Remember: If you are not speaking keep your phone on mute Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call –Hold = Elevator Music = very frustrated speakers and participants This meeting, like all of our meetings, is being recorded –Another reason to keep your phone on mute when not speaking! Feel free to use the “Chat” or “Q&A” feature for questions or comments NOTE: This meeting is being recorded and will be posted on the esMD Wiki page after the meeting From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute 2
Agenda 3 TopicPresenter Announcements and Administrative ItemsSweta Ladwa AoR L2 Harmonization – CDA embedded signatures and DSG Deep Dive Zachary May Bob Dieterle
Wednesday, PM ET: eDoC Workgroup meeting –1 - 2 PM ET: eDoC Use Case Meeting –2 - 3 PM ET: eDoC Structured Data SWG Meeting Friday, PM: eDoC Structured Data SWG Meeting Schedule
AoR L2 Digital Signature Deep Dive – DSG Future evolution of standard On trial implementation, current version 8/10/2009. DSG is independent of document type but specification is constrained to XDS environment. Future revisions should have little effect on functionality. Multiple/bundled documents The signature document itself contains a manifest that lists the document IDs for all of the signed documents Multiple signatures XMLDSIG CounterSignature element. Multiple embedded signatures are supported using the CounterSignature unsigned property. A CounterSignature can be qualified by another CounterSignature, and so on. SAML specifies the use of XMLDSIG to sign SAML assertions. Recommendation from AoR L1 IG: Delegation of Rights artifacts associated with documents requiring long term signature validation should conform to the XAdES-X-L digital signature form. The DSG and the SAML assertion are separate elements in AoR L1.
AoR L2 Digital Signature Deep Dive – XAdES Structure
AoR L2 Digital Signature Deep Dive – DSG and SAML
AoR L2 Digital Signature Deep Dive – DSG – XDS Signature Document Content ItemFormatDefinition Signature element, Id attributeOIDUnique identifier for the XDS Signature document CanonicalizationMethod element, Algorithm attribute URIconstant value: #WithCommentshttp://www.w3.org/TR/2001/RECxml-c14n #WithComments SignatureMethod element, Algorithm attribute URIconstant value: DigestMethod element, Algorithm Attribute URIconstant value: Reference element, URI attributetextconstant value: #IHEManifest Reference element, Type attributeURIconstant value: KeyInfo elementcomplexPublic key information for validating signatures X509Certificate elementbase64The actual X.509v3 certificate of the signers, with the public key. This is required for archival validation. QualifyingProperties elementcomplexXaDES data for signature time and certificate validity data SigningTime elementdatetimeTime that signature was created SigningCertificate elementcomplexX.509 identifier of the signing certificates and identifiers for the issuing authorities and parent authorities up to the root authority Signature Policy Identifier elementcomplexIf there is not a specific signing policy to refer to in the schema, then devices that comply with this profile comply with ‘IHEITIDigitalSignatureContentProfile.’
AoR L2 Digital Signature Deep Dive – DSG – XDS Signature Document Content ItemFormatDefinition SignatureProperties elementcomplexContains the extended properties for the signature Signature Property element, ID=”purposeOfSignature” textThe coded value for the purpose of the signature, defined in ASTM E Manifest elementcomplexA list of one or more document reference URIs and digest values to which the signature applies. Manifest element, Id attributetextconstant value: ‘IHEManifest’ Reference element, URI attributeany URIFor XDS documents where the uniqueID is an OID. urn:oid:XDSDocumentEntry.uniqueId e.g. “urn:oid: ” For other documents, any valid urn. Note: For DICOM objects the Unique ID is the SOP Instance UID. For CDA documents that have only an OID, the Unique ID is the OID. For other documents, an OID or other standard URN is required. Transform element, algorithm attributeany URIFor XML objects, use this constant value: #WithComments For DICOM objects, specify the transfer syntax that was used for the hash. All other objects will not have a transfer element and are to be treated as binary BLOBs.
AoR L2 Digital Signature Deep Dive – CDA Future evolution of standard Every document type must be CDA – revisions to CDA post greater risk of losing backwards compatibility. Multiple/ bundled documents CDA documents themselves, and their revisions, replacements, and addenda, are handled by ClinicalDocument.id, ClinicalDocument.setId, and ClinicalDocument.versionNumber. Changes to ParentDocument result in a relatedDocument which can be an addendum to, a replacement of, or a transformation of the ParentDocument. Multiple signatures Limited support via role definitions within header: Author, Authenticator, Encounter Performer, Legal Authenticator, Responsible Party Potentially supported by multiple signature sections (or iterated CounterSignature if supported in CDA). CDA r2 spec notes “Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.” An inserted XML signature section may require harmonization with identifiers currently in CDA header. It is unclear if a SAML assertion could be inserted into the body of a CDA as well, or if it would have to be an external element.
AoR L2 Digital Signature Deep Dive – DSG and CDA DSGCDA Standards evolution Document-independent format Potential future compatibility concerns, but support of HL7 Multiple documents Contains document manifest listing document IDs Internal support, but limited without related document management system (e.g., through XDS) Multiple signatures Achieved via CounterSIgnature and references. SAML assertion separate? If a new signature section is inserted, may require harmonization with header role types. Unclear how delegation of rights would be internalized