Testing Procedures for DS4P Summary testing approach, addressing requirements traceability, and...

Testing Procedures for DS4P

Summary testing approach, addressing requirements traceability,

and Scenario 4 update

What’s new?

• An approach to testing that focuses DS4P-specific aspects– Based on complex/composite privacy policies

• Identify those aspects that enables interoperability– Simple privacy metadata – NEW to DS4P– Reuse of existing transports– Reuse of existing best-practices for trigger, logs, provenance, etc.

• Requirement Traceability– Organized to focus on the DS4P-specific criteria

• Scenario 4– Title 38

• Pull Scenarios 2, 3, 5,6– Due next Monday

Privacy Policies and Interoperability

Privacy Policies are typically composites of simple, basic policies

• Composite privacy policies (e.g. 42CFR Part)comprise of several basic, computable data sharing policies

• Privacy metadata used to represent simple data sharing policies:

• Confidentiality level• Purpose of use/disclosure• Information source is a covered substance abuse

treatment• Consent required for disclosure/re-disclosure

– Privacy metadata allows loosely-coupled systems and organization to exchange the most meaningful metadata related to the data shared among systems/organizations

• Information exchanged may reference basic data sharing policies as privacy metadata– Confidentiality Code– Purpose of Use Code– Obligation Code– Refrain Policy Code

42 CFR Part 2

Purpose = Treatment

Obligation= Require Consent

Confidentiality = Restricted

Basic Data

Sharing Policy

Basic Data Sharing Policy

Composite Privacy Policy

Privacy Metadata used in Information Exchange to specify simple data exchange policies across organizations

For treatment purpose

No re-disclosure

Restricted

Summary Document

Transport Metadata

DocumentSectionSection Section

Senders determine what information is protected and marks it “restricted” in the document

Restricted document

Summary Document

DS4P Specifics are the focus of our inspection testing

class Testing Approach

Transport-specific Metadata

«value set»HL7 Obligation

Policy

+ oid = ?

«value set»HL7 Refrain

Policy

+ oid = ?

«value set»HL7 Purpose of

Use

+ oid = ...

«value set»HL7

Confidentiality

+ oid = ...

C-CCD

+ confidentialityCode :HL7 Confidentiality+ privacyNotificaiton :narrative

CDA R2

+ confidentialityCode :HL7 ConfidentialityXD* Metadata (XDS, XDR, XDM)

+ confidentialityCode :HL7 Confidentiality+ purposeOfUseCode :HL7 Purpose of Use+ obligationCode :HL7 Obligation Policy+ refrainPolicyCode :HL7 Refrain Policy

Extended C-CCD with Entry-level Metadata

+ securityObservation_Obligation :HL7 Obligation Policy+ securityObservation_Refrain :HL7 Refrain Policy+ securityObservation_Purpose :HL7 Purpose of Use

constrains

extends

We need to specify the OID

Summary

• Conformance Statements can be organized into – Data

segmentation specific

– Transport-specific– Generic best

practice• E.g. use ATNA

pkg Conformance Statements

Conformance Statements

+ Conformance Statements+ Data Segmentation Functional and Data Conformance+ Transport-Specific Conformance+ Generic Requirements+ Marked for deletion

(from Requirements Traceability Matrix)Data Segmentation Functional and Data Conformance

+ Data Segmentation Functional and Data Conformance+ Confidentiality Code+ Facility Code+ Obligation/Refrain Code+ Purpose of Use+ Sensitive Data Criteria+ Functional Criteria+ Privacy Consent+ Provenance/Authorship+ Entry-Level Extensions

Transport-Specific Conformance

+ Direct+ NwHIN Exchange

Generic Requirements

+ General+ CDA Implementation Conformance

object Requirements Traceability Matrix

Implementaiton Guide Conformance Summary

Conformance Criteria are used as traceability requirements

Conformance statements related to confidentiality

codes

Conformance statements related to facility codes

object Requirements Traceability Matrix

Implementaiton Guide Conformance Summary

Errors are easy to spot: obligation code intended to use obligation or refrain policy?

Repetitive reference the same value set could be avoided

pkg Data Segmentation Functional and Data Conformance

Confidentiality Code

+ IG3.1.1.2.1#2: The metadata/annotation SHALL include:? A confidentiality indicator (MUST be represented as a confidentialityCode if the patient data is formatted as a CDA R2 document)? An obligation policy (e.g. prohibition on re-disclosure without co+ IG3.1.2.1.1#4.1: Patient data that is classified as V (Very Restricted) MUST be segmented and excluded.+ IG3.1.2.1.1#4.2: Very Restricted (V) patient data MAY require explicit approval from the Chief Privacy Officer to disclose this type of information.+ IG3.1.2.1.2#1: Patient data for disclosure MUST be segmented into specific sensitivity levels (e.g. low through restricted).+ IG3.1.3#1.3: Use of confidentialityCodes MUST be used in a way to ensure semantic interoperability. Ensure that additionally protected data elements are referenced accordingly in the use case document.+ IG3.1.3#2: For all scenarios defined in the Data Segmentation Use Case, the transport mechanism metadata MUST be the MOST restrictive confidentialityCode (i.e. the 'high water mark').+ IG3.1.3.1#1: The ClinicalDocument/confidentialityCode SHALL be assigned by the provider or system in accordance with jurisdictional or organizational policy and any applicable consent directive+ IG3.1.3.1#2: confidentialityCode@code SHALL be present in the XD* metadata+ IG3.1.3.1#3: The confidentialityCode defined in the XD* metadata SHALL align to the confidentialityCode defined in a CDA R2 Header, IF a CDA R2 document is used to exchange patient data.+ IG3.1.3.1#4: The HL7 ConfidentialityCode defined in the CDA R2 Header SHALL govern the entire CDA R2 clinical document unless overridden by Confidentiality Code elements at the CDA R2 Section level+ IG3.5.1#1: If the confidentialityCode in the XD* metadata is set to V (Very Restricted)CDA R2 Header MUST be set to Very Restricted+ IG3.5.1#2: If the confidentialityCode in the XD* metadata is set to R (Restricted)CDA R2 Header MUST be Restricted+ IG3.5.1#3: If the confidentialityCode in the XD* metadata is set to N (Normal)The XDSDocumentEntry MUST match the highest confidentiality level+ IG3.5.2#1: The document-level confidentialityCode SHALL be N if any level of segmentation is not required.+ IG3.5.2#2: The sending system MUST assign a confidentialityCode to a CDA document by using the <confidentialityCode> element in the CDA R2 Header, prior to sending patient data to a receiving system.+ IG3.5.2#3: The confidentialityCode used within the CDA R2 Header MUST be from the HL7 BasicConfidentialityKind value set.+ IG3.5.2#4: A sending system MUST assign a confidentiality code within the XDR/XDS[/XDM] metadata even if they have also assigned a <confidentialityCode> element at the level of the CDA R2 Header.+ IG3.5.2#5: The CDA R2 Header SHALL contain exactly one [1..1] confidentialityCode.+ IG3.5.2#6: Implementations CANNOT use multiple confidentialityCode values within the CDA R2 Header.+ IG3.6.1#1: It is important to note that if a CDA Section-level confidentiality code is applied, all CDA entries and CDA entry relationships MAY inherit that specific confidentiality Code as well+ IG3.7.1#4: CDA R2 Header MUST be set to Very RestrictedAny sections that contain sensitive patient data MUST have either an R or V confidentiality code applied, and this MUST NOT conflict with the underlying entry level tagging for each CDA <entry> and + IG3.7.1#5.1: CDA R2 Header MUST be RestrictedAny sections that contain sensitive patient data MUST have an R confidentiality code applied, and this MUST NOT conflict with the underlying entry level tagging for each CDA <entry> and <entryRelationship> co+ IG3.7.1#6.1: CDA R2 Header MAY be set to NormalAny section MAY use an R or V confidentiality code but the receiving system is NOT REQUIRED to process it.+ IG3.7.1#7: Any section MAY use an R or V confidentiality code but the receiving system is NOT REQUIRED to process it.

Functional Criteria

+ Generic Privacy Policy based Criteria+ Sender/Receiver Criteria

Obligation/Refrain Code

+ IG3.7.2#4: Implementers SHOULD use this [cite value set] value set when defining the Obligation Code data element+ IG3.8.6#1.1: Thus, obligation codes MAY be specified as part of the XD* metadata that is associated with specific patient data, and also at the document, section, and entry level of a CDA R2 document type.+ IG3.8.6#1.2: The obligation code SHOULD ideally be included within the policy that is being referenced.+ IG3.8.6#10.1: Using XACML: If this approach is used, the recipient MUST use an XACML policy engine to decrypt information associated with an obligation.+ IG3.8.6#10.2: [Using XACML: If this approach is used,] The recipient MUST request the key to decrypt the information associated with obligation, and promise to fulfill the requirements of the obligation in order to receive the key.+ IG3.8.6#11: Push Based Model Ð Include in MetadataThe main risk with this approach is that a receiving system is NOT REQUIRED to honor this obligation code, as the obligationCode data element MUST be optional.+ IG3.8.6#2: A sending system MAY use obligation codes if the level of sensitivity for the information is considered high enough to warrant its inclusion.+ IG3.8.6#3: The sending system that chooses to use obligation codes MAY use values from the HL7 Obligation Policy value set 2.16.840.1.113883.1.11.20445.+ IG3.8.6#4: The sending system that chooses to use obligation codes MAY use values from the HL7 Refrain Policy value set.+ IG3.8.6#5: The sending system SHOULD include the obligation code within the relevant policy or consent directive that is being referenced.+ IG3.8.6#6: The exact location of the obligation code can vary. As noted, it is preferable that the obligation code NOT be directly included in a transaction, although the option is available if the sending system wishes to do so. The S&I Framework agrees + IG3.8.6#7.1: Thus, obligation codes MAY be specified as part of the XD* metadata that is associated with specific patient data, and also at the document, section, and entry level of a CDA R2 document type.+ IG3.8.6#7.2: A sending system MAY use obligation codes if the level of sensitivity for the information is considered high enough to warrant its inclusion.+ IG3.8.6#7.3: The sending system that chooses to use obligation codes MAY use values from the HL7 Obligation Policy value set 2.16.840.1.113883.1.11.20445.+ IG3.8.6#7.4: The sending system that chooses to use obligation codes MAY use values from the HL7 Refrain Policy value set.+ IG3.8.6#7.5: The sending system SHOULD include the obligation code within the relevant policy or consent directive that is being referenced. The exact location of the obligation code can vary. As noted, it is preferable that the obligation code NOT be di+ IG3.8.6#8: Include Obligations (meaning a way to convey policies) as a new element in the XDS Document Entry Metadata. Document Entry Metadata is extended to include Obligations to fulfill a gap that expresses policy to the recipient, recognizing that p+ IG3.8.6.1#1: Implementers SHOULD use the HL7 ObligationCode vocabulary.

Sender/Receiver Criteria

+ IG3.1.2.2.1#1: The receiving system MUST parse the patient data disclosure from the outside in (e.g. secure mail attachments, XDS document package).? The assumption is that the receiving system would start with SOAP metadata, [SMTP Header,] then evaluat+ IG3.1.2.2.1#2: In addition to the confidentiality indicator, the receiving system SHALL use other privacy metadata (e.g. purpose of use, obligations, privacy consent) to determine how to segment and handle the health data received from another organizatio+ IG3.1.2.2.2#1: The receiving system MAY accepts the disclosed data and persists it for permanent storage using the metadata provided by the sender for retrieval and to control further access or re-disclosure.+ IG3.1.2.2.3#1: The receiving system MUST reconcile the privacy metadata of the data received, the obligations associated by the sender, and privacy consent provisions with its own local policy.+ IG3.1.2.2.3#2: The receiving system MUST validate the patient disclosed data and its own ability to persist the contents.+ IG3.1.3#1.1: There MAY be a need for some level of policy catalog to dictate the combinations of data that would be affected by specific, pre-defined policies.+ IG3.2#1.3: Specifically, sending and receiving systems SHOULD evaluate result codes and result types for their level of sensitivity prior to the disclosure of patient data.+ IG3.2#2.4: Specifically, sending and receiving systems SHOULD evaluate procedure codes for their level of sensitivity prior to the disclosure of patient data.+ IG3.2#3.3: Specifically, sending and receiving systems SHOULD evaluate medication codes for their level of sensitivity prior to the disclosure of patient data.+ IG3.2#4: Specifically, sending and receiving systems SHOULD evaluate diagnosis codes for their level of sensitivity prior to the disclosure of patient data.+ IG3.2.1#1: The privacy consent MAY specify that specific protected information is not to be disclosed (e.g. heroin addiction is filtered but alcohol addiction is not to be disclosed).+ IG3.2.2.1#1: The sending system MUST specify whether the document is a new/original, replacement, or amendment to an existing document.+ IG3.2.2.2#1: The HIE provides access to the Healthcare Provider Directory where the sender's identity SHOULD be available.+ IG3.2.2.3#2: The receiving system SHOULD persist the associated metadata with the document if the receiving organization intends to re-disclose this patient data at a future date. In the event the documents are re-disclosed, this receiving system will enf+ IG3.3#1: To support segmentation, a sending system MAY choose to remove patient data it deems sensitive from the payload that it plans to send to the receiving system. Different methods of this approach include:? Removal by not including the patient dat+ IG3.8.1#1.1: Coverage type codes MAY be used to identify the types of coverage used to pay for services documented in the information intended for disclosure.+ IG3.8.1#1.2: The sending and receiving systems MAY use this [coverage type code] information as part of annotations that are made to patient data in making determinations on the patient data they allow to be disclosed.

(from Functional Criteria)

Generic Privacy Policy based Criteria

+ IG3#1: The recommendation of the S&I Framework Data Segmentation initiative is to focus on use of XD* Metadata attributes to provide initial segmentation at a high level.+ IG3.1.1.1.1#1: Upon receiving a request to disclose identifiable health information of a client, the sending system MUST analyze the client's records to determine whether any of the information requested is protected according to applicable jurisdictional+ IG3.1.1.1.1#2: The sending system SHALL use intrinsic information in the health record to determine if any protected information based one or more of the following criteria:? the type of provider who created the information (e.g. substance abuse 42 CFR + IG3.1.1.1.1#3: The sending system MUST use applicable privacy policies as well as the criteria asserted in the request (e.g. purpose of use, intended recipients) to determine whether the information intended for disclosure to a third-party is protected.+ IG3.1.1.1.2#1: The sending system MUST verify whether a privacy consent that allows the disclosure exists and it identifies the requester of the information as its intended recipient+ IG3.1.1.1.2#2: If the sending system does not already have a privacy consent available (e.g. on file, in a remote repository, etc.) for the intended recipient, the sending system MUST prompt the end-user to ask the client for a privacy consent to authoriz+ IG3.1.1.1.2#3: If the client does not grant the privacy consent then all or some of the patient data SHALL not be disclosed.+ IG3.1.1.1.2#4: If the sending system can verify that the consent allows the disclosure requested,then the disclosure MAY proceed.+ IG3.1.1.1.2#5: The patient consent directive MAY be conveyed to the receiving system Ð for example, as an explicit transaction where the sending system sends the receiving system the patient consent directive or a reference to a privacy consent registry a+ IG3.1.1.1.2#6: If the request for information is asserting an emergency from a trusted system, then the consent SHALL NOT be required to send substance abuse information (i.e. 42 CFR Part 2).+ IG3.1.1.1.2#7: If an exchange of patient data contains no protected information, the sending system DOES NOT have to provide any additional metadata.+ IG3.1.1.1.3#1: The sending EHR system MUST add privacy metadata (i.e. annotations) to identify protected health information at the envelope and in specific sections of documents and messages exchanged.+ IG3.1.1.1.3#2: The privacy metadata/annotation MUST include the qualifiers specified in the data set (e.g. confidentiality code, purpose of data, obligations on receivers of data).+ IG3.1.1.1.3#3: The sending system MUST send the information only to trusted systems able to enforce the privacy metadata/annotations.+ IG3.1.1.2.1#1: The receiving system MUST process the privacy metadata (e.g. annotations) sent along with the health information from the sending system.+ IG3.1.1.2.1#3: These annotations MUST be validated and persisted by the RECEIVING (EHR) system along with the provenance of the information and other clinical context (e.g. a referral, consult).+ IG3.1.1.2.1#4: If the annotations cannot be validated (e.g. confidentiality code is not valid) then the receiving system MUST notify the sending system that the annotations provided CANNOT be validated.+ IG3.1.1.2.2#2: The receiving system MUST enforce the annotations related to confidentiality, obligations, and purpose associated with health information received from other organizations in order to prevent unauthorized disclosures.+ IG3.1.1.2.3#1: In the event the clinicians need to re-disclose health information originally disclosed by another organization, the receiving system MUST make use of the provenance of the information and associated privacy annotations to determine whether+ IG3.1.1.2.3#2: The receiving system MUST verify whether the patient's privacy consent allows the disclosure of protected health information+ IG3.1.1.2.3#3: The receiving system MUST be able to use the privacy metadata/annotations received along with the protected health information, to ensure downstream re-disclosures are performed in conformance with the obligations specified by the source pr+ IG3.1.2.1.1#1: The data MAY be any patient data that the sending system deems necessary to disclose, such as a summary document, query, clinical-initiated referral, etc.+ IG3.1.2.1.1#3: The sending system SHOULD use the following criteria in determining the data selected for disclosure:? Privacy policies that identify protected information? Sender's local privacy policies based on intended recipient? Sender's data us+ IG3.1.2.1.1#5: Some protected data (e.g. substance abuse) MUST be associated with an explicit privacy consent from the patient. The consent MUST be already on file or MUST be collected and recorded.+ IG3.1.2.1.1#6: Any restricted data as defined in the privacy consent from the patient MUST be segmented and excluded from disclosure.+ IG3.1.2.1.2#2: In order to assign privacy metadata to information that must be disclosed, consent MUST be granted and the receiving system MUST be made aware that it needs to fulfill some conditions regarding its re-disclosure.+ IG3.1.2.1.3#1: To support HIPAA Privacy Rule "Accounting of disclosures" rule, the sending system SHALL record:? The disclosure event:? Data disclosed? Approximate day/time or interval of disclosure? Purpose of disclosure/use? Recipient identity+ IG3.1.2.1.4#1.1: An out-of-band policy negotiation MAY be needed to complete this disclosure.+ IG3.1.2.1.4#1.2: If the receiving system is not capable to protect electronic health data (through the processing of disclosure metadata), then the providers MUST use other means (e.g. paper) to communicate.+ IG3.1.2.1.4#2: Prior to sending any patient data, the sending system MUST verify that the following exists:? Provenance metadata (authorship) has been established? Destination metadata (information recipient) has been defined? Privacy metadata (e.g.+ IG3.8.6#9: Sending the patient consent directive which would need to include these obligations within the structure of the HL7 CDA Consent Directive DSTU standard+ IG4.6.1#2: In addition, when receiving the patient data, the following metadata MAY apply for implementation:JurisdictionThe recommendation for a jurisdiction metadata attribute is to obtain this value directly from the patientÕs consent directive by + IG5.1#2: Recommend usage of document-level tagging if the responding system believes there is sensitive information involved in the exchange.

(from Functional Criteria)

Purpose of Use

+ IG2.7.1#2: Implementers MUST use the HL7 Purpose of Use Value Set+ IG3.7.2#6: Implementers SHALL use this [cite value set] value set when defining the Purpose of Use data element.+ IG3.8.2#3: The sending system that chooses to use purpose of use codes SHALL use values from the HL7 Purpose of Use value set.

Sensitive Data Criteria

+ IG3.2#1.1: As recommended by the Health IT Standards Committee, result codes SHOULD be defined using LOINC.+ IG3.2#1.2: Sending and receiving systems MUST be able to validate and evaluate LOINC values as defined in a CDA R2 document type to be able to implement this guide.+ IG3.2#2.1: As recommended by the Health IT Standards Committee, procedure codes SHOULD be defined using ICD-9 (and ICD-10 as of 2014).+ IG3.2#2.2: Support [for ICD-9 (and ICD-10 as of 2014)] SHOULD also be in place+ IG3.2#2.3: Sending and receiving systems SHOULD be able to validate and evaluate ICD-9 and/or ICD-10 values as defined in a CDA R2 document type when applied to inpatient procedures to be able to implement this guide.+ IG3.2#2.4: Sending and receiving systems SHOULD also be able to support CPT-4 and HCPCS terminologies when applied to outpatient, ED, or physician office procedures.+ IG3.2#3.1: As recommended by the Health IT Standards Committee, medication codes SHOULD be defined using RxNORM.+ IG3.2#3.2: Sending and receiving systems MUST be able to validate and evaluate RxNORM values as defined in a CDA R2 document type to be able to implement this guide.+ IG3.2#4: As recommended by the Health IT Standards Committee, diagnosis codes SHOULD be defined using SNOMED-CT.+ IG3.2#4: Sending and receiving systems MUST be able to validate and evaluate SNOMED-CT codes as defined in a CDA R2 document type to be able to implement this guide.+ IG3.8.1#2: Implementers SHALL use the ASC X12 5010 coding system to define insurance coverage

Privacy Consent

+ IG3.7.2#3: The Refrain Policy value set MAY be used to support additional information within a Patient Consent Directive associated with protected diagnoses+ IG3.8.5#2: Push Based model Include in Consent Directive as separate documentIn this approach, sensitivity codes are included within the CDA Consent Directive document. The CDA Consent Directive SHALL contain sensitivity codes within the Information T+ IG3.8.5#3: Push Based model Include in Consent Directive and send consent directive and patient data togetherIn this approach, sensitivity codes are included within the CDA Consent Directive document, but both the consent directive and the patient

Provenance/Authorship

+ IG2.9#1: The specific attributes inside the document MUST show their own provenance in the context of that document.+ IG2.9#2: The recommendation of this implementation guide is that metadata that defines provenance is established at the level of the patient data (the document/payload). Thus, provenance SHOULD be primarily established through the use of XD * metadata, wi+ IG3.1.1.2.2#1: The receiving system MUST ensure that the provenance of patient data is tracked.

Entry-Level Extensions

+ IG3.1#1: To support 42 CFR Part 2 exchanges, entry level tagging MAY be used to provide more granular annotation of patient data, and to specifically identify where data may not be re-disclosed.+ IG3.7#1: Optimally for this method of tagging, the policy SHOULD be expressed as a XACML rule. (ID)+ IG3.7#2: If using entry-level tagging, an ID MUST be provided to the policy or consent directive being referenced.+ IG3.7#3: A coded value MAY be provided depending on its availability+ IG3.7#4: This is the URL reference to the external document and MUST be included so that it can be processed by the receiving system. The URL is created by using a reference value tag, which points to the URL. (Text)+ IG3.7.1#1: The externalDocument reference SHALL have [0..*] Consent Directive or Privacy Policy Type act.Codes and IDs.+ IG3.7.1#2: The typeCode for the reference association class MUST be REFR.+ IG3.7.1#3: The externalDocument MAY embed renderable textual or multimedia description (or reference to a description) of the complete Consent Directive, Privacy Policy, or Prohibition Against Redisclosure, which would reasonably be expected to be display+ IG3.7.1#5.2: CDA Entry Level Tagging MAY contain the externalPolicyReference that points to the specific restrictions.+ IG3.7.1#6.2: No entry level tagging [for CDA R2 documents] would be expected by the receiving system, and the receiving system WOULD NOT be required to process it.+ IG3.7.2#5: Implementers SHOULD use this [cite value set] value set when defining the Policy Reference data element.+ IG3.7.4#1: XACML MAY be used to point when policyReferences are made to external policies that is machine computable+ IG3.8.5#1: Push Based Model Include in MetadataXDM supports the ability to extend metadata, and a slot for SensitivityCode MAY be added to the XDM metadata that is provided to the receiving system.The main risk with this approach is that a receiv

Confidentiality Code

Functional

Obligation/Refrain

Purpose of use

Data Criteria

Privacy Consent

Provenance

Extensions – entry-levelDat

a Se

gmen

tatio

n Co

nfor

man

ce C

riter

iaSender/Receiver

Policy-based functionality

Choreography User Story 1.1.C: Setup and Testing the Sending EHR system

«Business trigger»Patient Requests Disclosure

Patient was notified of Title 38 privacy

1. Clerk records privacy consentin EHRS allowing Patient X data

to be transmitted to thedesignated PCP.

«EHR Data»Privacy Consent

Preferences

«Sending System» ADATP EHR SystemAlcohol and Drug Abuse Treatment Program (ADATP) at the VA

Verify the privacy consent is persisted by the EHR

2. Provider sets up Patient Xdata to transmitted to the PCP

Data is missing or incomplete

3. Provider sends data forPatient X to another provider

«Outbound Message»Data specified to be sent to the

PCP

Verify data disclosed and intended recipient match the privacy consent preferences

4. EHRS sends PatientX data electronicallyto the intended PCP

Complete scenario

Metadata or data is incorrect/incomplete.

The specific trigger for an electronic transmissionis triggered may vary across systems.

confidentiality = R (Restricted)purpose = treatmentintended recipient = Patient X PCPadditional obligation= do not redisclosedata set = all data

3.1.1.1.1. Identify information that is restricted/protectedby policy3.1.1.1.3. Add privacy metadata to health information disclosed to other organizations 5.4. Provide Patient Data and Restrictions on Use of Data

3.6. Section Level Tagging 3.7.2. Conformance Criteria for Segmentation Vocabularies 3.8.2. Purpose of Use Value Set 3.8.3. Healthcare Facility Type Codes 3.8.6. Use of Obligation Codes 3.8.6.1. Obligation Code Value Set7.1. Sending a set of clinical documents with differing levels of tagging 7.2. Sending a discharge summary in a care transition

«Test Suite» Sending System Testing

Verify disclosure was logged by the sending system

Log disclosureevent

Logging failed

Patient Requests Changes to Privacy Policy for anysubsequent transmissions

Additional encounters

fail

failed

pass

pass

fail

pass

yes

no







Preferences







PCP



Complete scenario








Log disclosureevent

Logging failed



fail

failed

pass

pass

fail

pass

yes

noPatient changes mind

and…







Preferences







PCP



Complete scenario








Log disclosureevent

Logging failed



fail

failed

pass

pass

fail

pass

yes

no

… the new preferences recorded…







Preferences







PCP



Complete scenario








Log disclosureevent

Logging failed



fail

failed

pass

pass

fail

pass

yes

no

… applied to segmentation.

Business Process User Story 1.1.C: Sending EHR Testing Procedure

«Test» Validate Privacy ConsentPersistence

«Test» Validate disclosed data«Test» Validate D

isclosureLogging


Logging failed

2. Verifiy CDA R2Header

3. Verify (optional)Section Level Tagging

1. Verify ConsentPersistence

4. Verify (optional)Entry-level Tagging

5. Verify Purposeof Use Value Set

6. Verify (optional)Healthcare Facility Type

Codes

7. Verify the use ofObligation Codes

8. Verify ConsentPreferences are

revised

failed

Send

ing

Syst

em T

est P

roce

dure

Change mind...

Choreography User Story 1.1.C: Setup and Testing the Receiving System

«Receiving System» PCP EHR System

1. Process transmission

2. User requestsinformation, the systemdisplays CDA documents

Patient X data and privacy metadata

Verify that the data is persisted correctly in the receiving system

Missing/incomplete data

Verify that the privacy notice is displayed

Document(s) are invalid, missing information, missing privacy notice

Rendered Patient X data and privacy metada

Procedure complete

3.1.1.2.1. Process privacy metadata associated health information received from other organizations.


«Test Suite» Receiving SystemTesting

Receive directed transmission

passed

passed

Rece

ivin

g Sy

stem

Pro

cess

Procedure repeated after the patient

changes her mind...

Business Process User Story 1.1.C: Receiving System Testing Procedure

«Test» Validate Inbound Data Persistence

«Test» Validate data displayed

1. Verify CDA headermetadata is

persisted

7.Verify Data Contents and PrivacyRe-Diclosure Notification

2. Verify (optional) SectionLevel Tag Persistence

3. Verify (optional) Entry LevelTag Persistence

4. Verify the Purposeof Use is persisted

correctly

5. Verify (optional) HealthcareFacility Type Code persistence

6.Verify the persistence ofObligation Codes

8. Repeat Procedure after theprrefrences are changed and

information resent

Rece

ivin

g Sy

stem

Tes

t Pro

cedu

re

Change mind...

Testing Procedures for DS4P Summary testing approach, addressing requirements traceability, and...

Documents

Transcript of Testing Procedures for DS4P Summary testing approach, addressing requirements traceability, and...