IHE Patient Care Coordination Technical Framework Vol I

More documents

Recommendations

Info

PCC Technical Framework V3.0, vol. 1 ________________________________________________________________________ 455 XDS-MS to import medical summaries produced by EHR systems, XDS-I to import imaging information, XDS-Lab to import laboratory reports, et cetera. 2.7.3 Basic Patient Privacy Consents (BPPC) 460 465 This profile provides a mechanism to record the patient privacy consent(s), a method to mark documents published to XDS with the patient privacy consent that was used to authorize the publication, and a method for XDS Consumers to use to enforce the privacy consent appropriate to the use. The XDS profile provides little guidance on supporting privacy policies within an affinity Domain. Documents can be marked with a confidentialityCode, but no information has been provided on how to use this information to support patient privacy concerns. This profile corrects that deficiency by describing a mechanism whereby an Affinity Domain can develop and implement multiple privacy policies, and describes how that mechanism can be integrated with the access control mechanisms supported by the XDS Actors (e.g. EHR systems). There are three key parts of the profile: 1. It provides a content module for capturing a patient consent to a privacy policy or policies. 470 2. It describes how the XDS metadata is used to support the consent policies. 3. Finally it describes the method by which XDS Actors can enforce the privacy policies determined by the document confidentialityCode and the patient privacy consents. 2.7.4 Preprocedure History and Physical (PPHP) 475 This purpose of this content profile is to provide a mechanism to record a pre-procedure assessment, and to communicate that assessment and other relevant documentation, such as laboratory and imaging reports to relevant parties prior to surgery. 2.7.5 Emergency Department Referral (EDR) 480 This profile provides a means to communicate medical summary data from an EHR System to an EDIS System during a referral from a provider to an emergency department. 2.8 Product Implementations 485 Developers have a number of options in implementing IHE actors and transactions in product implementations. The decisions cover three classes of optionality: • For a system, select which actors it will incorporate (multiple actors per system are acceptable). • For each actor, select the integration profiles in which it will participate. • For each actor and profile, select which options will be implemented. _____________________________________________________________________ 17 Revision 3.0 Public Comment — June 25, 2007 Copyright © 1997-2007: ACC/HIMSS/RSNA
PCC Technical Framework V3.0, vol. 1 ________________________________________________________________________ 490 495 500 505 510 All required transactions must be implemented for the profile to be supported (for XDS- MS, refer to the transaction descriptions for XDS in ITI TF-2). Implementers should provide a statement describing which IHE actors; IHE integration profiles and options are incorporated in a given product. The recommended form for such a statement is defined in PCC TF-1: Appendix C. In general, a product implementation may incorporate any single actor or combination of actors. When two or more actors are grouped together, internal communication between actors is assumed to be sufficient to allow the necessary information flow to support their functionality; for example, the Document Source Actor of XDS-MS may use the Patient Identifier Cross-reference Consumer Actor to obtain the necessary patient identifier mapping information from its local patient id to that used in the document sharing domain. The exact mechanisms of such internal communication are outside the scope of the IHE Technical Framework. When multiple actors are grouped in a single product implementation, all transactions originating or terminating with each of the supported actors shall be supported (i.e., the IHE transactions shall be offered on an external product interface). The following examples describe which actors typical systems might be expected to support. This is not intended to be a requirement, but rather to provide illustrative examples. An acute care EMR serving a hospital might include a Document Source Actor, Document Consumer Actor, a Document Repository Actor, a Patient Identification Consumer Actor, as well as a Secured Node Actor. An Ambulatory EMR serving a physician practice might include a Document Source Actor, Document Consumer Actor, a Patient Demographics Client Actor, as well as a Secured Node Actor. _____________________________________________________________________ 18 Revision 3.0 Public Comment — June 25, 2007 Copyright © 1997-2007: ACC/HIMSS/RSNA
Page 1 and 2: ACC, HIMSS and RSNA Integrating the
Page 3 and 4: PCC Technical Framework V3.0, vol.
Page 17: PCC Technical Framework V3.0, vol.
Page 69 and 70:
PCC Technical Framework V3.0, vol.
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
show all

IHE Patient Care Coordination Technical Framework Vol I

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?