|
|
| (6 intermediate revisions by the same user not shown) |
| Line 3: |
Line 3: |
| Volume=Volumes I and II| | | Volume=Volumes I and II| |
| Revision=2.0| | | Revision=2.0| |
| Year=2006-2007| | | Year=2007-2008| |
| Status=Draft}} | | Status=Comment}} |
|
| |
|
| {{Comments on IHE Technical Frameworks}} | | == Comments == |
| | {{:Comments on IHE Technical Frameworks}} |
|
| |
|
| {{Forward to the Technical Framework}} | | {{:PCC TF/Forward|Forward}} |
|
| |
|
| ===Content of the Technical Framework === | | ===Content of the Technical Framework === |
| Line 21: |
Line 22: |
| {{How to Contact Us}} | | {{How to Contact Us}} |
|
| |
|
| =Volume 1=
| | [[PCC TF-1]] |
| {{Title Page|
| |
| Domain=Patient Care Coordination|
| |
| Volume=Volumes I|
| |
| Revision=2.0|
| |
| Year=2006-2007|
| |
| Status=Draft}}
| |
| {{:Preface to Volume I of the PCC Technical Framework}}
| |
|
| |
|
| {{:Introduction to the PCC Technical Framework}}
| | [[PCC TF-2]] |
| ===History of Annual Changes===
| |
| In the 2005-2006 cycle of the IHE Patient Care Coordination initiative, the first release of the IHE PCC Technical Framework introduced the following integration profile:
| |
| | |
| * '''Cross-Enterprise Sharing of Medical Summaries (XDS-MS) –''' a mechanism to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings. Medical Summaries are commonly created and consumed at points in time of transfers of care such as referrals or discharge.
| |
| | |
| In the 2006-2007 cycle of the IHE Patient Care Coordination initiative, the follow integration profiles were added to the technical framework.
| |
| | |
| * '''Exchange of Personal Health Record Content (XPHR) –''' provides a standards-based specification for managing the interchange of documents between a Personal Health Record used by a patient and systems used by other healthcare providers to enable better interoperability between these systems.
| |
| * '''Basic Patient Privacy Consents (BPPC) –''' enables XDS Affinity Domains to be more flexible in the privacy policies that they support, by providing mechanisms to record patient privacy consents, enforce these consents, and create Affinity Domain defined consent vocabularies that identify information sharing policies.
| |
| * '''Preprocedure History and Physical Content Profile (PPHP) –''' supports the exchange of information allowing for the assessment and amelioration of risks related to a procedure.
| |
| * '''Emergency Department Referral Profile (EDR)''' '''–''' provides a means to communicate medical summary data from an EHR System to an EDIS System.
| |
| | |
| {{:About the Patient Care Coordination Integration Profiles}}
| |
| | |
| {{:Dependencies of the PCC Integration Profiles}}
| |
| | |
| {{:PCC Integration Profiles Overview}}
| |
| | |
| {{:Product Implementations}}
| |
| | |
| {{:Cross Enterprise Sharing of Medical Summaries (XDS-MS) Integration Profile}}
| |
| | |
| {{:Exchange of Personal Health Record Content (XPHR) Integration Profile}}
| |
| | |
| {{:Basic Patient Privacy Consents (BPPC) Integration Profile}}
| |
| | |
| {{:Emergency Department Referral (EDR) Integration Profile}}
| |
| | |
| {{:Preprocedure History and Physical (PPHP) Integration Profile}}
| |
| | |
| =Appendix A - Actor Descriptions=
| |
| Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise.
| |
| | |
| ; [[Content Creator]] : The Content Creator Actor is responsible for the creation of content and transmission to a Content Consumer.
| |
| | |
| ; [[Content Consumer]] : A Content Consumer Actor is responsible for viewing, import, or other processing of content created by a Content Creator Actor.
| |
| | |
| =Appendix B - Transaction Descriptions=
| |
| Transactions are interactions between actors that transfer the required information through standards-based messages. The PCC Technical Framework does not define any specific transactions, as these are assumed to be carried out through the use of transactions defined in other IHE Profiles.
| |
| | |
| =Appendix C - How to Prepare an IHE Integration Statement=
| |
| {{:How to Prepare an IHE Integration Statement}}
| |
| | |
| =Glossary=
| |
| See also [[Glossary]]
| |
| ; Actor : An entity within a use case diagram that can perform an action within a use case diagram. Possible actions are creation or consumption of a message
| |
| ; ADT: Admit, Discharge & Transfer.
| |
| ; Affinity Domain Policy: Affinity Domain Policy that clearly defines the appropriate uses of the XDS Affinity Domain. Within this policy is a defined set of acceptable use Privacy Consent Policies that are published and understood.
| |
| ; ASTM: Formerly the American Society of Testing and Materials, now ASTM International. An SDO that develops a number of standards across a wide variety of industries, including healthcare.
| |
| ; ATNA: Audit Trail and Node Authentication. An IHE ITI profile.
| |
| ; Care Context:
| |
| The participations surrounding the care provision act, and the attributes of that act. Everything in the document header. Data history, links to clinical reasoning.
| |
| ; CDA: Clinical Document Architecture. An HL7 standard for the exchange for clinical documents.
| |
| ; Content Binding: A content binding describe how the payload used in an IHE transaction is related to and/or constrained by the data elements contained within the content sent or received in those transactions.
| |
| ; CRS: Care Record Summary. An implementation guide that constrains CDA Release 2 for Care Record Summary documents.
| |
| ; CT: Consistent Time Integration Profile.
| |
| ; DICOM: Digital Imaging and Communication in Medicine
| |
| ; DSG: Digital Signatures. An IHE ITI Profile.
| |
| ; EDIS: Emergency Department Information System.
| |
| ; eMPI: Enterprise Master Patient Index.
| |
| ; EMR: Electronic Medical Record, an Electronic Health Record system used within an enterprise to deliver care (also called EHR-CR by IHE-XDS).
| |
| ; Estimated Time of Arrival: the time the patient being referred can be expected to arrive in the emergency department.
| |
| ; EUA: Enterprise User Authentication Integration Profile.
| |
| ; Expected Actions: Actions which should occur as the result of a trigger event.
| |
| ; Functional Role: Role an individual is acting under when they are executing a function. See ISO 21298
| |
| ; HIMSS: Healthcare Information and Management Systems Society.
| |
| ; HL7: Health Level Seven
| |
| ; HIS: Hospital Information System.
| |
| ; IHE: Integrating the Healthcare Enterprise.
| |
| ; Interaction Diagram: A diagram that depicts data flow and sequencing of events.
| |
| ; IT: Information Technology.
| |
| ; MPI: Master Patient Index.
| |
| ; MRN: Medical Record Number.
| |
| ; NAV: Notification of Document Availability
| |
| ; OID: Object Identifier. (See also <nowiki>'</nowiki>Globally Unique Identifier<nowiki>'</nowiki>).
| |
| ; Patient Privacy Consent: The act of a patient consenting to a specific Privacy Consent Policy.
| |
| ; Patient Privacy Consent Document: A document that follows the BPPC profile and captures the act of the patient consenting to a specific XDS Affinity Domain defined Privacy Consent Policy.
| |
| ; Patient Identifier Cross-reference Domain: Consists of a set of Patient Identifier Domains known and managed by a Patient Identifier Cross-reference Manager Actor. The Patient Identifier Cross-reference Manager Actor is responsible for providing lists of "alias" identifiers from different Patient Identifier Domains.
| |
| ; Patient Identifier Domain: A single system or a set of interconnected systems that all share a common identification scheme for patients. Such a scheme includes: (1) a single identifier-issuing authority, (2) an assignment process of an identifier to a patient, (3) a permanent record of issued patient identifiers with associated traits, and (4) a maintenance process over time. The goal of Patient Identification is to reduce errors.
| |
| ; PDF: Portable Document Format.
| |
| ; PIX: Patient Identifier Cross Referencing. An IHE ITI Profile.
| |
| ; PDQ : Patient Demographics Query. An IHE ITI Profile.
| |
| ; PHR: Personal Health Record
| |
| ; Privacy Consent Policy: One of the acceptable-use Privacy Consent Policies that are agreed to and understood in the Affinity Domain.
| |
| ; Privacy Consent Policy Act Identifier: An Affinity Domain assigned identifier that uniquely defines the act of a patient consenting to a specific Affinity Domain: Privacy Consent Policy.
| |
| ; Privacy Consent Policy Identifier: An Affinity Domain assigned identifier (OID) that uniquely identifies the Affinity Domain: Privacy Consent Policy. There is one unique identifier (OID) for each Privacy Consent Policy within the Affinity Domain.
| |
| ; Procedure: In the context of a "Pre-procedure History and Physical," the "procedure" is a surgery or an invasive examination of a patient that is required by quality review organizations to be preceded by a pre-procedure assessment of procedure risk and anesthesia risk. This assessment is typically referred to as a "Pre-operative" or "Pre-procedure History and Physical."
| |
| ; Process Flow Diagram: A graphical illustration of the flow of processes and interactions among the actors involved in a particular example.
| |
| ; Proposed disposition: the intended disposition (i.e. admission to ICU, discharge to home, transfer to psychiatric hospital), if known, that the referring provider expects the patient will end up after the emergency department intervention.
| |
| ; Role: The actions of an actor in a use case.
| |
| ; RSNA: Radiological Society of North America.
| |
| ; sig.: A Latin abbreviation for signetur used to represent the instruction following the medication name.
| |
| ; Scope: A brief description of the transaction.
| |
| ; Structural Role: Role of an individual within an organization. See ISO 21298
| |
| ; Transport Mode: the method the patient employs, or is provided to get to the emergency department.
| |
| ; Trigger Event: An event such as the reception of a message or completion of a process, which causes another action to occur.
| |
| ; UID: Unique Identifier (See also Globally Unique Identifier).
| |
| ; Universal ID: Unique identifier over time within the UID type. Each UID must belong to one of specifically enumerated species. Universal ID must follow syntactic rules of its scheme.
| |
| ; Use Case: A graphical depiction of the actors and operation of a system.
| |
| ; Wet Signature: Ink on paper signature.
| |
| ; XUA: Cross Enterprise User Authentication
| |
| ; XDS: Cross Enterprise Document Sharing
| |
| | |
| | |
| =Volume 2=
| |
| {{Title Page|
| |
| Domain=Patient Care Coordination|
| |
| Volume=Volumes II|
| |
| Revision=2.0|
| |
| Year=2006-2007|
| |
| Status=Draft}}
| |
HIMSS and RSNA
Integrating the Healthcare Enterprise
IHE Patient Care Coordination
Technical Framework
Volumes I and II
Revision 2.0
2007-2008
Comment
Comments may be submitted to:
http://forums.rsna.org under the “IHE” forum
Select the appropriate sub-forum for the technical framework you are commenting upon.
Forward
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. When clarifications or extensions to existing standards are necessary, IHE refers recommendations to the relevant standards bodies.
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 ([www.sfr-radiologie.asso.fr SFR]), and Società Italiana di Radiologia Medica (SIRM). In Japan IHE-J is sponsored by the Ministry of Economy, Trade, and Industry (METI); the Ministry of Health, Labor, and Welfare; and [www.medis.or.jp 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 actively involved and others are invited to join in the expansion of the IHE process across disciplinary and geographic boundaries.
The IHE Technical Frameworks for the various domains (Patient Care Coordination, IT Infrastructure, Cardiology, Laboratory, Radiology, etc.) define specific implementations of established standards to achieve integration goals that promote appropriate sharing of medical information to support optimal patient care. These are expanded annually, after a period of public review, and maintained regularly through the identification and correction of errata. The current version for these Technical Frameworks may be found at www.ihe.net.
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. 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. Subsequent volumes provide detailed technical descriptions of each IHE transaction.
Content of the Technical Framework
This technical framework defines relevant standards and constraints on those standards in order to implement a specific use cases for the transfer of information between systems. This document is organized into 2 volumes as follows:
This volume is provided as a high level overview of the profiles including descriptions of the use case, the actors involved, the process flow, and dependencies on other standards and IHE profiles. It is of interest to care providers, vendors' management and technical architects and to all users of the profile
Volume 2 – Transactions and Content Profiles
This volume is intended as a technical reference for the implementation of specific transactions in the use case including references to the relevant standards, constraints, and interaction diagrams. It is intended for the technical implementers of the profile.
How to Contact Us
IHE Sponsors welcome comments on this document and the IHE initiative. They should be directed to the discussion server at http://forums.rsna.org or to:
Didi Davis
Director of Integrating the Healthcare Enterprise
230 East Ohio St., Suite 500
Chicago, IL 60611
Email: ihe@himss.org
PCC TF-1
PCC TF-2
